# US 10,484,346 B2 · Establishment of consortium blockchain network

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 10,484,346 B2
- Document ID: US10484346B2
- Status: Granted
- Kind: B2
- Application number: 15/638,180
- Filed: 2017-06-29
- Published: 2018-08-09
- Granted: 2019-11-19
- Earliest claimed: 2017-02-07
- Assignees: Microsoft Technology Licensing, LLC
- Applicants: Microsoft Technology Licensing, LLC
- Inventors: Mark Russinovich; Manuel Costa; Matthew Kerner; Thomas Moscibroda
- Web page: https://patentgrep.com/patent/US10484346B2

## CPC

- H04L 63/0435: {wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption (cryptographic mechanisms or cryptographic arrangements for symmetric key encryption H04L9/06)}
- G06F 21/53: by executing in a restricted environment, e.g. sandbox or secure virtual machine
- G06F 21/57: Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F 21/74: operating in dual or compartmented mode, i.e. at least one secure mode
- G06Q 20/00: Payment architectures, schemes or protocols (apparatus for performing or posting payment transactions G07F7/08, G07F19/00; electronic cash registers G07G1/12)
- G06Q 20/02: involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
- G06Q 20/065: {using e-cash}
- G06Q 20/3829: {involving key management}
- G11B 20/00282: {the key being stored in the content area, e.g. program area, data area or user area (key stored in a management area G11B20/00297)}
- H04L 9/0637: {Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]}
- H04L 9/3236: {using cryptographic hash functions}
- H04L 9/3265: {using certificate chains, trees or paths; Hierarchical trust model}
- H04L 63/062: {for key distribution, e.g. centrally by trusted party (cryptographic mechanisms or cryptographic arrangements for key distribution involving a central third party H04L9/0819)}
- H04L 63/065: {for group communications (cryptographic mechanisms or cryptographic arrangements for key management involving conference or group key H04L9/0833)}
- H04L 63/08: {for authentication of entities (cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32)}
- H04L 63/10: {for controlling access to devices or network resources}
- H04L 63/101: {Access control lists [ACL]}
- H04L 63/104: {Grouping of entities}
- H04L 63/12: {Applying verification of the received information (cryptographic mechanisms or cryptographic arrangements for data integrity or data verification H04L9/32)}
- H04L 63/123: {received data contents, e.g. message integrity}
- H04W 4/06: Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
- H04L 9/0833: {involving conference or group key (network architectures or network communication protocols for key management in group communication in a packet data network H04L63/065)}
- H04L 9/3242: {involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC}
- H04L 9/3255: {using group based signatures, e.g. ring or threshold signatures}
- H04L 9/50: {using hash chains, e.g. blockchains or hash trees}
- H04L 2209/127: Trusted platform modules [TPM]
- H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M)
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)
- G06Q: INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G11B: INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER (recording measured values in a way that does not require playback through a transducer G01D9/00; recording or playback apparatus using mechanically marked tape, e.g. punched paper tape, or using unit records, e.g. punched or magnetically marked cards G06K; transferring data from one type of record carrier to another G06K1/18; circuits for coupling output of reproducer to radio receiver H04B1/20; gramophone pick-ups or like acoustic electromechanical transducers or circuits therefor H04R)
- H04W: WIRELESS COMMUNICATION NETWORKS (broadcast communication H04H; communication systems using wireless links for non-selective communication, e.g. wireless extensions H04M1/72)

## Abstract

The disclosed technology is generally directed to blockchain and other security technology. In one example of the technology, a first node is endorsed. During endorsement of a first node, a pre-determined type of blockchain or other security protocol code to be authorized and a pre-determined membership list are stored in a trusted execution environment (TEE) of the first node. A determination is made as to whether the membership lists and pre-determined blockchain or other security protocol code to be authorized from the proposed members match. If so, TEE attestation is used to verify that nodes associated with prospective members of the consortium store the pre-determined type of blockchain or other security protocol code to be authorized. Upon TEE attestation being successful, a consortium network is bootstrapped such that the prospective members become members of the consortium network.

## Claims

### Claim 1

An apparatus for a blockchain system, comprising:
a device including at least one memory adapted to store run-time data for the device, and at least one processor that is adapted to execute processor-executable code that, in response to execution, enables the device to perform actions, including:
storing pre-determined code of a pre-determined type of blockchain protocol code in a trusted execution environment (TEE) of a first validation node;
storing, in the first validation node: a first pre-determined membership list of a consortium, wherein the first pre-determined membership list includes a prospective member associated with the first validation node and a first authorization associated with the pre-determined type of blockchain protocol code;
receiving, from a plurality of prospective members of the consortium: a plurality of membership lists, and a plurality of authorizations from the plurality of prospective members of the consortium, wherein the plurality of authorizations are indications associated with the pre-determined type of blockchain protocol code;
making a determination as to whether the plurality of membership lists from the plurality of prospective members of the consortium match the first pre-determined membership list and the plurality of authorizations that are indications associated with the pre-determined type of blockchain protocol code match the first authorization;
upon determining that the plurality of membership lists from the plurality of prospective members of the consortium match the first pre-determined membership list and that the plurality of authorizations that are indications associated with the pre-determined type of blockchain protocol code match the first authorization, verifying, via TEE attestation, that validation nodes associated with prospective members of the consortium store the pre-determined type of blockchain protocol code that matches the first authorization; and
upon the TEE attestation being successful, bootstrapping a consortium network such that the prospective members become members of the consortium network.

