Communication protocol

Abstract

A computer-implemented method for secure communication between a set of nodes in which a sequence of security levels is defined in which a first security level in the sequence is defined as a safest security level and a last security level in the sequence is defined as a least security level, and wherein a respective security of a respective security level in the sequence is defined as decreasing from the first security level to the last security level, where each respective node has a respective security certificate associated with the respective security level, wherein each node is configured to communicate with other nodes according to a communication protocol; wherein 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 a method for communicating securely between nodes and a method for enabling nodes to communicate securely. Background Art

[0002] Nodes in computer networks, including the Internet, can be highly heterogeneous. These network-connected computers can be diverse, ranging from Internet of Things (IoT) devices and smartphones to supercomputers and cloud computing data centers. Each piece of hardware is characterized by its corresponding computing power, functionality, and data storage level. At the same time, the software (both applications and operating systems) running on the hardware is also used to define the device.

[0003] The characteristics of a device on the network can also lie in the security it can provide and / or require. For example, a data center of a large company requires more stringent security measures than a random IoT device in a home network. Given the different levels of security guarantees that some nodes can provide, it is prudent for a node to limit the nodes with which it communicates based on its confidence in the level of security that these other nodes can provide. Summary of the Invention

[0004] According to one aspect disclosed herein, there is provided a computer-implemented method for secure communication between a group of nodes, in which a sequence of security levels is defined, where the first security level in the sequence is defined as the most secure level, and the last security level in the sequence is defined as the least secure level, and where the corresponding security of the corresponding security levels in the sequence is defined to decrease from the first security level to the last security level, where each corresponding node has a corresponding security certificate associated with the corresponding security level, where each node is configured to communicate with other nodes according to a communication protocol, and where the communication protocol at least defines the following rules:

[0005] i) A corresponding node having a corresponding certificate associated with a corresponding security level is able to send a message to a corresponding node having a corresponding certificate associated with any less secure security level in the sequence;

[0006] ii) A corresponding node having a corresponding certificate associated with a corresponding security level is able to send a message to a corresponding node having a corresponding certificate associated with the subsequent more secure security level adjacent to the corresponding security level in the sequence;

[0007] iii) A corresponding node having a corresponding certificate associated with a corresponding security level can receive a message from a corresponding node having a corresponding certificate associated with a less secure security level adjacent to the corresponding security level in the sequence;

[0008] iv) A corresponding node having a corresponding certificate associated with a corresponding security level can receive a message from a corresponding node having a corresponding certificate associated with any more secure security level in the sequence; and,

[0009] wherein 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.

[0010] According to another aspect disclosed herein, a computer-implemented method for secure communication between a group of nodes is disclosed, wherein a sequence of security levels is defined, wherein the first security level in the sequence is defined as the most secure level, and the last security level in the sequence is defined as the least secure level, and wherein the security of a corresponding security level in the sequence is defined as decreasing from the first security level to the last security level, wherein each corresponding node has a corresponding security certificate associated with a corresponding security level, wherein each node is configured to communicate with other nodes according to a communication protocol, and wherein the communication protocol defines at least the following rules:

[0011] i) A corresponding node having a corresponding certificate associated with a corresponding security level can send a message to a corresponding node having a corresponding certificate associated with any less secure security level in the sequence;

[0012] ii) A corresponding node having a corresponding certificate associated with a corresponding security level can send a message to a corresponding node having a corresponding certificate associated with one or more but not all of the next more secure security levels in the sequence;

[0013] iii) A corresponding node having a corresponding certificate associated with a corresponding security level can receive a message from a corresponding node having a corresponding certificate associated with any one or more but not all of the less secure security levels in the sequence;

[0014] iv) A corresponding node having a corresponding certificate associated with a corresponding security level can receive a message from a corresponding node having a corresponding certificate associated with any more secure security level in the sequence; and,

[0015] 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.

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

[0017] According to another aspect disclosed herein, a computer-implemented method for issuing security certificates for secure communication between a group of nodes is provided, where a sequence of security levels is defined, where the first security level in the sequence is defined as the most secure level, and the last security level in the sequence is defined as the least secure level, and where the corresponding security of the corresponding security levels in the sequence is defined to decrease from the first security level to the last security level, where each corresponding node has a corresponding security certificate associated with the corresponding security level, where each certificate authority in a group of certificate authorities is associated with a corresponding security level, where each security certificate associated with the corresponding security level is signed by the corresponding certificate authority associated with the corresponding security level, where each certificate authority is configured to issue a security certificate according to a certificate issuance protocol, and where the certificate issuance protocol at least defines the following rules:

[0018] i) The certificate authority associated with the corresponding security level can issue a security certificate associated with the same corresponding security level;

[0019] ii) The certificate authority associated with the corresponding security level can issue a security certificate to a node having a security certificate whose security level is less secure and adjacent to the corresponding security level in the sequence;

[0020] iii) The certificate authority associated with the corresponding security level can reissue a security certificate to a node having an expired or revoked certificate associated with the same corresponding security level; and,

[0021] where the method is performed by a first certificate authority and includes: issuing a security certificate to a requesting node according to the certificate issuance protocol.

[0022] According to another aspect disclosed herein, a computer-implemented method for issuing security certificates for secure communication between a group of nodes is disclosed, in which a sequence of security levels is defined, where the first security level in the sequence is defined as the most secure level, and the last security level in the sequence is defined as the least secure level, and where the corresponding security of the corresponding security levels in the sequence is defined to decrease from the first security level to the last security level, where each corresponding node has a corresponding security certificate associated with the corresponding security level, where each certificate authority in a group of certificate authorities is associated with a corresponding security level, where each security certificate associated with the corresponding security level is signed by the corresponding certificate authority associated with the corresponding security level, where each certificate authority is configured to issue security certificates according to a certificate issuance protocol, and where the certificate issuance protocol at least defines the following rules:

[0023] i) A certificate authority associated with a corresponding security level is able to issue a security certificate associated with the same corresponding security level;

[0024] ii) A certificate authority associated with a corresponding security level is able to issue a security certificate to a node having a security certificate such that the security certificate the node has has one or more but not all of the less secure security levels in the sequence;

[0025] iii) A certificate authority associated with a corresponding security level is able to reissue a security certificate to a node having an expired or revoked certificate associated with the same corresponding security level; and,

[0026] where the method is performed by a first certificate authority and includes: issuing a security certificate to a requesting node according to the certificate issuance protocol.

[0027] The embodiment also provides a protocol for issuing security certificates to nodes, where a node can only obtain a security certificate for a given security level from a certificate authority authorized to provide security certificates for that level. In some examples, the security certificate is published on the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] To assist in understanding the embodiments of the present disclosure and to illustrate how such embodiments may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0029] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0030] Figure 2Schematically shows some examples of transactions that can be recorded in a blockchain;

[0031] Figure 3 Is a schematic block diagram of an exemplary system having multiple security levels (zones);

[0032] Figure 4 Schematically shows exemplary communication lines between nodes in different security zones;

[0033] Figure 5 Schematically shows exemplary communication lines between a node and a certificate authority;

[0034] Figure 6 Schematically shows an exemplary relationship between security and CA certificates;

[0035] Figure 7 Schematically shows an exemplary process of node authentication. Detailed Description of the Invention

[0036] 1. Communication and Certificate Issuance Protocol

[0037] Figure 3 Shows 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 be in the same form of computing device, or some or all of the nodes 301 may be in different forms of computing devices. The nodes 301 together 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 Figure 1 Although it is not excluded that the nodes 301 can be blockchain nodes 104.

[0038] Each node 301 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, dedicated processors, and / or field programmable gate arrays (FPGAs), as well as other devices such as application specific integrated circuits (ASICs). Each node also includes a memory, that is, a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which employ one or more memory media, such as magnetic media such as hard disks, electronic media such as solid state drives (SSDs), flash memories, or electrically erasable programmable read-only memories (EEPROMs), and / or optical media such as optical disk drives.

[0039] System 300 includes multiple security layers or security levels or security zones 302. It should be noted that these layers 302 can be physical (e.g., different areas of a building), or non - physical, i.e., system 300 does not need to have any physical barriers or separations between the layers 302. The security layers 302 are defined in sequence, starting from the first layer (or initial layer) and ending at the last layer (or final layer). The first layer is the most secure layer, and the last layer is the least secure layer. For each layer from the first layer to the last layer, the security level decreases. For simplicity, in Figure 3 the most secure layer is labeled "Level 1", and the least secure layer is labeled "Level 4" (in this example, there are only four layers). However, it should be noted that Level 4 can be the most secure layer and Level 1 can be the least secure layer. It should be understood that system 300 can include any number of nodes 301 and have any number of layers 302.

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

