SECURE COMMUNICATIONS IN A BLOCKCHAIN NETWORK

• US 20200136806A1
• Filed: 12/20/2019
• Published: 04/30/2020
• Est. Priority Date: 07/26/2017
• Status: Active Grant

• Current Assignee: Advanced New Technologies Company Limited (Ant Group Co., Ltd.)
• Original Assignee: Alibaba Group Holding Ltd.
• Inventors: Qiu, Honglin
• Granted Patent: US 10,909,269 B2
• Time in Patent Office: Days
• CPC Class Codes: G06F 21/62 Protecting access to data via a platform, e.g. using keys or access control rules
• CPC Class Codes: G06F 21/64 Protecting data integrity, e.g. using checksums, certificates or signatures
• CPC Class Codes: G06Q 2220/00 Business processing using cryptography postage metering system using cryptography G06Q2250/05
• CPC Class Codes: H04L 63/0823 using certificates cryptographic mechanisms or cryptographic arrangements for entity authentication involving certificates H04L9/3263
• CPC Class Codes: H04L 63/166 at the transport layer
• CPC Class Codes: H04L 9/0637 Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
• CPC Class Codes: H04L 9/0825 using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
• CPC Class Codes: H04L 9/30 Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
• CPC Class Codes: H04L 9/3265 using certificate chains, trees or paths; Hierarchical trust model
• CPC Class Codes: H04L 9/3268 using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
• CPC Class Codes: H04W 12/03 Protecting confidentiality, e.g. by encryption

Abstract

A first certificate authority (CA) trust list comprising a plurality of CA identifiers is obtained by a first node of a blockchain network. A communication request comprising a public key certificate of the second node is received by the first node from a second node of the blockchain network. A first CA identifier is determined from the received public key certificate. A determination is made as to whether the first CA identifier matches one of the plurality of CA identifiers of the first CA trust list. In response to determining that the first CA identifier matches one of the plurality of CA identifiers of the first CA trust list, the communication request is approved by the first node. In response to determining that the first CA identifier does not match one of the plurality of CA identifiers of the first CA trust list, the communication request is denied.

Claims

1. A computer-implemented method for improving security of a blockchain network, comprising:

obtaining, by a first node of the blockchain network, a first certificate authority (CA) trust list comprising a plurality of CA identifiers;

receiving, by the first node from a second node of the blockchain network, a communication request comprising a public key certificate of the second node;

determining a first CA identifier from the received public key certificate;

determining whether the first CA identifier matches one of the plurality of CA identifiers of the first CA trust list;

in response to determining that the first CA identifier matches one of the plurality of CA identifiers of the first CA trust list, approving, by the first node, the communication request; and

in response to determining that the first CA identifier does not match one of the plurality of CA identifiers of the first CA trust list, denying, by the first node, the communication request.

2. The computer-implemented method of claim 1, wherein the first node is a consensus node configured to perform consensus verification.

3. The computer-implemented method of claim 1, wherein the blockchain network is a consortium blockchain network.

4. The computer-implemented method of claim 1, wherein obtaining, by a first node of the blockchain network, the first CA trust list comprising the plurality of CA identifiers comprises one of:

pre-configuring the first node with the first CA trust list;

or

receiving, from a CA associated with the first node, the first CA trust list.

5. The computer-implemented method of claim 1, wherein the second node comprises a second CA trust list comprising a plurality of CA identifiers,

wherein approving, by the first node, the communication request comprises:

transmitting, by the first node to the second node, a verification request comprising a public key certificate of the first node, and

wherein the method further comprises;

determining, by the second node, a second CA identifier from the received public key certificate of the first node;

determining whether the second CA identifier matches one of the plurality of CA identifiers of the second CA trust list of the second node;

in response to determining that the second CA identifier matches one of the plurality of CA identifiers of the second CA trust list, establishing a communication session with the first node; and

in response to determining that the second CA identifier does not match one of the plurality of CA identifiers of the second CA trust list, denying, by the second node, establishment of the communication session with the first node.

6. The computer-implemented method of claim 5, wherein the first CA identifier of the public key certificate of the second node is different from the second CA identifier of the public key certificate of the first node.

7. The computer-implemented method of claim 1, wherein receiving, by the first node from the second node of the blockchain network, the communication request comprising the public key certificate of the second node comprises:

receiving, by the first node from the second node, the communication request in accordance with a transport layer security (TLS) handshake protocol.

8. A non-transitory, computer-readable medium storing one or more instructions executable by a computer system to perform operations comprising:

