Web of trust management in a distributed system

• US 9,397,835 B1
• Filed: 05/21/2014
• Issued: 07/19/2016
• Est. Priority Date: 05/21/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): Hoffman, Brandon
• Assistant Examiner(s): Anderson, Michael D
• Application Number:
  US14/284,278
• Time in Patent Office: 790 Days
• Field of Search: 713/176
• US Class Current: 1/1
• CPC Class Codes: G06F 12/1408 by using cryptography for digital transmission H04L9/00
• CPC Class Codes: G06F 2212/1016 Performance improvement
• CPC Class Codes: H04L 63/00 Network architectures or network communication protocols for network security cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00; network architectures or network communication protocols for wireless network security H04W12/00; security arrangements for protecting computers or computer systems against unauthorised activity G06F21/00
• CPC Class Codes: H04L 63/06 for supporting key management in a packet data network cryptographic mechanisms or cryptographic arrangements for key management H04L9/08
• CPC Class Codes: H04L 63/12 Applying verification of the received information cryptographic mechanisms or cryptographic arrangements for data integrity or data verification H04L9/32
• CPC Class Codes: H04L 63/20 for managing network security; network security policies in general filtering policies H04L63/0227
• 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/0897 involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
• 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/50 using hash chains, e.g. blockchains or hash trees

Abstract

A web of trust is used to validate states of a distributed system. The distributed system operates based at least in part on a domain trust. A root of trust issues the domain trust issues a domain trust. Domain trusts are updatable in accordance with rules of previous domain trusts so that a version of a domain trust is verifiable by verifying a chain of previous domain trust versions.

Claims

1. A computer-implemented method, comprising:

under the control of one or more computer systems that execute instructions,

obtaining a first version of a domain trust, the first version of the domain trust specifying;

a set of security modules authorized to perform cryptographic operations;

a set of operators; and

a set of quorum rules specifying one or more conditions for a plurality of operators in a subset of the set of operators being authorized to update the domain trust;

obtaining a second version of the domain trust, the second version of the domain trust digitally signed by a first security module; and

as a result of the first security module being outside of the set of security modules specified by the first version of the domain trust, updating to the second version of the domain trust on a condition that the second version of the domain trust is cryptographically verified as a valid successor of the first version of the domain trust, the second version of the domain trust being a valid successor to the first version of the domain trust as a result of being in a chain of domain trust versions including the first version of the domain trust, where each domain trust version in the chain of domain trust versions is generated in compliance with the set of quorum rules of an immediately preceding domain trust version.

2. The computer-implemented method of claim 1, wherein specification of the first security module in an intermediate version of the domain trust, between the first version of the domain trust and the second version of the domain trust, is sufficient for the second version of the domain trust to be a valid successor of the first version of the domain trust.

3. The computer-implemented method of claim 1, wherein updating to the second version of the domain trust requires cryptographic verification of every domain trust in the chain of domain trusts, from the first version of the domain trust to the second version of the domain trust.

4. The computer-implemented method of claim 1, wherein the method further comprises:

at a time after updating to the second version of the domain trust, transmitting a request whose fulfillment includes performance of a cryptographic operation;

receiving a response to the request that is digitally signed by a particular security module; and

utilizing the response to the request on a condition that the particular security module is specified in the second version of the domain trust.

5. A system, comprising one or more processors and, memory comprising executable instructions that;

when executed by the one or more processors, cause the system to;

obtain a first version of a domain trust, the first version of the domain trust specifying a first set of operators and a first set of quorum rules defining one or more conditions for a plurality of operators in a subset of the first set of operators being authorized to update the first version of the domain trust;

obtain a second version of the domain trust, the second version of the domain trust being different from the first version of the domain trust;

determine whether the second version of the domain trust is cryptographically verified as a valid successor of the first version of the domain trust; and

as a result of determining that the second version of the domain trust is cryptographically verified as a valid successor to the first version of the domain trust, operate in accordance with the second version of the domain trust.

6. The system of claim 5, wherein the executable instructions that cause the system to determine whether the second version of the domain trust is a valid successor of the first version of the domain trust, when executed by the one or more processors, cause the system to cryptographically verify that the second version of the domain trust is in a chain of domain trust versions including the first version of the domain trust, where each domain trust version in the chain of domain trust versions is authorized in compliance with a set of quorum rules of an immediately preceding domain trust version.

