Distributed system web of trust provisioning

• US 9,866,392 B1
• Filed: 09/15/2014
• Issued: 01/09/2018
• Est. Priority Date: 09/15/2014
• Status: Active Grant

• Current Assignee: Amazon Technologies, Inc. (Amazon.com, Inc.)
• Original Assignee: Amazon Technologies, Inc. (Amazon.com, Inc.)
• Inventors: Campagna, Matthew John, Roth, Gregory Branchek
• Primary Examiner(s): Zecher, Dede
• Assistant Examiner(s): McCoy, Richard A
• Application Number:
  US14/486,741
• Time in Patent Office: 1,212 Days
• Field of Search: None
• CPC Class Codes: H04L 9/0822 using key encryption key
• 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/0891 Revocation or update of secret information, e.g. encryption key update or rekeying
• CPC Class Codes: H04L 9/14 using a plurality of keys or algorithms
• CPC Class Codes: H04L 9/3234 involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token network architectures or network communication protocols for supporting authentication of entities using an additional device in a packet data network H04L63/0853
• CPC Class Codes: H04L 9/3247 involving digital signatures
• CPC Class Codes: H04L 9/3265 using certificate chains, trees or paths; Hierarchical trust model
• CPC Class Codes: H04L 9/50 using hash chains, e.g. blockchains or hash trees

Abstract

A web of trust in a distributed system is established. A root of trust for at least two components in the distributed system validates information for the distributed system. The validated information is then used to create additional information for the distributed system. Versions of the information are usable to validate subsequent versions of the information such that validation of a version of the information can be performed by using one or more previous versions to verify that the version is a valid successor of a previously validated previous version.

Claims

1. A computer-implemented method, comprising:

obtaining an initial version of a domain trust and a digital signature of the initial version of the domain trust, the initial version specifying a set of operators and a set of quorum rules, the quorum rules specifying one or more conditions for subsets of the set of operators being authorized to create a new domain trust, the digital signature having been generated by a root of trust;

determining, based at least in part on the digital signature and a cryptographic key associated with the root of trust, whether the digital signature was generated by the root of trust;

receiving a command to create a second version of the domain trust, the second version of the domain trust specifying a second set of operators, a second set of quorum rules, and a set of security modules;

determining whether the command was authorized by a subset of the set of operators that satisfies the set of quorum rules specified by the initial version of the domain trust;

as a result of determining that the digital signature was generated by the root of trust and that the new domain trust was authorized by the subset of the set of operators that satisfies the set of quorum rules, using a second cryptographic key to generate a digital signature of the second version of the domain trust, the second cryptographic key being such that the digital signature is usable by a first security module in the set of security modules to cryptographically verify that the second version of the domain trust was authorized by a security module root of trust; and

providing the second version of the domain trust and the digital signature of the second version of the domain trust to enable performance of cryptographic operations in accordance with the second version of the domain trust by a second security module specified in the second version of the domain trust.

2. The computer-implemented method of claim 1, wherein:

the method further comprises providing an attestation of executable code, the attestation generated using a third cryptographic key associated with a second root of trust; and

providing the attestation enables the command to be transmitted by a computer system that operates with successful validation of the attestation as a condition precedent to transmission of the command.

3. The computer-implemented method of claim 1, wherein determining whether the command was authorized by a subset of the set of operators that satisfies the set of quorum rules specified by the initial version of the domain trust comprises verifying multiple digital signatures each corresponding to a respective operator of the set of operators.

4. A system, comprising one or more processors and memory including instructions that, when executed by the one or more processors, cause the system to:

implement a first computer system, the first computer system configured to;

obtain an initial version of a domain trust, the initial version of the domain trust being cryptographically verifiable as authorized by a root of trust and specifying a first set of conditions for executing a command to create another version of the domain of trust, authorization by a quorum of operators satisfying one or more of the first set of conditions for executing the command, and the quorum of operators comprising a plurality of operators;

cryptographically verify that the initial version of the domain trust was authorized by the root of trust;

verify that the first set of conditions for executing the command are satisfied; and

as a result of the first set of conditions for executing the command being satisfied, create a second version of the domain trust, the second version of the domain trust specifying a second set of conditions for participation in a distributed system.

5. The system of claim 4, wherein the instructions, when executed by the one or more processors, further-cause the system to use the second version of the domain trust to verify, without a cryptographic key associated with the root of trust, validity of another version of the domain trust subsequent to the second version of the domain trust.