obtaining, by a first node of a blockchain network, a first certificate authority (CA) trust list comprising a plurality of CA identifiers;

receiving, by the first node from a second node of the blockchain network, a communication request comprising a public key certificate of the second node;

determining a first CA identifier from the received public key certificate;

determining whether the first CA identifier matches one of the plurality of CA identifiers of the first CA trust list;

in response to determining that the first CA identifier matches one of the plurality of CA identifiers of the first CA trust list, approving, by the first node, the communication request; and

in response to determining that the first CA identifier does not match one of the plurality of CA identifiers of the first CA trust list, denying, by the first node, the communication request.

9. The non-transitory, computer-readable medium of claim 8, wherein the first node is a consensus node configured to perform consensus verification.

10. The non-transitory, computer-readable medium of claim 8, wherein the blockchain network is a consortium blockchain network.

11. The non-transitory, computer-readable medium of claim 8, wherein obtaining, by a first node of the blockchain network, the first CA trust list comprising the plurality of CA identifiers comprises one of:

pre-configuring the first node with the first CA trust list;

or

receiving, from a CA associated with the first node, the first CA trust list.

12. The non-transitory, computer-readable medium of claim 8, wherein the second node comprises a second CA trust list comprising a plurality of CA identifiers,

wherein approving, by the first node, the communication request comprises:

transmitting, by the first node to the second node, a verification request comprising a public key certificate of the first node, and

wherein the operations further comprise;

determining, by the second node, a second CA identifier from the received public key certificate of the first node;

determining whether the second CA identifier matches one of the plurality of CA identifiers of the second CA trust list of the second node;

in response to determining that the second CA identifier matches one of the plurality of CA identifiers of the second CA trust list, establishing a communication session with the first node; and

in response to determining that the second CA identifier does not match one of the plurality of CA identifiers of the second CA trust list, denying, by the second node, establishment of the communication session with the first node.

13. The non-transitory, computer-readable medium of claim 12, wherein the first CA identifier of the public key certificate of the second node is different from the second CA identifier of the public key certificate of the first node.

14. The non-transitory, computer-readable medium of claim 8, wherein receiving, by the first node from the second node of the blockchain network, the communication request comprising the public key certificate of the second node comprises:

receiving, by the first node from the second node, the communication request in accordance with a transport layer security (TLS) handshake protocol.

15. A computer-implemented system, comprising:

one or more computers; and

one or more computer memory devices interoperably coupled with the one or more computers and having tangible, non-transitory, machine-readable media storing one or more instructions that, when executed by the one or more computers, perform one or more operations comprising;

obtaining, by a first node of a blockchain network, a first certificate authority (CA) trust list comprising a plurality of CA identifiers;

receiving, by the first node from a second node of the blockchain network, a communication request comprising a public key certificate of the second node;

determining a first CA identifier from the received public key certificate;

determining whether the first CA identifier matches one of the plurality of CA identifiers of the first CA trust list;

in response to determining that the first CA identifier matches one of the plurality of CA identifiers of the first CA trust list, approving, by the first node, the communication request; and

in response to determining that the first CA identifier does not match one of the plurality of CA identifiers of the first CA trust list, denying, by the first node, the communication request.

16. The computer-implemented system of claim 15, wherein the first node is a consensus node configured to perform consensus verification.

17. The computer-implemented system of claim 15, wherein the blockchain network is a consortium blockchain network.

18. The computer-implemented system of claim 15, wherein obtaining, by a first node of the blockchain network, the first CA trust list comprising the plurality of CA identifiers comprises one of:

pre-configuring the first node with the first CA trust list;

or

receiving, from a CA associated with the first node, the first CA trust list.

19. The computer-implemented system of claim 15, wherein the second node comprises a second CA trust list comprising a plurality of CA identifiers,

wherein approving, by the first node, the communication request comprises:

transmitting, by the first node to the second node, a verification request comprising a public key certificate of the first node, and

wherein the operations further comprise;

determining, by the second node, a second CA identifier from the received public key certificate of the first node;

determining whether the second CA identifier matches one of the plurality of CA identifiers of the second CA trust list of the second node;

in response to determining that the second CA identifier matches one of the plurality of CA identifiers of the second CA trust list, establishing a communication session with the first node; and

in response to determining that the second CA identifier does not match one of the plurality of CA identifiers of the second CA trust list, denying, by the second node, establishment of the communication session with the first node.

20. The computer-implemented system of claim 19, wherein the first CA identifier of the public key certificate of the second node is different from the second CA identifier of the public key certificate of the first node.