[0041] The security certificate is associated with a given security layer 302. For example, the security certificate can 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). The security certificate is associated with only a single security layer 302.

[0042] 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, nodes 301 can communicate only if the communication complies with all the rules. That is, no other communication is allowed.

[0043] 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.

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

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

[0046] The fourth rule of the communication protocol is that a node 301 with a security certificate associated with a given security layer 302 can receive a message from a node 301 with a security certificate associated with a subsequent less secure security layer 302, but cannot receive a message from any security layer lower (i.e., less secure) than the subsequent less secure security layer 302.

[0047] For example, a node at level 1 can receive a message from a node 301 at level 2 (complying with the fourth rule), but cannot receive a message from a node at level 3 or 4 (due to the fourth rule). A node 301 at level 2 can receive a message from a node 301 at level 1 (complying with the third rule), and receive a message from a node at level 3 (complying with the fourth rule), but cannot receive a message from a node at level 4 (due to the fourth rule). A node 301 at level 3 can receive a message from nodes 301 at levels 1 and 2 (complying with the third rule), and receive a message from a node at level 4 (complying with the fourth rule). A node 301 can also receive a message from other nodes 301 with the same security certificate (i.e., a security certificate associated with the same security layer 302).

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

[0049] The communication protocol can define that messages will be sent in encrypted form. Thus, unless the context otherwise requires, any mention of sending a message may be taken to mean that the message is an encrypted message.

[0050] The communication protocol can define that messages sent (i.e., sent to and from) between nodes 301 within and between security layers 302 can be encrypted using a symmetric encryption key or an asymmetric encryption key. In some examples, messages sent between nodes 301 within security layer 302 are encrypted using symmetric encryption. In some examples, messages sent between nodes 301 between security layers 302 are encrypted using asymmetric encryption.

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

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

[0053] Figure 4 Schematically shown are messages 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, a symmetric key S 1,2 is used to encrypt messages sent between node n1 (level 1) and node n2 (level 2), and the symmetric key is generated using the key of node n1 and the key of node n2. An asymmetric key As3 is used to encrypt messages sent between node n1 (level 1) and node n3 (level 3), and the asymmetric key is generated using the public key of node n3.

[0054] Other encryption schemes can be used for any type of message.

[0055] The communication protocol can define the process that must be performed to initially convey a message between nodes of adjacent security layers 302, such as a handshake process. The sending node 301 first sends a request to the receiving node 301. The request includes the certificate of the sending node or a reference to the location of the certificate. For example, the reference can include the transaction identifier of a transaction on the blockchain 150 that includes the certificate. The receiving node 301 verifies the security certificate. This can include verifying whether the certificate includes the signature of or is signed by a certificate authority authorized to issue security certificates. This can also include verifying whether the certificate of the sending node 301 is associated with an appropriate security level, i.e., whether the sending node is associated with a security level that permits sending communications to the receiving node 301 based on the rules of the communication protocol.

[0056] If the verification of the security certificate passes, the receiving node 301 sends a verification message (which can be encrypted or not) to the sending node. 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 whether the signature is valid for the public key of the sending node. If the verification of the signature passes, the receiving node 301 will accept the message from the sending node 301. This can include performing a Diffie-Helman key exchange or a similar exchange with the sending node 301 to establish an encryption key.

[0057] The communication protocol can define the processes that must be performed to convey messages between nodes in non-adjacent security layers 302 when the receiving node 301 is in a more secure layer than the sending node 301. In this case, the sending node 301 must send the message (which can be encrypted) to an intermediate node in the adjacent more secure layer and request that the message be forwarded to the receiving node 301. If the intermediate node 301 is in the 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 the adjacent layer to the receiving node 301, the intermediate node 301 forwards the message to another intermediate layer in the adjacent more secure layer and requests that the message be forwarded to the receiving node 301. This process can be repeated one or more times until the receiving node 301 finally receives the message.

[0058] In some examples, the communication protocol can define further rules. In these examples, each security layer is associated with the most secure security layer, and nodes in a given security layer can communicate with this most secure security layer. That is, when this rule is implemented, an upper limit is set on the security layers with which a node can communicate. Nodes in a security layer can communicate with nodes in more secure layers up to the defined most secure security layer, but cannot communicate with nodes in more secure layers. It should be noted that the "most secure security layer" does not necessarily mean the most secure security layer in the sequence of security layers. Additionally, this rule defines that for adjacent layers, a node in a less secure layer cannot communicate with a node that is more secure than the nodes with which a node in a more secure layer can communicate. In other words, let n be the security layer, and let L(n) be the most secure layer to which a message can be sent directly from layer n. This rule defines L(n) <= L(n + 1).

[0059] In some embodiments, a certificate authority (CA) 303 is also arranged in the security layer, i.e., each CA 303 is associated with a corresponding security layer. In these embodiments, each CA 303 is configured to issue security certificates according to a certificate issuance protocol (i.e., according to the rules defined in the certificate issuance protocol). More specifically, the CA 301 can only issue a certificate if all the rules are complied with during the issuance.

[0060] The first rule of the certificate issuance protocol is that the CA 303 can issue a certificate associated with the same security level 302 as that associated with the CA 303. That is, the CA 303 can issue a certificate of the security level 302 occupied by the CA 303 to the node 301. For example, referring to Figure 5 , the CA in level n n can issue a certificate to the node n n .

[0061] The second rule of the certificate issuance protocol is that the CA 303 can issue a certificate associated with an adjacent less secure security level, but cannot issue any certificate associated with any non - adjacent less secure security level. For example, the CA n-2 can issue a certificate to the node n in level n - 1 n-1 , but cannot issue a certificate to the node n in level n n .

[0062] The third rule of the certificate issuance protocol is that the CA 303 can re - issue a certificate to the node 301 that previously had a security certificate associated with the same security level as the CA 303. For example, the node 303 can re - apply for a certificate after the previous certificate has been revoked or expired.

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

[0064] In some examples, compared to the above examples, the second rule of the certificate issuance protocol may be less strict. For example, the second rule can be relaxed to allow certificates to be issued to nodes at not only adjacent less secure security levels. Generally, the CA can issue certificates to any but not all nodes in the less secure security levels. For example, the CA can issue certificates to nodes in the subsequent x less secure security levels, where x is less than the number of remaining security levels in the sequence. x and m can define a threshold number of security levels. The threshold can be defined by the user of the node system. The threshold can be based on one or more attributes of the system, such as one or more attributes of the nodes, such as the type of communication between nodes (such as wired or wireless) and / or the type of data communicated between nodes (e.g., a measure based on sensitivity) and / or one or more attributes of the level sequence (e.g., the total number of levels in the sequence). As a specific example, the threshold can be set to be equal to a function (e.g., rounded, ceiling, or truncated) of at least the number of levels, e.g., rounded(number of levels / 4).

[0065] The node 301 and the CA 303 can interact in the following manner to obtain a certificate. The node 301 (requesting node) that requests the certificate sends a request for the certificate associated with that level 302 to the CA 303 associated with a specific security level 302. The CA 303 performs one or more checks to determine that the requesting node 301 is eligible to receive such a certificate. This can include determining whether the requesting node 301 has a valid certificate for an adjacent less secure level 302. If the verification passes, the CA 303 generates a security certificate associated with the requesting node 301 and a security level associated with the 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.

[0066] The communication protocol can define how the nodes 301 can communicate with the CA 303 and / or how the CAs 303 can communicate with each other.

[0067] Starting from the interaction between the node 301 and the CA 303, the communication protocol can define 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 an adjacent more secure security layer 302, but not from a CA associated with a non - adjacent more secure security layer 302.

[0068] Regarding the interaction between CAs, a CA 303 associated with a given security layer 302 can communicate with a CA 303 associated with the same security layer 302 and a CA 303 associated with an adjacent security layer 302.

[0069] Further optional examples are described below.

[0070] 2. Encryption Technologies

[0071] 2.1 X.509 Certificates