7. The system of claim 5, wherein the executable instructions include instructions that, when executed by the one or more processors, further cause the system to, at a time after determining that the second version of the domain trust is cryptographically verified as a valid successor to the first version of the domain trust:

verify a remote attestation of executable code of a second security module;

as a result of successful verification of the remote attestation, obtain authorization from a quorum of operators defined by the second version of the domain trust to add the second security module to the domain trust; and

cause a security module specified in the second version of the domain trust to cryptographically validate a third version of the domain trust that specifies the second security module.

8. The system of claim 7, wherein causing the security module specified in the second version of the domain trust to cryptographically verify the third version of the domain trust comprises providing proof of the obtained authorization, the proof comprising a digital signature from each operator of a set of operators specified in the second version of the domain trust.

9. The system of claim 5, wherein the system is an operator specified in the first set of operators.

10. The system of claim 5, wherein the instructions further include instructions that, when executed by the one or more processors, cause the system to upon determining that the second version of the domain trust is cryptographically verified as a valid successor of the first version of the domain trust, replace configuration information corresponding to the first version of the domain trust with configuration information corresponding to the second version of the domain trust.

11. The system of claim 5, wherein the first version of the domain trust differs from a previous version of the domain trust and the instructions further include instructions that, when executed by the one or more processors;

cause the system to;

obtain a third version of the domain trust that differs from the second version of the domain trust at least by specifying a different set of operators or a different set of quorum rules than specified by the second version of the domain trust;

obtain authorization to issue the third version of the domain trust from a quorum of operators, the quorum determined based at least in part on a set of quorum rules specified by the second version of the domain trust; and

transmit the obtained third version of the domain trust to a security module specified in the second version of the domain trust with proof of the obtained authorization to issue the second version of the domain trust.

12. The system of claim 5, wherein:

the first version of the domain trust specifies a security module at is unspecified in the second version of the domain trust; and

the instructions that cause the system to operate in accordance with the second version of the domain trust;

as a result of the second version of the domain trust being cryptographically verified as a valid successor of the first version of the domain trust, cause the system to reject at least one result of a cryptographic operation performed by the security module that is unspecified in the second version of the domain trust.

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

store a first version of information issued by a domain trust, the first version of the information specifying at least a first set of operators and a first set of quorum rules defining one or more conditions on a plurality of operators in a subset of the first set of operators for creation of an updated version of the information from the first version of the information;

obtain a second version of the information that specifies a set of computer systems authorized to perform operations, a plurality of operators in a second set of operators, and a second set of quorum rules defining one or more conditions on the second set of operators for creation of an updated version of the information from the second version of the information; and

cryptographically validate the second version of the information as a valid successor to the first version of the information on a condition that the second version obtained was authorized by a subset of the first set of operators in accordance with the first set of quorum rules.

14. The non-transitory computer-readable storage medium of claim 13, wherein the first information specifies a set of security modules and the operations are cryptographic operations.

15. The non-transitory computer-readable storage medium of claim 13, wherein the second set of operators is different from the first set of operators.

16. The non-transitory computer-readable storage medium of claim 13, wherein the second set of quorum rules is different from the first set of quorum rules.

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

receive a third version of the information from an entity unspecified in the second version of the information; and

verify the third version of the information by verifying at least one intermediate version of the information between the second version and the third version.

18. The non-transitory computer-readable storage medium of claim 17, wherein verification of the intermediate version of the information includes verification that the intermediate version of the information was authorized by a quorum of operators specified in the second version of the information, the quorum determined based at least in part on the second set of quorum rules.

19. The non-transitory computer-readable storage medium of claim 13, wherein said cryptographic validation of the second version of the information includes digitally signing the second version of the information using a private cryptographic key.

20. The non-transitory computer-readable storage medium of claim 13, wherein the instructions further include instructions that, when executed by the one or more processors, cause the computer system to generate a new version of a domain token that includes the second version of the information that was cryptographically validated.

21. The non-transitory computer-readable storage medium of claim 20, wherein the instructions further include instructions that, when executed by the one or more processors, cause the computer system to, at a time after generation of the new version of the domain token, generate a second new version of the domain token that includes the second version of the information.

22. The non-transitory computer-readable storage medium of claim 13, wherein the information is a domain trust.