### Claim 2 (depends on 1)

The apparatus of claim 1, the actions further including storing a public/private key pair in the TEE of the first validation node.

### Claim 3 (depends on 1)

The apparatus of claim 1, wherein bootstrapping the consortium network further includes generating a blockchain master key.

### Claim 4 (depends on 1)

The apparatus of claim 1, the actions further comprising:
discovering other validation nodes associated with the plurality of prospective members; and
receiving a private key from each of the other validation nodes.

### Claim 5

A method for a blockchain system, comprising:
endorsing a first node, including: storing pre-determined code of the pre-determined type of blockchain protocol code in a trusted execution environment (TEE) of the first node; storing, in the first node, a first pre-determined membership list of a consortium, wherein the first pre-determined membership list includes a prospective member associated with the first node; and storing, in the first node, a first authorization associated with the pre-determined type of blockchain protocol code;
receiving, from a plurality of prospective members of the consortium: a plurality of membership lists, and a plurality of authorizations from the plurality of prospective members of the consortium, wherein the plurality of authorizations are indications associated with the pre-determined type of blockchain protocol code;
determining whether the plurality of membership lists from the plurality of prospective members of the consortium match the first pre-determined membership list and the plurality of authorizations that are indications associated with the pre-determined type of blockchain protocol code match the first authorization;
upon determining that the plurality of membership lists from the plurality of prospective members of the consortium match the first pre-determined membership list and that the plurality of authorizations that are indications associated with the pre-determined type of blockchain protocol code match the first authorization, using TEE attestation to verify that nodes associated with prospective members of the consortium store the pre-determined type of blockchain protocol code that matches the first authorization; and
upon the TEE attestation being successful, bootstrapping a consortium network such that the prospective members become members of the consortium network.

### Claim 6 (depends on 5)

The method of claim 5, wherein endorsing the first node further includes storing a public/private key pair in the TEE of the first node.

### Claim 7 (depends on 5)

The method of claim 5, wherein bootstrapping the consortium network further includes generating a blockchain master key.

### Claim 8 (depends on 5)

The method of claim 5, further comprising receiving a public transaction key associated with a participant.

### Claim 9 (depends on 5)

The method of claim 5, wherein determining whether the plurality of membership lists from the plurality of prospective members of the consortium match the first pre-determined membership list and the plurality of authorizations that are indications associated with the pre-determined type of blockchain protocol code match the first authorization further includes determining whether there is a match among at least one of the following: a type of TEE, a type of processor, a software version of blockchain protocol code, or a type of Confidential Consortium (COCO) Blockchain framework.

### Claim 10 (depends on 5)

The method of claim 5, wherein the TEE includes at least one protected region in a processor in the first node.

### Claim 11 (depends on 10)

The method of claim 10, wherein the TEE includes two separate protected regions in the processor in the first node.

### Claim 12 (depends on 5)

The method of claim 5, further comprising discovering other nodes associated with the plurality of prospective members.

### Claim 13 (depends on 12)

The method of claim 12, further comprising receiving a private key from each of the other nodes.

### Claim 14 (depends on 12)

The method of claim 12, wherein endorsing the first node further includes storing a public/private key pair in the TEE of the first node.

### Claim 15 (depends on 14)

The method of claim 14, further comprising establishing a trusted connection with at least one of the other nodes via creation of a mutually-authenticated secure tunnel built on public keys of the communicating nodes.

### Claim 16 (depends on 14)

The method of claim 14, further comprising, upon the TEE attestation being successful, exchanging the private key with each of the other nodes.

### Claim 17 (depends on 16)

The method of claim 16, further comprising:
receiving a private key from each of the other nodes, wherein bootstrapping the consortium network further includes generating a blockchain master key from the private keys.

### Claim 18

A processor-readable storage medium, having stored thereon process-executable code that, upon execution by at least one processor, enables actions, comprising:
determining whether a plurality of membership lists from plurality of prospective members of a consortium match a first pre-determined membership list and a plurality of authorizations indicate that a pre-determined type of security protocol code matches a first authorization;
upon determining that the plurality of membership lists from the plurality of prospective members of the consortium match the first pre-determined membership list and that the plurality of authorizations that are indications that the pre-determined type of security protocol code matches the first authorization, using trusted execution environment (TEE) attestation to verify that nodes associated with prospective members of the consortium store the pre-determined type of security protocol code that matches the first authorization; and
upon the TEE attestation being successful, bootstrapping a consortium network such that the prospective members become members of the consortium network.

### Claim 19 (depends on 18)

The processor-readable storage medium of claim 18, the actions further comprising storing a public/private key pair in a TEE of a first node.

### Claim 20 (depends on 18)

The processor-readable storage medium of claim 18, wherein bootstrapping the consortium network further includes generating a blockchain master key.