[0072] X.509 is the standard format for public key certificates, i.e., digital documents that securely associate cryptographic key pairs with identities such as websites, individuals, or organizations. Each X.509 certificate includes at least a public key, a digital signature, and information about both the identity associated with the certificate and its certificate authority (CA).

[0073] The information fields include details such as name and address or organization, details of the signature algorithm used, and the expiration date. An X.509 certificate can be revoked before its expiration date. It can be revoked.

[0074] The transparency and immutability characteristics of blockchain are generally considered useful in the issuance and storage of digital certificates.

[0075] 2.2 Diffie-Hellman

[0076] Secure communication between nodes can be achieved through encryption. This can be done using symmetric encryption schemes or asymmetric encryption schemes. For symmetric encryption, the Diffie-Hellman exchange can be used to securely establish a shared key between a pair of nodes. For elliptic curve cryptography, the Diffie-Hellman exchange can be done through the following steps:

[0077] 1. Each party uses secp256k1 to create its public-private key pair. Bob (v B ,P B ), Alice (v A ,P A ), where P B = v B G, and P A = v A G.

[0078] 2. Each party shares its public key with the other party. Bob provides the key P B to Alice, and Alice provides the key P A to Bob. This can be done through a public channel.

[0079] 3. Each party multiplies the other party's public key by its (the original party's) private key. Bob calculates v B P A 。 Alice calculates v A P B 。

[0080] 4. Both parties now have a shared key that can be used for symmetric encryption.

[0081] S AB =v B P A =v A P B =v B v A G=v A v B G

[0082] Neither party needs to know the other party's private key, and a third party cannot determine S AB , because they do not know the private keys v A or v B 。

[0083] 2.3 RSA Encryption

[0084] For asymmetric encryption, RSA can be used. For RSA, both parties also have their own public-private key pairs. The public key is used to encrypt messages, while the private key is used to decrypt messages. The following are several key steps in RSA encryption:

[0085] - Generate the RSA modulus (n);

[0086] o Select two large prime numbers p and q. Both of these are kept secret.

[0087] o Calculate n = p × q. The length of n is usually in bits. For strong encryption, let n be a large number, usually at least 512 bits.

[0088] - Obtain the derived number (e)

[0089] o Select an integer e greater than 1 and less than (p - 1)(q - 1).

[0090] o Except for 1, e and (p - 1)(q - 1) should not have a common factor, that is, the two numbers e and (p - 1)(q - 1) are relatively prime.

[0091] - Compose the public key

[0092] o A pair of numbers (n, e) constitutes the RSA public key

[0093] - Generate the private key

[0094] o The private key d is calculated based on p, q, and e. For a given n and e, there is a unique number d.

[0095] o The number d is the reciprocal of e modulo (p - 1)(q – 1). This means that

[0096] ed = 1 mod (p - 1)(q - 1)

[0097] o The Extended Euclidean algorithm calculates d based on the values p, q, and e.

[0098] To encrypt a message m using the public key (n, e) to generate a ciphertext c, use the following equation

[0099] c = m e (mod n)

[0100] To decrypt the ciphertext c using the private key d, use the following calculation

[0101] c d = (m e ) d = m (mod n)

[0102] 3. Network Access Control Switching Protocol

[0103] This section describes an exemplary protocol ("network access protocol") that can be implemented using the specific examples of the above embodiments. It should be understood that some examples are optional.

[0104] 3.1 Communication between Nodes

[0105] This section describes a network access security protocol in which nodes in a network are authenticated as conforming to one of a set of discrete n security levels, where n > 2 (see Figure 3 ). A node authenticated as conforming to security level i (where i ∈ [1, n]) is granted a health (i.e., secure) certificate Cer i .

[0106] The certificate Cer i involves the use of a digital signature by a certification authority. The signature signs a message that includes the identification information of the node. The identification information can include the registered public key of the node.

[0107] A node with Cer i is considered more secure than a node with certificate Cer j where j > i.

[0108] For a node with certificate Cer i , communication with another node follows the following rules:

[0109] - Node n with certificate Cer i can send communications to nodes with Cer i where v ≥ 1. i+v

[0110] - Node n with certificate Cer i can send communications to nodes with Cer i i-1

[0111] - Node n with certificate Cer i can receive communications from nodes with Cer i i+1

[0112] - Node n with certificate Cer i can receive communications from nodes with Cer i where v ≥ 1. i-v

[0113] The term "communication" can exclude sending identification and authentication. All nodes can receive messages including the ID and health certificate of another node.

[0114] Figure 4 Shows the communication lines between nodes from each security zone within the security area. Node n2 can be considered capable of directly communicating with nodes at one higher security level (n1) and one lower security level (n3). Node n2 can also directly send communications to the less secure node n4, but this cannot be interactive, i.e., node n4 cannot directly send messages to n2. Another node of interest is node n1 which can communicate 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.

[0115] 3.2 Communication with Certificate Issuing Authorities

[0116] The protocol uses multiple Certificate Authorities (CAs). The CAs themselves operate within a restricted security area. The Certificate Authority CA i is expected to reside within security zone i. Thus, the CA i is restricted with respect to the objects with which it can communicate. The communication between the CA and the nodes follows the following principles.

[0117] - Allow the authority CA i : i ≠ n to communicate with any node with authentication Cer i , Cer i+1 or Cer i-1 ​​​​​​​

[0118] - Allow a CA with the lowest security clearance n to communicate with new nodes of the network (the nodes do not have authentication).

[0119] - Allow institutional CAs i to communicate with CA i-1 and CA i+1 .

[0120] - Node n in the network i+1 must directly interact with the certification authority (CA i ) to upgrade its health certificate. The CA i (either by itself or via a third-party service) determines whether the node meets the criteria for receiving the certificate Cer i .

[0121] - Institutional CAs i can only authenticate whether the node meets the security and health level Cer i .

[0122] - Nodes with the authentication Cer i can only upgrade their authentication to Cer i-1 .

[0123] - Store and / or represent all granted health certificates on the blockchain 150.

[0124] Figure 5 A representation of these communication lines is shown in

[0125] 3.3 Private Message Passing between Nodes

[0126] The protocol supports private messaging. This means that messages sent to or from a node should not be read by unintended parties. This is achieved by encrypting the messages. In some examples:

[0127] - Each node n i has an EC public-private key pair. For example, node n i will have the pair (k i , P i ), where P i = k i G. This public key is publicly registered or a provable derivative of a registered public key.

[0128] - Each node has an RSA public-private key pair. For example, node n i will have the pair (n i , e i ). This public key is publicly registered or a provable derivative of a registered public key.

[0129] To complete a conversation between a pair of nodes, a symmetric key is used to encrypt the messages between the pair of nodes. This symmetric key can be obtained by both parties through a Diffie-Hellman exchange (described below). It should be remembered that node n i can communicate with a node having Cer i+1 (n i+1 ) and a node having Cer i-1 (n i-1 ). For example, (see Figure 4 ) node n2 generates a shared symmetric encryption key S 1,2 through a Diffie-Hellman exchange with n1. This key (by both nodes) is used to encrypt the messages in the communication between the two nodes. Similarly, node n2 establishes a shared value S 2,3 with node n3.

[0130] In the case where there is only one-way communication between one node and another node, the message is sent from node n i to the less secure node n j , where j > i + 1, and the sending node uses the RSA public key As j =(n j ,e j ) of the receiving node to encrypt the message. For example, (see Figure 4 ) node n1 encrypts the message to n3 using As3 and encrypts the message to n4 using As4. Node n2 also communicates with n4 using As4.

[0131] 3.4 Protocol Flow

[0132] This section describes several processes of the network access protocol.

[0133] 1. Establishment of a certificate authority.

[0134] 2. Nodes have obtained authentication for the security zones they satisfy.

[0135] 3. Nodes communicate based on the assigned health level certificates.

[0136] 3.4.1 Establishment of Certificate Issuing Authority Hierarchy

[0137] The certificate authority establishes that n + 1 certificate authorities are created to authenticate the health and security levels of the applicant nodes.

[0138] Root certificate authority

[0139] One of them is the root certificate authority CA RT . This CA is the initiator of the protocol and the core and most trusted entity in the network. Its identity and public key is known. Its responsibilities are as follows:

[0140] · Certify CA1 as a CA. Among them, CA Rt Provide a certificate to CA1 to certify CA1 as one of the servers with the permission of the health and safety level of Cer1 for the authorized authentication node. is a certificate that contains the identities (of the recipient and signer) and other necessary information applicable to declaring the owner of the signed certificate as a certificate authority.

[0141] · Certify the security level of CA1.

[0142] · Submit a signed transaction to the blockchain, and the signed transaction contains the metadata of CA1

[0143] · Submit a signed transaction to the blockchain, and the signed transaction contains the metadata Cer1 of CA1.

[0144] Root certificate authority CA Rt is not responsible for determining health certificates or assigning health certificates to any non-CA nodes in the network.

[0145] Certificate authorities 1-n

[0146] Non-root certificate authorities (CA i : i ∈ [1, n]) are trusted servers in the trusted institutional hierarchy on the network. Each is assigned a security level and needs to comply with the corresponding rules of that security level. This means that CA i is not allowed to communicate with nodes that do not have the health level Cer i+1 、Cer i or Cer i-1 . CA CA i 's responsibilities are as follows:

[0147] · Certify CA i+1 as a CA. Among them, CA i Provide a certificate to CA1 to certify CA i+1 as one of the authorized certificate authorities with the permission of the health and safety level of Cer i+1 in the authorized certificate authority.

[0148] · Accept an authentication request from a node with at least a health certificate of CA i+1 , determine whether the node meets the criteria of CA i , and grant the certificate CA i to the node if applicable.

[0149] · Submit a signed transaction to the blockchain, the signed transaction containing metadata of the CA i+1

[0150] · Submit a signed transaction to the blockchain, the signed transaction containing metadata of the CA i+1 Cer i+1 .

[0151] · Submit a signed transaction to the blockchain, the signed transaction containing metadata of n i+1 Cer i .

[0152] These CA servers may or may not be installed with different hardware-software; the key difference in the security level of the CA lies in the security level of the nodes allowed to communicate with it. The institutional CA i is allowed to communicate with nodes n i and n i+1 .

[0153] A trust chain can be established among the authentications of the CA . The root certificate authority CA Rt provides a signature in the CA certificate to indicate the validity of CA1 as a certificate authority at security level 1. Refers to the identity of its "parent institution". More generally, the CA authentication contains the signature of its parent institution and refers to the ID of that parent institution. Interested parties will be able to trace the trust path to the root CA or at least to the CA they trust j : j ≤ i - 1.

[0154] Figure 6 Shows the exemplary components of the health certificate Cer i and how the certificate interacts with the CA certificate. For example, consider the health and safety certificate Cer1. Each certificate contains the signature of the issuer. CA1 provides a digital signature that signs most (if not all) of the other data in the certificate. The certificate also includes a reference to the certificate of the certificate authority . The certificate (which may be stored / represented on the blockchain) will have been signed by its parent CA (CA Rt ). The certificate Cer1 also contains a copy of the public key of the CA . The public key (or a provable derivative) is the public key that will (has) been used to sign the CA certificate of the CA at a subsequent lower security level. Finally, the certificate Cer1 will include identification information and other information about the node n1 for which the security level 1 authentication is being granted.​

[0155] 3.4.2 Node Authentication

[0156] This section refers to Figure 7 the process by which a node obtains a health certificate.

[0157] New node

[0158] Only a node n without any health certificates is allowed New to communicate with the CA with the lowest health certificate (CA n ).

[0159] · n New will send a request to the CA n to request authorization for the certificate Cer n .

[0160] · The CA n will perform the necessary checks to determine whether n New meets the criteria.

[0161] · If so, the CA n will create the certificate Cer New for the node n n , send a copy to n New , and submit a copy to the blockchain.

[0162] · The previous n New might have been upgraded to n n , and can communicate with the following:

[0163] o New nodes

[0164] o Nodes with Cer n

[0165] o Nodes with Cer n-1

[0166] o CA n

[0167] o CA n-1 .

[0168] Node n i

[0169] · n i sends a request to the CA i-1 to request authorization for the certificate Cer i-1 .

[0170] · The CA i-1 will perform the necessary checks to determine whether n i meets the criteria.

[0171] · If so, then CA i-1 is the node n i Create the certificate Cer i-1 , send a copy to n i , and submit a copy to the blockchain.

[0172] · The previous n i has been upgraded to n n-1 , and can communicate with the following:

[0173] o Nodes with Cer i

[0174] o Nodes with Cer i-1

[0175] o Nodes with Cer i-2

[0176] o CA n-1

[0177] o CA n-2

[0178] o CA n .

[0179] 3.4.3 Node Communication

[0180] The new node

[0181] Allows the new node n New to communicate with the least secure node n n . To communicate with the node n n (new node), perform the following steps:

[0182] - n New Send a communication request to the node n n . The communication includes the identification information of n new (e.g., its public key P new )

[0183] - n n Send a random message m new to n Rnd

[0184] - n new Sign the message using P new and send the signature to n n

[0185] - If the signature is valid

[0186] o The two parties perform a Diffie - Hellman exchange, thus generating a shared secret S n,New ​​​

[0187] oS n,New For encrypting messages between the two parties in any future conversation.

[0188] Node n i To a more secure Node n i-1

[0189] -n i Send a communication request to Node n i-1 The communication includes the identification information of n (e.g., its public key P i i ) and its health certificate Cer i i-1 (or a reference to a transaction with a certificate on the blockchain).

[0190] -n i-1 Verify the certificate CA of Node n i i

[0191] -n i-1 Send a random message m to n i Rnd i

[0192] -n i Sign the message using P i n-1 And send the signature to n

[0193] - If the signature is valid and the certificate is verified,

[0194] o The two parties perform a Diffie - Hellman exchange, thus generating a shared secret S i-1,i

[0195] oS i-1.i For encrypting messages between the two parties in any future conversation.

[0196] Node n i To a less secure Node n i+1

[0197] -n i Send a communication request to Node n i+1 The communication includes the identification information of n (e.g., its public key P i i ) and its health certificate Cer i i+1 (or a reference to a transaction with a certificate on the blockchain).

[0198] -n i+1 Verify the certificate CA of Node n i i ​

[0199] -n i+1 To n i Send a random message m Rnd

[0200] -n i Use P i Sign the message and send the signature to n n+1

[0201] - If the signature is valid and the certificate is verified,

[0202] o The two parties perform a Diffie-Hellman exchange, resulting in a shared secret S i,i+1

[0203] oS i.i+1 Is used to encrypt messages between the two parties in any future conversation.

[0204] Node n i To a less secure node n j , where j > i + 1