6. The system of claim 4, wherein the instructions, when executed by the one or more processors, further-cause the system to:

after creating the second version of the domain trust, receive a command to install the second version of the domain trust; and

fulfill the received command by reconfiguring to operate in accordance with the second version of the domain trust.

7. The system of claim 4, wherein the distributed system implements a cryptographic domain.

8. The system of claim 4, wherein the created second version of the domain trust is cryptographically verifiable as authorized by the first computer system.

9. The system of claim 4, wherein the set of conditions for creating another domain trust comprise one or more conditions specifying entities authorized to issue a command to create the other domain trust.

10. The system of claim 4, wherein satisfaction of the set of conditions requires authorization by a subset of a set of operators that forms a quorum of operators defined by the set of conditions.

11. The system of claim 4, wherein the initial version of the domain trust is obtained from an operator specified in the initial version of the domain trust.

12. The system of claim 4, wherein the system further comprises a set of operator computer systems specified by the initial version of the domain trust and at least a subset of the operator computer systems in compliance with the set of conditions is authorized to cause creation of the other domain trust.

13. The system of claim 4, wherein:

the first computer system is configured to cause a cryptographically verifiable attestation of executable code of the first computer system to an operator computer system of the operator computer system; and

the operator computer system is configured to require successful verification of the attestation to issue a command to cause creation of the domain trust.

14. The system of claim 4, wherein the other version of the domain trust specifies a set of security modules authorized to perform cryptographic operations.

15. The system of claim 4, wherein the first computer system is further configured to, as a result of the set of conditions for creating another domain trust being satisfied, create a domain token that includes a set of cryptographic keys.

16. One or more non-transitory computer-readable storage media having stored thereon executable instructions that, when executed by one or more processors of a computer system, cause the computer system to at least:

receive an attestation of at least executable code utilized by a security module, the attestation chaining to a root of trust;

cryptographically verify, based at least in part on a cryptographic key associated with the root of trust, that the attestation indicates a valid state of the security module;

as a result of cryptographically verifying that the attestation indicates the valid state of the security module, obtain authorization from a quorum of operators to create a domain, the quorum defined by a set of conditions specified in an initial version of a domain trust stored by the security module; and

cause the security module to use the initial version of the domain trust to determine whether to perform an operation.

17. The one or more non-transitory computer-readable storage media of claim 16, wherein:

the instructions that cause the computer system to cause the security module to use the initial version of the domain trust to determine whether to perform an operation, when executed by the one or more processors, cause the computer system to transmit a command and cryptographic proof of authorization by the quorum of the command to the security module; and

the operation comprises fulfillment of the command.

18. The one or more non-transitory computer-readable storage media of claim 16, wherein the instructions further comprise instructions that, when executed by the one or more processors, cause the computer system to provide the initial version of the domain trust to the security module.

19. The one or more non-transitory computer-readable storage media of claim 18, wherein the initial version of the domain trust is cryptographically verifiable using a cryptographic key associated with a second root of trust different from the root of trust.

20. The one or more non-transitory computer-readable storage media of claim 16, wherein:

the instructions that cause the computer system to obtain authorization from the quorum of operators to create the domain, when executed by the one or more processors, cause the computer system to obtain a set of digital signatures comprising a digital signature from each operator of the quorum of operators; and

the authorization is based at least in part on the obtained set of digital signatures.

21. The one or more non-transitory computer-readable storage media of claim 16, wherein creation of the domain includes creation of a new version of the domain trust cryptographically verifiable using a cryptographic key associated with the security module.

22. The one or more non-transitory computer-readable storage media of claim 21, wherein the instructions further include instructions that, when executed by the one or more processors, cause the computer system to:

receive the new version of the domain trust from the security module;

cryptographically verify the new version of the domain trust based at least in part on the cryptographic key; and

operate in accordance with whether cryptographic verification of the new version of the domain trust is successful.

23. The one or more non-transitory computer-readable storage media of claim 16, wherein:

the operation comprises generating a new version of the domain trust; and

the instructions further include instructions that, when executed by the one or more processors, cause the computer system to provide the initial version of the domain trust and the new version of the domain trust to another security module thereby causing the other security module to use the initial version of the domain trust to determine whether to use the new version of the domain trust.

24. The one or more non-transitory computer-readable storage media of claim 16, wherein is the attestation is generated using a trusted platform module of the security module.