[0205] -n i Obtain the RSA public key of node n j (n j , e j ). It should be noted that this RSA public key is a registered public key or a provable derivative of a registered public key. [It should also be noted that n j , e j in the RSA public key (n j refers to the RSA modulus (described below) rather than node n j )

[0206] -n i Encrypt its message to node n using the RSA public key j .

[0207] -n i Send the encrypted message to node n j .

[0208] Node n i To a more secure node n k , where k < i - 1

[0209] If node n i wants to communicate with a more secure node n that is at least two security levels higher k , direct communication is not possible. The communication passes through intermediate nodes and their corresponding security protocols before reaching the intended recipient. Node n i Sends the message to node n i-1, and accompanied by instructions to the final destination. Node n i-1 sends the message to Node n i-2 , and accompanied by instructions to the final destination. And so on. This continues until the node reaches the final destination n k .

[0210] More formally, if Node n i needs to communicate about message m with Node n k , where k < i - 1, then the message must be forwarded in sequence through a set of nodes {n a : i - 1 ≤ a ≤ k + 1}.

[0211] If privacy needs to be protected, then Node n i can use the RSA public key (n k , e k ) of Node n k to encrypt the message m and then forward it along the chain.

[0212] 3.5 Revocation and Isolation

[0213] 3.5.1 Revocation

[0214] Health certificates typically include an expiration date, i.e., the date when the certificate is no longer valid. This allows for the opportunity to re-evaluate the node and its ability to continue meeting the certificate criteria. Additionally, if a node fails to comply with the regulations of that security level, the institution may wish to revoke the node's certification (before the expiration date).

[0215] In the case where the certificate Cer i of Node n i is revoked or expired, if the node wishes to renew it, the node must re-apply to the CA i for Cer i . If a node knows that its certification is about to expire, it can apply for renewal while its current certificate is still valid.

[0216] Assuming that a node with certificate Cer i also has a valid certificate Cer i+1 may not be safe because Cer i+1 may have expired. Assume that the expiration periods of all certificates in each security area are the same. In some cases, the expiration periods of security certificates may be uniform across all security areas, or they may be uniform only within a certain security area but differ between areas. The expiration period can be customized for each node. To continuously re-evaluate and ensure compliance with the standards, it may be considered prudent to have a shorter expiration period for high-security certificates. This means losing its Cer iNodes will not automatically be assumed to have any Cer j of Cer i+1 where j > i + 1.

[0217] If the certificate Cer of a node i has expired, conditions can be incorporated into the protocol where nodes with expired / revoked certificates Cer i can use their expired certificates to communicate with the CA i and reapply for a new Cer i .

[0218] Alternatively, it may not be allowed to discard its certificate Cer i (and at least Cer i+1 ) of node n i from communicating with the CA i to request a renewal. The (previous) node n i is now assumed to be node n x where x is the highest significant security certificate level that the node still has a valid certificate for, and x > i + 1. The worst-case scenario is that the node degrades to being considered n New . To regain authentication from the CA i , node n x / n New must reapply for higher-level security certificates in order until it reverts to level i.

[0219] 3.5.2 Isolation

[0220] In some cases, nodes may be prohibited from interacting with other nodes in the network. In such cases, a blacklist can be maintained by identifying a group of nodes. This list can be stored in a location accessible to all nodes (e.g., a blockchain).

[0221] Any node that receives a communication request from another node can first check the blacklist to determine if the requesting node is blacklisted. If the node is blacklisted, communication with the requesting node is not allowed.

[0222] 3.6 Representing Certificates via Blockchain

[0223] The blockchain provides several features and capabilities that make it suitable for use as a storage or representation form for digital certificates. The transparency of the content enables any stakeholder interested in the certificate data to access and view this content. At the same time, the encryption capabilities and smart contract capabilities of the blockchain present opportunities to integrate and improve various aspects of digital certificates.

[0224] 3.6.1 Certificate Storage

[0225] The (OP_RETURN) output of a blockchain transaction can be used to store arbitrary data. This data can be a security certificate Cer i or a CA certificate In some cases, the hash of a certificate may be more suitable for storage on the blockchain than the original certificate data itself (e.g., for data size and privacy reasons). This hash can be mapped to a hash value in an off-chain hash table containing the original certificate data.

[0226] The following Table 1 shows an example of certificate storage in a transaction.

[0227]

[0228] Table 1: Certificate Storage in Bitcoin Transactions

[0229] It should be noted that the entity that signs the input of a transaction is not limited to a certificate authority. In theory, anyone can sign the transaction input; the certificate stored in the (OP_RETURN) output will contain all the information that gives the certificate validity, including the digital signature of the issuer.

[0230] 3.6.2 Signing

[0231] The issuer of a certificate can sign the input of the authentication transaction TxID Cer instead of storing the issuer's signature in the (OP_RETURN) output. This output can contain other non-signature data that can be found in a digital certificate. For an example of a CA i signing the input of an authentication transaction, see Table 2.

[0232] Unspent transaction outputs can be used to represent the continued validity of a certificate. Spending an output may be interpreted as meaning that the authentication has expired or been revoked. In the exemplary transaction shown in Table 2, the output at index 0 uses a script lock that requires a signature from a CA i If the CA spends this output, the certificate is considered no longer valid.

[0233]

[0234] Table 2: Using Transactions to Represent Certificates

[0235] 4. Overview of an Exemplary Blockchain System

[0236] Figure 1An exemplary system 100 for implementing a blockchain 150 is shown. The system 100 may include a packet-switching network 101, typically a wide-area internet such as the Internet. The packet-switching network 101 includes a plurality of blockchain nodes 104 (commonly referred to as "miners"), which may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switching network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0237] Each blockchain node 104 includes a computer device of a peer, and different nodes 104 belong to different peers. Each blockchain node 104 includes processing means, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, dedicated processors, and / or field-programmable gate arrays (FPGAs), and other devices, such as application-specific integrated circuits (ASICs). Each node also includes a memory, namely a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which employ one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memories, or electrically erasable programmable read-only memories (EEPROMs), and / or optical media such as optical disk drives.

[0238] The blockchain 150 includes a series of data blocks 151, where a corresponding copy of the blockchain 150 is maintained at each of the plurality of blockchain nodes 104 in the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, the blockchain 150 can perform data pruning as long as each blockchain node 150 stores the block headers (discussed below) of each block 151. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses a specific transaction protocol throughout.

[0239] The blockchain node 104 can be configured to forward the transaction 152 to other blockchain nodes 104, so that the transaction 152 spreads throughout the network 106. The blockchain node 104 can be configured to create a block 151 and store a corresponding copy of the same blockchain 150 in its respective memory. The blockchain node 104 can also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into the block 151. The ordered pool 154 is commonly referred to as the "mempool". In this article, this term is not intended to be restricted to any specific blockchain, protocol, or model. This term refers to an ordered set of transactions that the node 104 has accepted as valid, and for which the node 104 is forced not to accept any other transaction that attempts to spend the same output.

[0240] In a given current transaction 152j, the input (or each input) includes a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring financial assets, although this is certainly a common application. More generally, spending can be described as consuming the output or allocating it to one or more outputs in another subsequent transaction. Typically, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although a previous transaction 152i will need to exist and be verified as valid to ensure the validity of the current transaction, the previous transaction 152i does not have to exist when creating the current transaction 152j or even sending the current transaction 152j to the network 106. Therefore, in this article, "previous" refers to the predecessor in the logical sequence linked by the pointer, rather than necessarily the creation time or sending time in the time sequence, and thus does not necessarily exclude the case of creating or sending transactions 152i, 152j out of order (see the discussion on orphan transactions below). The previous transaction 152i can equally be referred to as the antecedent transaction or the predecessor transaction.

[0241] Due to the resources involved in transaction verification and publication, typically at least each blockchain node 104 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 can take the form of a user terminal or a group of user terminals networked together.

[0242] The memory of each blockchain node 104 stores software configured to run on the processing device of the blockchain node 104 to perform its respective role according to the blockchain node protocol and process transactions 152. It should be understood that any action attributed to the blockchain node 104 in this article can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in an application layer or one or more applications in a lower layer such as the operating system layer or the protocol layer, or any combination of these layers.

[0243] Any given blockchain node can be configured to perform one or more of the following operations: verifying transactions, storing transactions, propagating transactions to other peers, 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, nodes can be dedicated to specific operations. For example, node 104 can focus on transaction verification and propagation, or can focus on block mining. In some examples, blockchain node 104 can perform more than one of these operations in parallel. Any reference to blockchain node 104 can refer to an entity configured to perform at least one of these operations.

[0244] The computer device 102 of each party 103 that plays the role of a consuming user is also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without having to act as senders or receivers. For example, some parties can act as storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0245] Some or all of the parties 103 can be connected as part of different networks, such as a network overlaying the blockchain network 106. The users of the blockchain network (often referred to as "clients") can be said to be part of the system that includes the blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 can interact with the blockchain network 106 so as to utilize the blockchain 150 by connecting to the blockchain node 106 (i.e., communicating with the blockchain node 106). For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but are not shown for the sake of convenience. Each party 103 can be an individual or an organization. For illustrative purposes only, in this document, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this document can be replaced by "first party" and "second party" respectively.

[0246] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each party 103 also includes a memory, namely a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which employ one or more memory media, such as magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer device 102 of each party 103 stores software, which includes a corresponding instance of at least one client application 105 configured to run on the processing device. It should be understood that any action attributed to a given party 103 herein can be performed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through the user terminal.

[0247] The client application 105 can initially be provided to the computer device 102 of any given party 103 through, for example, a suitable computer-readable storage medium downloaded from a server, or through a removable storage device such as a removable SSD, a flash drive, a removable EEPROM, a removable disk drive, a floppy disk, or a magnetic tape, an optical disk such as a CD or DVD ROM, or a removable optical disk drive.

[0248] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the corresponding party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104, which are then propagated in the network of blockchain nodes 104 and thus included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant party scattered in the blockchain 150.

[0249] Note: Although various client functions may be described as integrated into a given client application 105, this is not necessarily restrictive. Instead, any client function described herein may be implemented in a suite of two or more different applications, such as via an API interface or one application as a plugin to another application. More generally, client functions may be implemented at the application layer or at a lower layer such as an operating system or any combination of these layers. The following will be described in terms of client application 105, but it should be understood that this is not restrictive.

[0250] An instance of the client application or software 105 on each computer device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the corresponding party 103 is the recipient (or indeed to check the transactions of other parties in the blockchain 150, since in the embodiments the blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software that is configured to verify transactions 152 according to a blockchain node protocol and forward transactions 152 for propagation in the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 104 in the network 106 use the same node protocol.

[0251] As part of an account-based transaction model, another type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol. In the account-based case, each transaction does not define the amount transferred by reference to the UTXO of a previous transaction in a past transaction sequence, but rather by reference to an absolute account balance. The current state of all accounts is stored separately by the nodes of the network into the blockchain and is continuously updated. In such systems, transactions are ordered using the running transaction record of the account (also referred to as "position" or "nonce"). This value is signed by the sender as part of its cryptographic signature and is hashed as part of the transaction reference calculation. Additionally, optional data fields may also be signed in the transaction. For example, if the data field contains the ID of a previous transaction, the data field may point to the previous transaction.

[0252] Some account-based transaction models have some similarities to the output-based transaction model described herein. For example, as described above, the data fields of an account-based transaction can point to the previous transaction, which is equivalent to the input of an output-based transaction that references the output points of the previous transaction. Thus, both models support chaining between transactions. As another example, an account-based transaction includes a "recipient" field (where the receiving address of the account is specified) and a "value" field (where a certain quantity of digital assets can be specified). Together, the recipient and value fields are equivalent to the output of an output-based transaction that can be used to allocate a certain quantity of digital assets to a blockchain address. Similarly, an account-based transaction has a "signature" field that includes the signature of the transaction. The signature is generated using the sender's private key and confirms that the sender has authorized the transaction. This is equivalent to the input / unlock script of an output-based transaction, which typically includes the signature of 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. On an account-based blockchain, a "smart contract" refers to a transaction that contains a script that is 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 satisfy one or more conditions defined by the script of the smart contract. The smart contract exists as a transaction on the blockchain and can be invoked (or triggered) by a subsequent transaction. Thus, in some examples, a smart contract can be considered equivalent to the locking script of an output-based transaction (which can be triggered by a subsequent transaction) and checks whether the inputs of the subsequent transaction satisfy one or more conditions defined by the locking script.

[0253] 5. UTXO-Based Model

[0254] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). It will be described below by reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that while an exemplary UTXO-based protocol is described with reference to Bitcoin, it can equally well be implemented on other example blockchain networks.

[0255] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 can include an unspent transaction output (UTXO), which can be used as a source for an input 202 of another new transaction (if the UTXO has not been redeemed yet). The UTXO includes a value specifying the amount of digital assets. This represents a set of tokens on the distributed ledger. The UTXO can also contain the transaction ID of its source transaction and other information. The transaction data structure can also include a header 201, which can include size indicators for the input field 202 and the output field 203. The header 201 can also include the ID of the transaction. In an embodiment, the transaction ID is the hash value of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the node 104.

[0256] For example, Alice 103a wishes to create a transaction 152j that transfers a related amount of digital assets to Bob 103b. In Figure 2 this, Alice's new transaction 152j is labeled "Tx1". This new transaction obtains the amount of digital assets locked to Alice in the output 203 of a previous transaction 152i in the sequence and transfers at least a portion of such amount to Bob. In Figure 2 this, the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels and do not necessarily mean that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to a subsequent transaction in the pool 154. Tx1 can point to any previous (i.e., antecedent) transaction that still has an unspent output 203 locked to Alice.

[0257] The terms "previous" and "subsequent" as used in the context of the transaction sequence herein refer to the order of transactions in the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They can equally be replaced by "predecessor" and "successor", "ancestor" and "descendant", or "parent" and "child", etc. This does not necessarily refer to the order in which they are created, sent to the network 106, or reach any given blockchain node 104. However, a subsequent transaction (descendant transaction or "child") that points to a previous transaction (ancestor transaction or "parent") will not be valid unless the parent transaction is valid. A child that reaches the blockchain node 104 before its parent is considered orphaned. Depending on the node protocol and / or node behavior, it can be discarded or buffered for a period of time to wait for the parent.

[0258] One of the one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of a subsequent transaction must satisfy in order for the subsequent transaction to be valid and thus successfully redeem the UTXO.

[0259] The locking script (also known as scriptPubKey) is a piece of code written in a domain - specific language recognized by the node protocol. A specific example of such a language is called "Script" (with S capitalized), which can be used by the blockchain network. The locking script specifies the information required to spend the transaction output 203, such as the requirement for Alice's signature. The locking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a piece of code written in a domain - specific language that provides the information required to meet the locking script criteria. For example, it can contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0260] Thus, in the example shown, the UTXO0 in the output 203 of Tx0 includes the locking script [Checksig P A , which requires Alice's signature Sig P A to redeem UTXO0 (strictly speaking, to make a subsequent transaction attempting to redeem UTXO0 valid). [Checksig P A contains the representation (i.e., hash) of the public key P A in Alice's public - private key pair. The input 202 of Tx1 includes a pointer to Tx1 (e.g., via its transaction ID (TxID0), which in the embodiment is the hash value of the entire transaction Tx0). The input 202 of Tx1 includes the index that identifies UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes the unlocking script <Sig P A >, which includes Alice's cryptographic signature created by Alice by applying the private key in her key pair to a predetermined portion of data (sometimes called the "message" in cryptography). The data (or "message") for which Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0261] When the new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script meets the conditions defined in the locking script (where the conditions can include one or more criteria).

[0262] It should be noted that script code is typically represented diagrammatically (i.e., using non-precise language). For example, opcodes can be used to represent specific functions. "OP_..." refers to specific opcodes of the script language. For example, OP_RETURN is a script language opcode that, when preceded by OP_FALSE at the start of a locking script, creates an unspendable output of a transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data can include a file to be stored in the blockchain.

[0263] Typically, the input of a transaction contains a digital signature corresponding to the public key PA. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific data segment. In an embodiment, for a given transaction, the signature will sign part of the transaction input as well as part or all of the transaction output. Signing a specific part of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that is used to select the output to be signed (and thus fixed at the time of signing).

[0264] The locking script is sometimes referred to as "scriptPubKey", meaning that it typically includes the public key of the party to which the corresponding transaction is locked. The unlocking script is sometimes referred to as "scriptSig", meaning that it typically provides the corresponding signature. But more generally, in all applications of the blockchain 150, the conditions for UTXO redemption do not necessarily include verifying a signature. More generally, the script language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" can be preferably used.

[0265] 6. Side Channels

[0266] As Figure 1As shown, the client applications on each of the computer devices 102a, 120b of Alice and Bob can include additional communication capabilities. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 enables data to be exchanged outside of the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, this can be used to exchange a transaction 152 between Alice and Bob without registering the transaction (yet) on the blockchain network 106 or posting it to the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing a transaction in this way is sometimes 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, the side channel 107 can be used to exchange any other transaction-related data, such as keys, negotiation amounts or terms, data content, etc.

[0267] The side channel 107 can be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 can be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between the devices 102a, 102b of Alice and Bob. Generally, the side channel 107 referred to anywhere in this document can include any one or more links via one or more networking technologies or communication media for "off-chain" data exchange, i.e., data exchange outside of the blockchain network 106. In the case of using multiple links, the off-chain link bundle or set as a whole can be referred to as the side channel 107. Therefore, it should be noted that if it is said that Alice and Bob exchange certain information or data, etc. via the side channel 107, this does not necessarily mean that all of this data must be sent over exactly the same link or even the same type of network.

[0268] 7. Further Comments

[0269] Once the disclosure of this document is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited by the described embodiments, but only by the appended claims.

[0270] For example, some of the above embodiments have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of the blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any reference above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 can be replaced by reference to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. The blockchain, the blockchain network, and / or the blockchain node may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 as described above.

[0271] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin node 104 performs at least all of the functions of creating, publishing, propagating, and storing the 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 of these functions but not all of them. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing the blocks (keep in mind that these entities are not considered nodes of the preferred Bitcoin network 106).

[0272] 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 of the functions of creating, publishing, propagating, and storing the blocks 151 of the blockchain 150 but not all of them. For example, on these other blockchain networks, the term "node" may be used to refer to a network entity that is configured to create and publish the blocks 151 but does not store and / or propagate these blocks 151 to other nodes.

[0273] Even more generally, any reference above to the term "Bitcoin node" 104 can be replaced by the term "network entity" or "network element", where such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functions of such a network entity / element can be implemented in hardware in the same manner as described above with reference to the blockchain node 104.

[0274] Some embodiments have been described in the context of 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 any suitable type of consensus mechanism can be used in general embodiments, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-past-time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has the opportunity to generate the next block 151. The selected node is typically referred to as a validator. A blockchain node can lock its tokens for a period of time to have the opportunity to become a validator. Generally, the node that locks the maximum stake for the longest time is most likely to become the next validator.

[0275] It should be understood that the above embodiments are described only by way of example. More generally, a method, apparatus, or program can be provided in accordance with any one or more of the following statements.

[0276] Statement 1. A computer-implemented method for secure communication between a group of nodes, wherein a sequence of security levels is defined, wherein the first security level in the sequence is defined as the most secure level, and the last security level in the sequence is defined as the least secure level, and wherein the corresponding security of the corresponding security levels in the sequence is defined to decrease from the first security level to the last security level, wherein each corresponding node has a corresponding security certificate associated with the corresponding security level, wherein each node is configured to communicate with other nodes according to a communication protocol, and wherein the communication protocol defines at least the following rules:

[0277] i) A corresponding node having a corresponding certificate associated with a corresponding security level can send a message to a corresponding node having a corresponding certificate associated with any less secure security level in the sequence;

[0278] ii) A corresponding node having a corresponding certificate associated with a corresponding security level can send a message to a corresponding node having a corresponding certificate associated with the next more secure security level adjacent to the corresponding security level in the sequence, but cannot send a message to a corresponding node having a corresponding certificate associated with a corresponding security level that is more secure than the next more secure security level adjacent to the corresponding security level in the sequence;

[0279] iii) A corresponding node having a corresponding certificate associated with a corresponding security level is able to receive a message from a corresponding node having a corresponding certificate associated with a less secure security level adjacent to the corresponding security level in the sequence, but does not receive a message from a corresponding node having a corresponding certificate associated with a corresponding security level that is less secure than the less secure security level adjacent to the corresponding security level in the sequence;

[0280] iv) A corresponding node having a corresponding certificate associated with a corresponding security level is able to receive a message from a corresponding node having a corresponding certificate associated with any more secure security level in the sequence; and,

[0281] wherein 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.

[0282] Statement 2. The method according to Statement 1, wherein the communication protocol defines that messages are sent in encrypted form.

[0283] Statement 3. The method according to Statement 2, wherein the communication protocol defines that messages sent between corresponding nodes having corresponding 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.

[0284] Statement 4. The method according to Statement 3, wherein the communication protocol defines that, in order to send a message between corresponding nodes having corresponding security certificates associated with adjacent security levels in the sequence, the following steps are to be performed:

[0285] The sending node sends a communication request to the receiving node, wherein the communication request includes the corresponding security certificate of the sending node or a reference thereto;

[0286] The receiving node verifies the corresponding security certificate of the sending node;

[0287] The receiving node sends a verification message to the sending node;

[0288] The sending node sends a verification signature to the receiving node, wherein the verification signature is based on the verification message and the private key corresponding to the public key of the sending node; and,

[0289] The receiving node verifies the verification signature.

[0290] Statement 5. The method according to any statement subordinate to statement 2, wherein the communication protocol defines that messages sent between corresponding 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.

[0291] Statement 6. The method according to statement 5, wherein the communication protocol defines that, in order to send a message between corresponding nodes having respective security certificates associated with non-adjacent security levels in the sequence, where the receiving node has a respective security level associated with a more secure level than the sending node, the following steps are to be performed:

[0292] The sending node sends the message to a corresponding node having a security certificate associated with the subsequent more secure security level adjacent to the respective security level in the sequence, and requests the corresponding node to forward the message to the receiving node.

[0293] Statement 7. The method according to any of the preceding statements, wherein each certificate authority in a group of certificate authorities is associated with a respective security level, and each security certificate associated with a respective security level is signed by the respective certificate authority associated with the respective security level.

[0294] Statement 8. The method according to statement 7, wherein each node is configured to communicate with a certificate authority according to the communication protocol, and the communication protocol defines at least the following rules:

[0295] v) A corresponding node having a respective security certificate associated with a respective security level is able to send a message to and receive a message from a respective certificate authority associated with the same respective security level or an adjacent security level in the sequence;

[0296] vi) A corresponding node having a respective security certificate associated with a respective security level is able to obtain a respective security certificate associated with the subsequent more secure security level from a respective certificate authority associated with the subsequent more secure security level in the sequence.

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

[0298] Statement 10. The method according to any of the preceding statements, wherein the respective security certificate includes the respective identifier of the respective node and / or the respective public key of the respective node.

[0299] Statement 11. A computer-implemented method for issuing security certificates for secure communication between a group of nodes, wherein a sequence of security levels is defined, wherein the first security level in the sequence is defined as the most secure level, and the last security level in the sequence is defined as the least secure level, and wherein the corresponding security of the corresponding security levels in the sequence is defined as decreasing from the first security level to the last security level, wherein each corresponding node has a corresponding security certificate associated with a corresponding security level, wherein each certificate authority in a group of certificate authorities is associated with a corresponding security level, wherein each security certificate associated with a corresponding security level is signed by the corresponding certificate authority associated with the corresponding security level, wherein each certificate authority is configured to issue security certificates according to a certificate issuance protocol, and wherein the certificate issuance protocol at least defines the following rules:

[0300] i) A certificate authority associated with a corresponding security level is able to issue a security certificate associated with the same corresponding security level;

[0301] ii) A certificate authority associated with a corresponding security level is able to issue a security certificate to a node having a security certificate whose security level is less secure than and adjacent to the corresponding security level in the sequence, but is not able to issue a security certificate to a node having a security certificate that is less secure than the node having the security certificate whose security level is less secure than and adjacent to the corresponding security level in the sequence;

[0302] iii) A certificate authority associated with a corresponding security level is able to reissue a security certificate to a node having an expired or revoked certificate associated with the same corresponding security level; and,

[0303] wherein the method is executed by a first certificate authority and includes: issuing a security certificate to a requesting node according to the certificate issuance protocol.

[0304] Statement 12. The method according to Statement 11, wherein issuing a security certificate to the requesting node includes:

[0305] Receiving a request from the requesting node, the requesting node having a corresponding security certificate associated with a corresponding security level;

[0306] Determining that a corresponding security certificate associated with a subsequent more secure security level adjacent to the corresponding security level in the sequence can be issued to the requesting node;

[0307] Generating a corresponding security certificate associated with the subsequent more secure security level; and,

[0308] Send the corresponding security certificate or a reference thereto to the requesting node.

[0309] Statement 13. The method according to statement 12, the method comprising:

[0310] Submit a blockchain transaction to a blockchain network, wherein the blockchain transaction comprises the corresponding security certificate or its hash and a signature associated with the first certificate authority.

[0311] Statement 14. The method according to any statement subordinate to statement 11, wherein each certificate authority is configured to communicate with other certificate authorities according to a communication protocol, and wherein the communication protocol at least defines the following rules:

[0312] i) A certificate authority associated with a corresponding security level is capable of communicating with a corresponding certificate authority having a corresponding security certificate associated with an adjacent security level in the sequence; and,

[0313] ii) A certificate authority associated with a corresponding security level is capable of communicating with a corresponding certificate authority having a corresponding security certificate associated with the same corresponding security level.

[0314] Statement 15. A computer device, the computer device comprising:

[0315] A memory, the memory comprising one or more memory units; and,

[0316] A processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to run on the processing device, the code being configured to, when run on the processing device, perform the method according to any one of statements 1 to 14.

[0317] Statement 16. A computer program, the computer program being contained on a computer-readable memory and configured to, when run on one or more processors, perform the method according to any one of statements 1 to 14.

[0318] According to another aspect disclosed herein, a method can be provided, the method comprising actions of the first node and the first certificate authority. According to another aspect disclosed herein, a system can be provided, the system comprising a computer device of the first node and the first certificate authority.

[0319] According to another aspect disclosed herein, a method can be provided, the method comprising actions of the set of nodes. According to another aspect disclosed herein, a system can be provided, the system comprising a computer device of the set of nodes.

[0320] According to another aspect disclosed herein, a method can be provided, the method including actions of the set of certificate authorities. According to another aspect disclosed herein, a system can be provided, the system including computer devices of the set of certificate authorities.

Claims

1. A computer-implemented method for secure communication between a group of nodes, wherein a sequence of security levels is defined, wherein the first security level in the sequence is defined as the most secure level, and the last security level in the sequence is defined as the least secure level, and wherein the corresponding security of the corresponding security levels in the sequence is defined as decreasing from the first security level to the last security level, wherein each corresponding node has a corresponding security certificate associated with the corresponding security level, wherein each node is configured to communicate with other nodes according to a communication protocol, and wherein the communication protocol defines at least the following rules: i) A corresponding node having a corresponding certificate associated with a corresponding security level is able to send a message to a corresponding node having a corresponding certificate associated with any less secure security level in the sequence; ii) A corresponding node having a corresponding certificate associated with a corresponding security level is able to send a message to a corresponding node having a corresponding certificate associated with one or more but not all of the subsequent more secure security levels in the sequence; iii) A corresponding node having a corresponding certificate associated with a corresponding security level is able to receive a message from a corresponding node having a corresponding certificate associated with any one or more but not all of the less secure security levels in the sequence; iv) A corresponding node having a corresponding certificate associated with a corresponding security level is able to receive a message from a corresponding node having a corresponding certificate associated with any more secure security level in the sequence; and wherein 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.

2. The method according to claim 1, wherein the communication protocol defines that messages are sent in encrypted form.

3. The method according to claim 2, wherein the communication protocol defines that messages sent between corresponding nodes having corresponding 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 method according to claim 3, wherein the communication protocol defines that, in order to send a message between corresponding nodes having corresponding security certificates associated with adjacent security levels in the sequence, the following steps are to be performed: The sending node sends a communication request to the receiving node, wherein the communication request includes the corresponding security certificate of the sending node or a reference thereto; The receiving node verifies the corresponding security certificate of the sending node; The receiving node sends a verification message to the sending node; The sending node sends a verification signature to the receiving node, wherein the verification signature is based on the verification message and the private key corresponding to the public key of the sending node; and The receiving node verifies the verification signature.

5. The method according to claim 2 or any of its dependent claims, wherein the communication protocol defines that messages sent between corresponding 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 method according to claim 5, wherein the communication protocol defines that, in order to send a message between corresponding nodes having respective security certificates associated with non - adjacent security levels in the sequence, where the receiving node has a respective security level associated with a more secure level than the sending node, the following steps are to be performed: The sending node sends the message to a corresponding node having a security certificate associated with the subsequent more secure security level adjacent to the respective security level in the sequence and requests the corresponding node to forward the message to the receiving node.

7. The method according to any of the preceding claims, wherein each certificate authority in a group of certificate authorities is associated with a respective security level, and each security certificate associated with a respective security level is signed by the respective certificate authority associated with the respective security level.

8. The method according to claim 7, wherein each node is configured to communicate with a certificate authority according to the communication protocol, and the communication protocol defines at least the following rules: v) A corresponding node having a respective security certificate associated with a respective security level is able to send messages to and receive messages from a corresponding certificate authority associated with the same respective security level or an adjacent security level in the sequence; vi) A corresponding node having a respective security certificate associated with a respective security level is able to obtain a respective security certificate associated with the subsequent more secure security level from a corresponding certificate authority associated with the subsequent more secure security level in the sequence.

9. The method according to any of the preceding claims, wherein part or all of the respective security certificate or its respective hash is stored on a blockchain.

10. The method according to any of the preceding claims, wherein the respective security certificate includes the respective identifier of the respective node and / or the respective public key of the respective node.

11. The method according to any of the preceding claims, wherein for rule ii) of the communication protocol, one or more but not all of the subsequent more secure security levels consist of the subsequent more secure security level adjacent to the respective security level in the sequence.

12. The method according to any of claims 1 to 10, wherein for rule ii) of the communication protocol, one or more but not all of the subsequent more secure security levels include one or more security levels within a threshold number of levels starting from the respective security level in the sequence.

13. The method according to claim 12, wherein the threshold is based on one or more of the following: The total number of levels in the sequence; Security settings defined and / or configured by users of one or more of the corresponding nodes; A formula based on one or more attributes of the set of nodes and / or the sequence of security levels.

14. The method according to any one of the preceding claims, wherein the communication protocol defines at least the following rules: vii) Each corresponding security level is associated with a corresponding most secure security level, a node having a certificate associated with the corresponding security level is able to communicate with the corresponding most secure security level, and wherein for corresponding adjacent security levels, the corresponding most secure security level associated with the less secure adjacent security level is less secure than the corresponding most secure security level associated with the more secure security level.

15. A computer-implemented method for issuing security certificates for secure communication between a set of nodes, wherein a sequence of security levels is defined, wherein the first security level in the sequence is defined as the most secure level and the last security level in the sequence is defined as the least secure level, and wherein the corresponding security of the corresponding security levels in the sequence is defined as decreasing from the first security level to the last security level, wherein each corresponding node has a corresponding security certificate associated with a corresponding security level, wherein each certificate authority in a set of certificate authorities is associated with a corresponding security level, wherein each security certificate associated with a corresponding security level is signed by the corresponding certificate authority associated with the corresponding security level, wherein each certificate authority is configured to issue security certificates according to a certificate issuance protocol, and wherein the certificate issuance protocol defines at least the following rules: i) A certificate authority associated with a corresponding security level is able to issue a security certificate associated with the same corresponding security level; ii) A certificate authority associated with a corresponding security level is able to issue a security certificate to a node having a security certificate such that the security certificate the node has has one or more but not all of the less secure security levels in the sequence; iii) A certificate authority associated with a corresponding security level is able to reissue a security certificate to a node having an expired or revoked certificate associated with the same corresponding security level; and wherein the method is performed by a first certificate authority and includes: Issuing a security certificate to a requesting node according to the certificate issuance protocol.

16. The method according to claim 15, wherein issuing a security certificate to the requesting node comprises: Receiving a request from the requesting node, the requesting node having a corresponding security certificate associated with a corresponding security level; Determining that a corresponding security certificate associated with a subsequent more secure security level can be issued to the requesting node; Generating a corresponding security certificate associated with the subsequent more secure security level; And Sending the corresponding security certificate or a reference thereto to the requesting node.

17. The method according to claim 16, the method comprising: Submit a blockchain transaction to a blockchain network, where the blockchain transaction includes the corresponding security certificate or its hash and a signature associated with the first certificate authority.

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

19. The method according to any one of claims 15 to 18, wherein for rule ii) of the certificate issuance protocol, the one or more but not all of the less secure security levels in the subsequent less secure security levels consist of the less secure security levels adjacent to the corresponding security level in the sequence.

20. The method according to any one of claims 15 to 18, wherein for rule ii) of the certificate issuance protocol, the one or more but not all of the less secure security levels in the subsequent less secure security levels include one or more security levels within a threshold number of levels starting from the corresponding security level in the sequence.

21. The method according to claim 18 or any of its dependent claims, wherein for rule ii) of the communication protocol, the one or more but not all of the subsequent more secure security levels in the subsequent more secure security levels consist of the subsequent more secure security levels adjacent to the corresponding security level in the sequence.

22. The method according to claim 18 or any of its dependent claims, wherein for rule ii) of the communication protocol, the one or more but not all of the subsequent more secure security levels in the subsequent more secure security levels include one or more security levels within a threshold number of levels starting from the corresponding security level in the sequence.

23. The method according to claim 20 or 22, wherein the threshold is based on one or more of the following: The total number of levels in the sequence; Security settings defined and / or configured by users of one or more of the corresponding nodes; A formula based on one or more attributes of the set of nodes and / or the security level sequence.

24. A computer device, the computer device comprising: A memory, the memory including one or more memory units; And A processing device, the processing device including one or more processing units, wherein the memory stores code configured to run on the processing device and, when run on the processing device, execute the method according to any one of claims 1 to 23.

25. A computer program, the computer program being embodied on a computer-readable memory and configured to, when run on one or more processors, execute the method according to any one of claims 1 to 23.

Images