Certificate validation using multiple key pair root certificate authorities

Abstract

In a general aspect, a cryptographic system includes a multiple key pair root certificate authority. In some aspects, a query regarding the validity of an identified root certificate of the root certificate authority (CA) is received from an entity. The validity of the identified root certificate is cryptographically verified against a cryptographically authenticated database representing the root certificate authority. The cryptographically authenticated database includes a plurality of different root certificates of the root CA, including the identified root certificate. The cryptographically authenticated database also includes validity information representing the validity or invalidity of each of the plurality of different root certificates. A determination regarding the validity of the identified root certificate is provided to the entity.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This patent application claims priority to U.S. Provisional Patent Application No. 63 / 391,465, entitled "Multiple Key Pair Root Certificate Authority," filed July 22, 2022, the entire disclosure of which is incorporated by reference. [Background technology]

[0002] The following description relates to a multiple key pair root certificate authority for a cryptographic system.

[0003] Cryptography systems are used to communicate securely over public channels. For example, some cryptosystems provide confidentiality by encrypting messages, and some provide authenticity through digital signatures. Some cryptosystems operate using public keys, private keys, and shared secrets. [Brief explanation of the drawings]

[0004] [Figure 1A] 1 is a schematic diagram of an exemplary communication system.

[0005] [Figure 1B] 1B is a schematic diagram of an exemplary cryptographically authenticated chain of data block 120 of FIG. 1A. [Figure 1C] FIG. 2 is a block diagram of an exemplary computer system of a root certificate authority. [Figure 2A] FIG. 1 is a schematic diagram of an exemplary initial block of a chain of cryptographically authenticated data blocks associated with a root certificate authority. [Figure 2B] FIG. 2B is a schematic diagram of a cryptographically authenticated chain of data blocks showing the example initial block and example action block of FIG. 2A.

[0006] [Figure 2C]FIG. 2B is a schematic diagram of a certificate chain originating from the root certificate of the example initial block of FIG. 2A. [Figure 3] FIG. 1 is a schematic diagram illustrating an exemplary process for generating a cryptographically authenticated chain of data blocks. [Figure 4] FIG. 2 is a schematic diagram illustrating an exemplary process for validating a root certificate.

[0007] [Figure 5] FIG. 1 is a block diagram of an exemplary computer system.

[0008] [Figure 6] FIG. 1 is a schematic diagram illustrating an exemplary process for generating a cryptographically authenticated database of root certificates. DETAILED DESCRIPTION OF THE INVENTION

[0009] In some aspects of what is described herein, a cryptographic system includes a root certificate authority (root CA) with multiple key pairs. In some aspects, implementations of the systems and techniques described herein provide technical advantages or improvements over existing technology. As one example, damage caused by compromise of a root certificate authority's private key (e.g., a security compromise resulting from an attack, technical malfunction, or other event) can be prevented by using a root certificate authority with multiple key pairs. For example, a root certificate authority with multiple key pairs can provide a protocol or another formal mechanism for revoking the public key corresponding to a compromised private key, or in some cases, for completely removing the problematic root certificate. As another example, the validity of a root certificate can be modified (e.g., revoked or restored), audited, and cryptographically verified by other entities in the cryptographic system. For example, a cryptographically authenticated database can provide public proof that a root certificate is valid or invalid. End entities can query the status of a root certificate, and the root CA can provide cryptographically verifiable status information.

[0010] Accordingly, aspects of the systems and techniques described herein can be used to improve the operation of communication systems (such as data networks), computer systems (such as networked computers), smart devices (such as so-called "Internet of Things (IoT)" devices), and other classes of technology. For example, a wide variety of modern technologies rely on computer-implemented cryptographic systems for secure operation, and the techniques described herein can improve such computer-implemented cryptographic systems, making them, for example, more secure, more efficient, or possibly providing other advantages.

[0011] Public key cryptography is widely deployed in various technologies to achieve secure authentication, secret key sharing, and so on. Public keys can be used to validate digital signatures to verify the identity of communicating parties or to establish shared secrets to securely encrypt messages. The security provided by public key cryptography typically relies on received public keys being securely bound to legitimate identities in a trustworthy manner. Without such secure binding, an entity could unknowingly trust the identity of a malicious party masquerading as the intended party, or send a message to a false recipient who is actually an adversary. Public key infrastructure (PKI) systems have been used to establish trust in public keys that are bound to legitimate identities.

[0012] PKI is currently the most widely deployed mechanism for establishing trust in cryptographic systems. Traditionally, PKI systems build a hierarchical tree of trust starting from a trusted entity called a root certificate authority (root CA), which presents itself as the root of trust. In a typical PKI system, a certificate authority (CA) verifies that a public key belongs to an identity, binds the two with a digital signature, and issues this binding in the form of a digital certificate. Any party in the cryptographic system (such as an end entity) can verify the binding between a public key and an identity by validating the CA's digital signature on the certificate using the CA's public key. Because this validation operation uses the CA's public key, the CA's public key must also be trusted. Therefore, there must be a parent CA that vouches for this public key by issuing a signed certificate. Thus, certificates chain to a root certificate authority to establish trust, but this chain must end somewhere. The last certificate in the chain is a root certificate, which belongs to a root CA. This root CA acts as the root of trust and is represented by a certificate called a root certificate. Root certificates are self-signed because there is no third-party CA above them to provide a guarantee. Therefore, root certificates are trusted differently. Typically, methods such as public or private communication are used to trust a root certificate.

[0013] Traditional PKI systems face certain technical challenges and vulnerabilities. One of the most significant vulnerabilities in a PKI system is the root CA, as it can be a single point of failure. Compromise of the root CA can potentially cause a catastrophic breakdown in the security of the entire system. An attacker in possession of the private key of a compromised root CA can issue certificates that can be verified by the root certificate. This means that the attacker can impersonate any entity in the system, potentially resulting in a catastrophic breakdown in the security and trust of the entire system. Therefore, a technology platform that provides multiple key pairs for root CAs can provide improved security and efficiency, for example, preventing or otherwise avoiding or mitigating the damage caused by the compromise of a single root certificate.

[0014] Because traditional PKI systems lack a trusted entity above the root certification authority that is authorized to revoke root certificates, they may be inadequately prepared for a catastrophic failure resulting from the compromise of a root CA's private key. For example, systems that do not provide any formal mechanism for revoking root certificates or any mechanism for users to identify root certificates that are no longer valid may be vulnerable. Instead, users of such traditional PKI systems have relied on announcements (e.g., including "optional" software updates) and word of mouth to identify compromised root certificates. Therefore, a technology platform that allows for the establishment of a more systematic method for representing and identifying revoked root certificates would provide improved security and efficiency.

[0015] In some implementations, a root CA with multiple key pairs can provide technical advantages over, for example, traditional PKI systems. For example, a multiple key pair root CA system can provide a trust mechanism whereby the validity of a root certificate can be verified against a cryptographically authenticated database representing the root CA. In some examples, the cryptographically authenticated database can include a collection of related encrypted data that is stored, organized, and accessed electronically, for example, via a database management system. In various implementations, such a database can be hosted, for example, on a computer cluster, cloud storage, a peer network, etc. The encrypted database can provide confidentiality and data integrity. Thus, if the database records any past changes, it can provide a history of those changes. In some cases, the change history and data can be proven to be authentic. Furthermore, if a distributed (redundant) database is used, backups will exist to further establish the validity of the data. In some cases, applying digital signatures to data stored in the database can simplify the process of proving the validity of the data.

[0016] An example of such a cryptographically authenticated database is, for example, a cryptographically authenticated chain of data blocks. For purposes of discussion, aspects of the present disclosure are described below as utilizing a cryptographically authenticated chain of data blocks. However, in various implementations, other types of cryptographically authenticated databases may be used. For example, some implementations may utilize other types of databases that can provide at least to a trusted third party, preferably the public, proof of data integrity and authentication by the owner of a private key, enforcement of data integrity on stored data, and a change history, if provided and audited. Implementations that utilize a cryptographically authenticated chain of data blocks have the added advantage of not requiring the disclosure of the private key. Such functionality can provide stronger authentication of the data.

[0017] In a system having a root CA with multiple key pairs, instead of using a single root certificate associated with the root CA, for example, a multi-certificate root of trust can be used. The multi-certificate root of trust can be represented in a data set, for example, by a chain of data blocks containing the identities and public keys of multiple root certificates. Because a multi-key pair root CA has multiple root certificates, a single root certificate is not a single point of failure. The chain of cryptographically authenticated data blocks representing the multiple key pair CAs can be published, broadcast, or distributed for use in a cryptographic system (e.g., just as traditional root certificates are published, broadcast, or distributed). The chain of cryptographically authenticated data blocks also allows for dynamic changes to the root CA, for example, by adding new data blocks to the chain representing new certificates or the revocation of existing root certificates, thus providing flexibility and allowing for the revocation of root certificates.

[0018] In some instances, a root CA with multiple key pairs (multi-key pair root CA) provides redundancy as well as the ability to revoke and query the status of root certificates. Additionally, in some cases, a multi-key pair root CA can validate root certificates with signatures that are not self-signed. In various implementations, a multi-key pair root CA uses a chain of data blocks authenticated using digital signatures. In various implementations, the structure of the initial data block and subsequent data blocks can be configured to provide backward compatibility with legacy systems that may distribute standard root certificates.

[0019] In various implementations, a root CA possesses multiple key pairs that are independently controlled and managed. For example, damage caused by the compromise of a single root CA private key can be prevented because the root CA's other private keys remain uncompromised. A multi-key root CA also provides a mechanism for revoking certificates corresponding to a CA's compromised root key pair. Signature verification of a chain of data blocks also provides confirmation of the identity information (used to validate the root certificate) and the binding of the associated key pair. In various implementations, status inquiries of the root CA's public key or certificate are made available. A standard certificate chain can be constructed under each root CA key pair, for example, by one or more subordinate (e.g., intermediate) certificate authorities.

[0020] As an overview of an exemplary implementation, a chain of data blocks for a multi-key pair root CA can start with a single initial block. The initial block can be constructed as follows: For example, the root CA has multiple public-private key pairs, where an entity's public-private key pair includes a private key and a corresponding public key, which are related as defined by the cryptosystem. The private key is kept confidential by the entity, and the public key can be made public to other entities in the cryptosystem. For a root certificate, once multiple key pairs are established, the identity and public key combination of each key pair is self-signed. The self-signed root certificate is then placed in a chain of data blocks. Each data block is then signed by the root CA's multiple private keys. When issuing a certificate, the private key of a superior CA (root CA or superior intermediate CA) generates the signature. A set of data from each key pair, including the identity, public key, and digital signature of one or more other key pairs, is collected to construct a data block. This data block is then digitally signed by one or more key pairs to ensure its integrity and record proof of authorization. These multiple signatures, and the individual signatures on identity-public key pairs, can further help prevent single points of failure. This signed data block can be the initial block in a chain of data blocks.

[0021] Each time a change occurs (e.g., to the certificate included in the initial block), a new block can be chained. Such a change can include the addition or revocation of a root certificate, or another type of change. A new block containing information describing the change as a data entry can be appended to the existing chain of data blocks through a cryptographic process in which the new data block is concatenated with a hash of the previous block and the combination is digitally signed (e.g., multiple times). In some implementations, blocks are not allowed to be removed from the chain; blocks are chained in chronological order. Thus, tracking blocks from most recent to oldest can deterministically indicate the current state of the root certificate and allow entities to verify the validity of an identity's public key.

[0022] Because such a root certificate is not a single point of failure, damage resulting from the compromise of a root certificate's private key can be prevented. For example, the risk of such a compromise is limited to the subnetwork under the compromised root certificate, while subnetworks under other root certificates remain unaffected. Furthermore, by providing signatures from multiple root certificates for each block, the compromise of a single root certificate is not sufficient to change the status of other root certificates in the chain of data blocks. This mechanism also allows for the immediate revocation of the public key corresponding to the compromised private key or the deletion of the problematic certificate in a secure and systematic manner.

[0023] Figure 1A is a block diagram illustrating aspects of an exemplary communication system 100. The exemplary communication system 100 shown in Figure 1A includes four nodes: two entity nodes 102, 104, a root CA node 112, and a second CA node 114. The nodes communicate with each other via a network 106. The communication system 100 may include additional or different features, and the components within the communication system may be configured as shown in Figure 1A or in another manner.

[0024] In some implementations, nodes in communication system 100 have a server-client relationship. For example, entity node 102 can be a server and entity node 104 can be its client in the network, or vice versa. In some implementations, nodes in communication system 100 can have a peer-to-peer relationship. For example, entity nodes 102, 104 can be peers in the network. Nodes can have other types of relationships in communication system 100.

[0025] In the example shown in Figure 1A, exemplary entity nodes 102, 104, root CA node 112, and second CA node 114 each have computational resources (e.g., hardware, software, and firmware) used to communicate with other nodes. For example, each of the nodes of communication system 100 shown in Figure 1A can be implemented as exemplary computer system 500 shown in Figure 5 or components thereof. In some implementations, the nodes of communication system 100 can be implemented in a variety of systems, such as, for example, laptops, desktops, workstations, smartphones, tablets, servers, server clusters, mainframes, and other types of computer systems. In some cases, a single device can operate as both an entity node and a certificate authority node.

[0026] 1A, an end entity (represented by either entity node 102, 104) or a certificate authority entity (represented by either node 112, 114) may correspond to a computing device, a computer system, an IP address or other network address, or other type of computer-readable identifier or instance of a computer resource. Accordingly, computations and other operations of each entity may be performed by one or more processors or other elements of the respective node. Similarly, information sent to or received by an entity may be sent to or received from an element (e.g., one or more processors, memory, or interfaces) of the respective node.

[0027] The exemplary network 106 may include all or a portion of a data communications network or another type of communications link. For example, the network 106 may include one or more wired or wireless connections, one or more wired or wireless networks, or other communications channels. In some examples, the network 106 includes a local area network (LAN), a wide area network (WAN), a private network, a virtual private network (VPN), a public network (such as the Internet), a peer-to-peer network, a cellular network, a Wi-Fi network, a personal area network (PAN) (e.g., a Bluetooth Low Energy (BTLE) network, a ZigBee network, etc.), or other short-range networks involving machine-to-machine (M2M) communications, or other types of data communications networks.

[0028] In some examples, the nodes shown in FIG. 1A communicate with each other in a secure manner based on a cryptographically authenticated chain of data blocks, including an initial block and, optionally, a chain of one or more blocks chained to the initial block. For example, the nodes may utilize a cryptographic system or another type of system in which trust is established based on the chain of exemplary cryptographically authenticated data blocks 120. The exemplary cryptographically authenticated chain of data blocks 120 shown in FIG. 1A includes an initial block 122 and two action blocks 124A and 124B. The first action block 124A chains to the initial block 122, and the second action block 124B chains to the first action block 124A.

[0029] In general, a chain of cryptographically authenticated data blocks can include only an initial block 122, or can include any number of action blocks 124. Initial block 122 is generated by root CA node 112 and is the initial block of a chain that includes multiple root certificates owned by the root CA, while action blocks 124A, 124B represent changes related to the chain of cryptographically authenticated data blocks 120 or the root certificates contained therein. An exemplary initial block is shown in FIG. 2A, and an exemplary action block is shown in FIG. 2B. A chain of cryptographically authenticated data blocks 120 can optionally include additional blocks or blocks of different types.

[0030] In some implementations, the root CA node 112 can issue digital certificates based on a chain of cryptographically authenticated data blocks 120. As an example, the root CA node 112 can represent a root CA that owns multiple key pairs included in the chain of cryptographically authenticated data blocks 120 (e.g., in either the initial block 122 or the action block 124A, or both), and the root CA node 112 can issue a digital certificate that can be validated using one of the public keys in the chain of cryptographically authenticated data blocks 120. Thus, other entities can use the chain of cryptographically authenticated data blocks 120 to establish trust in the digital certificates issued by the root CA node 112. In some implementations, the second CA node 114 can be, for example, a subordinate CA (e.g., an intermediate CA) that is trusted by other entities based on digital certificates issued by the root CA node 112.

[0031] In some cases, entity nodes 102, 104 use a digital signature scheme that allows each node to validate the authenticity of messages received from other nodes. The digital signature scheme may be, for example, an elliptic curve cryptography (ECC)-based signature scheme, an RSA-based signature scheme, a lattice-based signature scheme, a hash-based signature scheme, a hypereigen-based signature scheme, a multivariate signature scheme, or a scheme using another type of cryptography. When the digital signature is verified using the signer's public key, the verifier can establish trust in the signer's public key based on a chain of cryptographically authenticated data blocks 120.

[0032] In some cases, entity nodes 102, 104 use an encryption scheme that allows each node to send confidential messages to other nodes. The encryption scheme may be, for example, an elliptic curve cryptography (ECC)-based encryption scheme, an RSA-based encryption scheme, a lattice-based encryption scheme, a hypereigenbased encryption scheme, a code-based encryption scheme, or a scheme using another type of cryptography. When a message to a recipient is encrypted using the recipient's public key, the sender can establish trust in the recipient's public key based on a chain of cryptographically authenticated data blocks 120.

[0033] FIG. 1B is a schematic diagram of an exemplary cryptographically authenticated chain of data blocks that can be used as a chain for cryptographically authenticated data blocks 120 of FIG. 1A. The exemplary cryptographically authenticated chain of data blocks shown in FIG. 1B includes sequentially chained blocks. In the example shown in FIG. 1B, the chain of data blocks begins with initial block 122, which is the first block in the chain ("Block_0"). The exemplary initial block 122 includes a data block ("Data Block #0") and a digital signature for the data block. In the process of forming each new block in the chain, a hash of the previous block in the chain is calculated by applying a hash function to the previous block, and the hash is appended to the new data block. As shown in FIG. 1B, action block 124A ("Block_1") is chained from initial block 122, and action block 124A includes the new data block ("Data Block #1") and the hash of the previous block (Hash(Block_0)). A hash of initial block 122 is generated by computing Hash(Block_0), where Hash(x) represents the output hash value generated by applying a cryptographic hash function to an input value (e.g., "Block_0"). In some implementations, one or more conventional hash functions from the SHA-2 family (e.g., SHA-256, SHA-512, SHA-384) or the SHA-3 family may be used. Additional or different hash functions may also be used.

[0034] In the process of forming each new block in the chain, a digital signature of the new data block and a hash of the previous block are generated, and the digital signature is appended to the new data block and the hash of the previous block. As shown in FIG. 1B, a digital signature is generated based on the concatenation of the new data block ("Data Block #1") and the hash (Hash(Block_0)), and the digital signature is appended to form action block 124A. Typically, the digital signature is generated by a digital signature algorithm operating on inputs including the signing entity's private key and the message to be signed (e.g., the data block and hash shown in FIG. 1B). The digital signature can be generated according to any suitable digital signature algorithm (e.g., RSA, DSA, ECDSA, a lattice-based digital signature algorithm, etc.).

[0035] Each subsequent block in the chain can be generated using a similar process. As shown in Figure 1B, action block 124B ("Block_n") is chained from the previous block ("Block_(n-1)"), and action block 124B includes a new data block ("Data Block #n") and the hash of the previous block. Also shown in Figure 1B, a digital signature is generated based on the concatenation of the new data block ("Data Block #n") and the hash ("Hash(Block_(n-1))"), and the digital signature is appended to form action block 124B.

[0036] In the example shown in Figure 1B, the hash of the previous block uniquely specifies the link between the two blocks (e.g., initial block 122 and action block 124A), and the digital signature ensures the integrity of the link from the new block to the previous block. As illustrated by the examples of Figures 2A and 2B and by the related discussion below, data structures and methods of the type depicted in Figure 1B for building a chain of data blocks can be used as the basis for building a cryptographically authenticated chain of data blocks representing a multi-key pair root CA.

[0037] FIG. 1C is a block diagram of an exemplary computer system 128 of a root CA having a control unit 130 and multiple signing units 132. For example, the exemplary computer system 128 shown in FIG. 1C can perform one or more operations of the root CA 112 shown in FIG. 1A. The computer system 128 can include additional or different components, and the components can be arranged in other ways. In the illustrated example, the root CA computer system includes a central control unit 130 and multiple signing units 132 connected in a star network around the control unit 130, with each signing unit 132 connected only to the control unit 130. The signing units 132 possess private keys and generate digital signatures upon request from the control unit 130. Each signing unit 132 maintains its own state and can represent the current state of a chain of cryptographically authenticated data blocks. In some implementations, the control unit 130 and the signature unit 132 may be implemented as a set of software processes on a single computing device, such as, for example, an integrated circuit (IC) chip on a circuit board, a separate circuit board in a hardware box such as a rack-mounted blade unit, or a separate computing device.

[0038] Typically, computer system 128 can be built on a hardware security module (HSM), which is usually a rack-mounted blade unit. Therefore, multiple HSMs can be used to build a multi-key pair root CA. Alternatively, within a rack-mounted blade unit, control unit 130 and signing unit 132 can be implemented as separate circuit boards connected on a system bus. These units can also be implemented as software modules within the HSM, and protections can be implemented to ensure the independence of the signing units for security purposes. The connection between control unit 130 and signing unit 132 can be secured against tampering and spoofing, and no secret information is communicated, thereby avoiding concerns about eavesdropping.

[0039] In various embodiments, the root CA 112 possesses multiple key pairs. Private keys are stored and managed independently. Public keys and associated identity information are stored and managed in the form of a cryptographically authenticated database, which in various implementations can be a chain of data blocks. The use of a cryptographically authenticated database allows changes to key pairs, such as updates, replacements, revocations, and additions, to be captured with cryptographic authentication and integrity.

[0040] In a traditional PKI system where a root CA owns a single key pair, the identity of the root CA is equivalent to the identity of the root CA's key pair. However, the exemplary root CA 112 shown in FIG. 1A owns multiple key pairs, and each key pair is therefore identified by the combination of the identity of the root CA 112 and the identity of the key pair belonging to that root CA 112. In the data block, a public key is associated with the combination of the identity of the root CA and the identity of the key pair.

[0041] The chain of data blocks 120 captures the identity and public key of the root CA 112, which can be represented in a variety of ways in a cryptographically authenticated database, distinguished by the identity of the key pair. Examples of public key representations include: 1. Represented with the minimum amount of data; 2. A variant of expression 1 with a more self-contained expression; 3. Represent it as a set of standard unsigned digital certificates; 4. Represent it as a set of self-signed certificates; 5. Represented as a set of standard digital certificates signed by a private key different from the private key paired with the certificate's public key; 6. Represent multiple cryptosystems as a set of certificates; 7. Represented as a set of self-signed certificates signed by other private keys and stored in the alternate cryptosystem extension.

[0042] If it is desirable to minimize the size of the data blocks of the cryptographically authenticated database (i.e., Representation 1), an initial block (e.g., initial block 200 shown in FIG. 2A) may include a list of pairs of the identity of the root CA 112, the public key, and the identity of its associated key pair. Subsequent data blocks may omit the identity of the root CA 112. In such a case, it may be necessary to trace the chain back to initial block 200 to obtain the identity of the root CA.

[0043] Alternatively, the identity of the key pair can always include the identity of the root CA 112. This is preferable if a self-contained representation of the key pair (i.e., Representation 2) is desired. Note that it is important that both Representation 1 and Representation 2 contain enough information to derive a representation in the form of a digital certificate body (e.g., an unsigned digital certificate).

[0044] The representation of the identity of the root CA 112 and the identity of the key pair containing the public key can take the form of an unsigned digital certificate (e.g., digital certificate body (i.e., representation 3)). The data block can then consist of a list of unsigned digital certificates.

[0045] In some implementations, the representation can use a full standard self-signed digital certificate (i.e., representation 4). This representation can provide backward compatibility for legacy systems. Instead of providing a chain of data blocks, the self-signed digital certificate can be distributed to the end entity. In such a deployment, the end entity can perform root certificate validation, as described later in this specification.

[0046] Instead of using a self-signed certificate format, a representation using a standard certificate signed by a private key different from the private key corresponding to the certificate's public key (i.e., Representation 5) can be used. This can be useful when the root CA 112 owns only a small number of key pairs, for example, two key pairs corresponding to two certificates. Such certificate pairs can be distributed to end entities in place of a chain of data blocks to function as root certificates. These certificates are not self-signed, but can verify the signature using the other certificate. In various implementations where the root CA 112 owns a larger number of key pairs, there can be a large number of possible combinations of certificate pairs, and the number of such certificate pairs can be much greater than the number of key pairs, requiring a large number of certificates.

[0047] The number of certificates can be reduced by using X.509 extensions for additional cryptosystems: the public key and an additional signature from a different private key can be stored in the extensions (i.e., representation 6). In this case, the same number of certificates as the number of key pairs can be required.

[0048] A variation of Representation 6 is to store the self-signature in place of the regular signature and store other signatures in an extension (i.e., Representation 7), which achieves the same backward compatibility as Representation 4 and allows cross-validation with different key pairs.

[0049] In some implementations where the cryptographically authenticated database is a chain of data blocks, the chain of data blocks begins with an initial data block containing an initial set of data including the identity of a root CA, the root CA's public key, and the identity of the public key. The initial data set may be provided, for example, as a set of self-signed digital certificates. This initial data set may be digitally signed to authenticate and ensure integrity, and the signature may be appended to complete the initial data block. Changes to the root CA's 112 key pair may be incorporated into subsequent data blocks. Subsequent data blocks may be chained by taking a hash of the previous data block including the appended signature, concatenating the message digest with the new data block's data set, digitally signing the concatenation, and appending the signature to the concatenation to complete the new data block.

[0050] In some implementations, the root CA may construct the initial data block in the following way: 1. The root CA generates multiple key pairs. 2. An initial data block body is constructed containing the root CA's identity, the key pair's identity, and the public key. 3. Sign the initial data block body using the private key associated with the key pair generated by the root CA. 4. The signature is added to the body to complete the initial data block.

[0051] The example initial block 200 shown in FIG. 2A includes an array of root certificates 202A, 202B, and 202C that form the initial data block 200. The root certificates 202A, 202B, and 202C correspond to key pairs owned by a root CA. Each root certificate corresponds to a respective one of the root CA's key pair. In the example shown, there are three root certificates (Root Certificate 1, Root Certificate 2, and Root Certificate 3), but in other implementations, the initial block 200 can include any number of root certificates. In the example shown in FIG. 2A, each of the root certificates 202A, 202B, and 202C is self-signed, meaning that the root certificate includes a digital signature generated by signing the CA's public key (and additional data elements) with the CA's corresponding private key.

[0052] 2A, initial block 200 also includes digital signatures 205A, 205B, and 205C corresponding to each of the root certificates present in initial block 200. The digital signatures are generated by a private key associated with each root certificate. In some cases, a digital signature protocol can be applied to an input message that includes an array of root certificates 202A, 202B, and 202C. For example, signature 1 is generated using the private key associated with the public key of root certificate 1, signature 2 is generated using the private key associated with the public key of root certificate 2, and signature 3 is generated using the private key associated with the public key of root certificate 3.

[0053] In some aspects of operation, multiple different root certificates 202A, 202B, 202C are obtained from signing unit 132 of root CA 112. Each signing unit 132 applies a digital signature associated with initial block 200. Control unit 130 can then validate the digital signature of initial block 200 before providing initial block 200 for use in the cryptographic system.

[0054] After the initial block 200 is created, additional data blocks in the chain can be constructed. The valid identity and public key of the root CA 112 can be represented by a chain of data blocks derived from the initial block 200, and any changes to the root CA 112, such as adding or revoking a certificate, are recorded by the chain block. As shown in FIG. 2B, a single block is added to the chain's predecessor at a time, creating a single-threaded chain. For example, the chain of data blocks can be deployed as an append-only chain, where blocks are not allowed to be removed from the chain. Thus, blocks are chained chronologically, with the last block being the most recent. Thus, to verify the root certificate of the root CA 112, one can follow the chain from the last block to find the first (e.g., most recent) occurrence of this certificate's identity, determine the validity of the root certificate, and, if the root certificate is valid, find a valid public key and use the public key to validate the signature. Thus, the chain of data blocks contains validity information representing the validity or invalidity of each of multiple different root certificates 202A, 202B, and 202C.

[0055] The initial block 200 and the chain data block may have different data structures for their respective data blocks. In some cases, the data structures of the initial block 200 and the chain data block may have certain fields in common, such as an identity field, a public key field, and a signature field. In some cases, aspects of the initial block 200 and the chain data block may resemble or include one or more X.509 certificates or another digital certificate format. For example, X.509 or another digital certificate format and encoding may be used to represent this portion of the data block, although simpler encodings may also be used. However, in some cases, unlike X.509, multiple signatures may be applied to a data block.

[0056] In some implementations, the identity field contains identity information data about the entity. The public key data field may have a data structure with components including, for example, the cryptosystem with domain parameters to which the public key belongs, the public key, and possibly an expiration date which may include an expiration time or other time representation, such as a duration. The digital signature data structure may contain components including, for example, the identity of the signer, the cryptosystem with domain parameters for which the signature is generated, the digital signature, and a timestamp.

[0057] 2B is a schematic diagram of an initial block 200 to which subsequent data blocks are chained. As shown in FIG. 2B, any changes to the information in the initial block 200 (e.g., changing the validity of a root certificate, adding a new digital certificate, etc.) will be incorporated into subsequent data blocks. When a change occurs, a new data block can be created. A new data block can be generated in the following manner: 1. The previous block is hashed; 2. The generated message digest is concatenated with the body of the new block; 3. The concatenated data is signed; 4. The signature is appended to the concatenated data, completing the chain for a new data block.

[0058] In some implementations, the control unit 130 is utilized to store and maintain a chain of data blocks, which can serve as a cryptographically authenticated database.

[0059] While FIG. 2B shows a first action block 204 and a second action block 206, any number of action blocks may be included, depending on the event or action to be taken. By way of example, first action block 204 specifies that root certificate 1 be revoked. Such an action may be performed, for example, in response to the compromise of a private key associated with root certificate 1, the expiration of root certificate 1, or any other scenario that may warrant revocation of a root certificate. First action block 204 includes a first data field 208. First data field 208 includes a description of the action to be performed. First action block 204 also includes a second data field 210, which includes the identity of the root certificate on which the action is to be performed. In the example shown in FIG. 2B, second data field 210 includes the identity of root certificate 1. First action block 204 also includes a hash 212. Hash 212 specifically links the action block to the previous block in the chain. In the example shown in FIG. 2B, hash 212 links first action block 204 to initial block 200. Finally, first action block 204 includes multiple digital signatures. In various implementations, the multiple digital signatures include digital signatures generated by private keys associated with each valid root certificate (e.g., each non-revoked root certificate included in the initial block). Thus, for first action block 204, digital signatures generated by private keys associated with root certificates 2 and 3 are attached. Digital signatures generated by private keys associated with root certificate 1 are not attached because the action to revoke root certificate 1 is performed by first action block 204. Digital signatures (Signature 2', Signature 3') are generated by signing a message including data fields 208, 210 and hash 212. In this manner, digital signatures (Signature 2', Signature 3') can be used to cryptographically verify the validity or invalidity of root certificates 202A, 202B, and 202C.

[0060] Second action block 206 specifies that root certificate 4 is to be added as a valid root certificate. As before, first data field 214 contains a description of the action to be performed: adding root certificate 4. Second data field 216 contains a self-signed certificate corresponding to root certificate 4. Hash 218 links second action block 206 to the previous block in the chain (in this case, first action block 204). Finally, second action block 206 contains digital signatures generated by the private keys associated with root certificate 2, root certificate 3, and root certificate 4, respectively. The digital signatures (Signature 2'', Signature 3'', Signature 4'') are generated by signing a message including data fields 214, 216, and hash 218. In this way, the digital signatures (Signature 2'', Signature 3'', Signature 4'') can be used to cryptographically verify the validity or invalidity of the root certification authority's root certificate.

[0061] In some implementations, the control unit 130 constructs the body of the action block. If a new public key is included, the action block includes the new public key and the identity of the key pair to which this public key belongs. The control unit 130 assigns a signature unit 132 for the new key pair and constructs the action block body in a manner similar to the generation of the initial data block 200. For example, if representation 4 (self-signed certificate representation) is used, the central control unit forms the body of the self-signed certificate and has it signed by the corresponding signature unit. If representation 5 or 6 (signed certificate) is used, the control unit 130 has another signature unit 132 sign the body of the root certificate. Some actions of the control unit 130 can be assigned to signature units 132.

[0062] To revoke or delete a public key, it may be sufficient for the new data block to contain the identity of the key pair to which the public key belongs. However, the public key itself may also be included. Other changes and actions may be captured with appropriate information in the body of the new data block. In some implementations, the new data block may contain the entire Certificate Revocation List ("CRL"), including its signature.

[0063] Once the action block has been added and the previous data block hashed, control unit 130 can perform the hashing and send the message digest along with the body of the action block to signing unit 132. Signing unit 132 can hash its state, which may include the previous data block, to verify the validity of the received message digest. Alternatively, control unit 130 can simply send the body of the action block, and each signing unit 132 can hash its state, concatenate the message digest, generate a signature, and send it back to control unit 130. In such a case, control unit 130 can also hash the previous block and concatenate it with the body, and can verify the received signature to ensure that signing unit 132 has the correct state and performed the proper signature generation. The signature can be appended to the concatenation of the message digest and body to complete the action block. This completes the chaining process. A new data block is sent to signing unit 132, where signing unit 132 updates its state with the new data block. Action blocks can also be distributed to end entities.

[0064] Possible action types (and associated action type identifiers) that may be identified in the data entries in FIG. 2C include adding a new root certificate ("new"), revoking a root certificate ("revoking"), deleting an old public key ("cancel"), timestamp ("timestamp"), known status ("status"), freezing ("freeze"), unfreezing ("unfreeze"), and possibly others.

[0065] In some cases, other types of actions may be defined and utilized. Examples of how the above action types may be defined and utilized are now described. These and other action types may also be implemented in other ways.

[0066] The "new" action is used to add a key pair or root certificate. For example, this action indicates that this root certificate or key pair did not exist in Root CA 112. Therefore, a new ID appears in the data entry along with the associated public key.

[0067] The "update" action is used when a public key is about to expire. This action therefore allows a grace period during which two public keys of the same cryptosystem with the same security strength can coexist for an identity until the old public key expires. The updated public key can be specified in the data input.

[0068] The "replace" action is used when a public key is revoked. The owner of the revoked public key can replace it with a replacement public key, which can be specified in the data input.

[0069] The "revoke" action prompts the immediate revocation of a public key. The revoked public key is specified in the data input. Once a public key is revoked, the "replace" action can be used to reactivate the owner of this public key.

[0070] The "add" action allows adding a second public key to an existing identity, creating a situation where, for example, a member possesses two valid public keys at the same time. This can be useful in migration scenarios, where the second public key belongs to a different cryptosystem, or to the same cryptosystem but with a different security strength. The second public key is for the new cryptosystem and / or security strength to which the system is migrating.

[0071] The old public key in a migration initiated by the "add" action can be made inactive by the "cancel" action. In some implementations, "revoke" can be used to indicate this "cancel" action.

[0072] The "timestamp" action can be used to indicate that the chain is up-to-date and was correct at the time of publication. The root CA is free to choose any appropriate interval for publishing the "timestamp" block. In some implementations, the absence of a recent "timestamp" block in a published chain can be interpreted by clients as an indication that the latest block in the chain is pending or has not been published.

[0073] The "status" action can contain all valid self-signed root certificates of a root CA. Such blocks can be redundant, as they contain information that can be computed from previous blocks. The "status" block can be considered an intermediate initial block. Consumers (especially those on constrained devices) can validate the status block upon receipt. Future chain validation can be performed from the current end of the chain to the previously validated status block, suggesting the work required to verify trust. If full validation is required, the entire chain is available. In some implementations, the "status" block can contain the currently valid self-signed root certificates.

[0074] The "freeze" action is optional. It indicates that no new blocks will be updated, i.e., no action will be performed, for a certain time. Therefore, this action block must be associated with a time duration for the freeze period, i.e., an expiration time. Optionally, no time can be specified, indicating that the chain of data blocks will be frozen indefinitely. This can be used, for example, to terminate the chain.

[0075] The "unfreeze" action is optional. This action is used only if accidental or malicious use of the "freeze" action is detected. This action can undo such a "freeze" action.

[0076] In some implementations, the action types introduced above for managing root certificates and public keys provide the ability to migrate to new cryptographic systems, enabling cryptographic agility. For example, if there is a need to migrate from an old to a new public key algorithm, an action type can define how to quickly add a second public key for the new identity, provide a transition period, and later revoke the old public key once the transition is complete.

[0077] 2C is a schematic diagram of a certificate chain originating from the root certificate of initial block 200. As shown in FIG. 2C, root certificate 270 included in the chain of data blocks can serve as a trusted anchor for intermediate certificate 272 and end entity certificate 274. In various implementations, root certificate 270 can be, for example, root certificates 202A, 202B, 202C, and 216 shown in FIGS. 2A and 2B. Intermediate certificate 272 can be issued by a root CA to an intermediate CA; for example, the intermediate certificate can include the root CA's digital signature (generated using the root CA's private key associated with root certificate 270) over the intermediate CA's identity and public key. End entity certificate 274 can be issued by an intermediate CA to an end entity; for example, the intermediate certificate can include the intermediate CA's digital signature (generated using the intermediate CA's private key associated with intermediate certificate 272) over the end entity's identity and public key.

[0078] In a multi-key pair root CA 112, a root certificate can be validated by a chain of data blocks 120. The chain of data blocks can be distributed to verifying end entities. A verifying end entity can validate the chain of data blocks 120 by verifying a signature in the chain using a public key in the chain. In some cases, a public key different from the target public key may be used to verify the signature.

[0079] In some implementations, the initial data block 200 is distributed first (instead of distributing the root certificate 270 itself). The public key of the root CA 112 can then be updated by distributing the action blocks (204, 206). The action blocks (204, 206) can be validated by verifying that the message digest of the action block (204, 206) matches the hash of the previous data block and verifying the signature of the action block (204, 206). The action blocks (204, 206) are signed with multiple private keys of the root CA. This means that if the action block (204, 206) requests revocation of the root certificate, the revocation is cryptographically authenticated using a public key in the chain of data blocks that is different from the target public key. Distribution of the initial data block 200 and subsequent action blocks (204, 206) can utilize existing methods for distributing root certificates, such as via OS updates. However, a validating end entity may need to perform different checks and processing than the root certificate.

[0080] As mentioned above, the public key, along with its identity, can be represented in the form of a digital certificate. Backward compatibility can be achieved if representations 4 and 7, which are self-signed certificate representations, are used. Instead of distributing a chain of data blocks to legacy validating end entities that require backward compatibility, the root CA 112 distributes a standard self-signed certificate included in the chain of data blocks. The legacy validating end entities can then perform standard certificate chain verification. Existing methods for updating root certificates can be used to provide the new public key.

[0081] In some implementations, a legacy end entity may occasionally or periodically validate a root certificate that it possesses. In such a case, the legacy end entity can fetch or download the latest chain of data blocks, verify that the root certificate is in the chain of data blocks, verify that the root certificate remains valid, and verify that the chain of data blocks is valid, which would involve verifying the signatures in the chain with its own public key.

[0082] In some cases, the root CA 112 may distribute its public key in the form of a digital certificate that is not self-signed but is otherwise in a standard format. This is representation 5 or 6 above. Because these certificates are not self-signed, they can be cross-verified with appropriate signature verification. Again, the root CA's certificate can be validated by downloading the chain of data blocks and verifying the signatures therein.

[0083] Root certificates can be validated in a manner similar to that of the Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs). If the root CA is an OCSP responder, the OCSP response can be signed with a private key that is not paired with the queried public key. A CRL can be signed with a private key that has not been revoked. In either case, multiple signatures with different valid private keys can be applied to an OCSP response or CRL.

[0084] FIG. 3 is a schematic diagram illustrating an example process 300 for generating a cryptographically authenticated chain of data blocks. For example, process 300 may generate the example chain of data blocks 120 shown in FIG. 1, the example chain of data blocks shown in FIGS. 2A and 2B, or another cryptographically authenticated chain of data blocks. The example process 300 may be performed by a computer system, such as a computer system associated with the root CA 112 shown in FIG. 1A or another computer system. In some cases, one or more operations of process 300 may be performed by the example computer system 128 shown in FIG. 1C. The example process 300 may include additional or different operations, and operations may be performed in the order shown or in a different order. In some cases, one or more of the operations shown in FIG. 3 are implemented as a process including multiple operations, subprocesses, or other types of routines. In some cases, operations may be combined, performed in a different order, performed in parallel, repeated, or otherwise repeated, or performed in a different manner.

[0085] At 302, the control unit 130 constructs an initial data block with the help of signing units 132, which perform key pair generation and digital signature generation. First, each signing unit 132 generates an initial key pair. Then, the signing units 132 send their public keys to the control unit 130. If these are actions within the root CA 112, the root CA 112 knows that each signing unit 132 possesses a private key. In such a case, no Certificate Signing Request (CSR) type exchange is necessary to prove possession of the private key.

[0086] Next, control unit 130 creates the body of initial block 200, which includes the identity of root CA 112, the identity of the initial key pair, and the initial public key. If a self-signed certificate representation is used, control unit 130 forms the body of the self-signed certificate and has it signed by signing unit 132. Control unit 130 can construct the identity information and send it to signing unit 132 to be completed with the public key. In this case, signing unit 132 can return the self-signed certificate to control unit 130. Alternatively, control unit 130 can construct the data to be self-signed after receiving the public key from signing unit 132. In this case, signing unit 132 returns only the signature to control unit 130, where control unit 130 can complete the self-signed certificate. Control unit 130 then concatenates the self-signed certificate to construct the body of the initial block (e.g., initial block 200 shown in FIGS. 2A and 2B).

[0087] At 304, once control unit 130 has constructed the body of the initial data block, it sends the body to signing unit 132 to obtain a signature. Control unit 130 then adds a signature to complete the initial data block. Control unit 130 sends the completed initial data block to signing unit 132, which stores it as an initial state. The initial data block can also be distributed to end entities that can use different representations as described above. Distribution methods are further described with reference to FIG. 2C. In various implementations, signing unit 132 can perform some of the actions performed by control unit 130.

[0088] At 306, to add an action block, the previous data block is first hashed. Control unit 130 may perform the hashing and send the message digest along with the body of the action block to signing unit 132. Each signing unit 132 may hash a state that is or may include the previous data block to verify the validity of the received message digest. Alternatively, control unit 130 may simply send the body of the action block, and each signing unit 132 may hash its state, concatenate the message digest, generate a signature, and send it back to control unit 130. In such a case, control unit 130 may also hash the previous block and concatenate it with the body, and may verify the received signature to ensure that signing unit 132 has the correct state and performed the proper signature generation.

[0089] At 308, the signature is appended to the concatenation of the message digest and body to complete the action block, potentially completing the chaining process. The action block is sent to signing unit 132, which uses the action block to update the state. The action block, or the updated chain of data blocks, may be distributed to end entities.

[0090] FIG. 4 is a schematic diagram illustrating an example process 400 for verifying a root certificate. For example, process 400 may validate any of root certificates 202A, 202B, 202C, 216 shown in FIG. 2B or a root certificate in another cryptographically authenticated database. Example process 400 may be performed by a computer system, such as a computer system associated with root CA 112 shown in FIG. 1A or a different computer system. In some cases, one or more operations of process 400 may be performed by example computer system 128 shown in FIG. 1C. Example process 400 may include additional or different operations, and operations may be performed in the order shown or in a different order. In some cases, one or more of the operations shown in FIG. 4 are implemented as a process including multiple operations, subprocesses, or other types of routines. In some cases, operations may be combined, performed in a different order, performed in parallel, repeated, or otherwise repeated, or performed in a different manner.

[0091] At 402, a query regarding the validity of a root certificate is received. In some implementations, the identified root certificate may be Root Certificate 1 (202A) shown in FIGS. 2A-2B or another root certificate. In various implementations, the identified root certificate may be included in an initial block, such as initial block 200 shown in FIGS. 2A-2B. The identified root certificate is associated with a root CA, such as Root Certification Authority 112 shown in FIG. 1A.

[0092] The query may be received at the computer system, for example, via a network interface or another type of communications interface. The query may be received by the root certificate authority, for example, from another entity in the cryptographic system (e.g., an end entity or another certificate authority). In some cases, the query is received from an entity seeking to validate a certificate in a certificate chain for which the root certificate serves as the root of trust. In various implementations, the query may be or resemble an Online Certificate Status Protocol (OCSP) query, a Certificate Revocation List (CRL) query, or another type of status query, and the query may have another form or format.

[0093] At 404, the identified root certificate is cryptographically verified against a cryptographically authenticated database representing root CAs. In various implementations, the cryptographically authenticated database can be implemented as a chain of data blocks representing root CAs. The cryptographically authenticated database includes multiple different root certificates of root certificate authorities, including the root certificate identified in the query received at 402. For example, in some implementations, the multiple different root certificates can be the root certificates (202A, 202B, 202C, 216) shown in FIGS. 2A-2B, and the identified root certificate can be, for example, root certificate 202A or another root certificate. The cryptographically authenticated database also includes validity information indicating the validity or invalidity of each of the multiple different root certificates.

[0094] The validity information can be or include one or more digital signatures of the root CA. The root CA's digital signature in the validity information is different from the digital signatures of the individual root certificates. For example, the validity information can be digital signatures 205A, 205B, and 205C shown in FIG. 2A. In such a case, cryptographically verifying the validity of the identified root certificate against a cryptographically authenticated database includes verifying one or more digital signatures in the validity information. In some implementations, cryptographically verifying the validity of the identified root certificate includes verifying the digital signatures associated with all of the root certificate authority's valid key pairs. For example, in the example shown in FIG. 2A, cryptographically verifying the validity of root certificate 202A includes verifying signatures 205A, 205B, and 205C, and in the example shown in FIG. 2B, cryptographically verifying the validity of root certificate 216 includes verifying signature 2'', signature 3'', and signature 4''.

[0095] In some implementations, cryptographically verifying the validity of the identified root certificate includes the additional act of verifying one or more components in the chain of data blocks. In some cases, the cryptographically authenticated database includes hash values that provide links between data blocks in the chain of data blocks, and cryptographically verifying the validity of the identified root certificate against the cryptographically authenticated database includes verifying the hash values. In some cases, the cryptographically authenticated database includes one or more action blocks, and cryptographically verifying the validity of the identified root certificate against the cryptographically authenticated database includes processing the action blocks to determine the current state of the identified root certificate.

[0096] In step 406, a determination regarding the validity of the identified root certificate is provided. For example, the determination can be provided by sending a message indicating that the identified root certificate is valid or invalid. The determination is based on validity information in a cryptographically authenticated database. For example, if the appropriate digital signature is verified and the identified root certificate is not expired or revoked, the determination can indicate that the identified root certificate is valid. If the appropriate digital signature cannot be verified or if the identified root certificate is expired or revoked, the determination can indicate that the identified root certificate is invalid. In various implementations, the determination can be signed with a private key that is not revoked and is not paired with the public key of the identified root certificate. Thus, multiple digital signatures from different valid private keys can be used to authenticate the validity of the identified root certificate.

[0097] 5 is a block diagram illustrating an example of a computer system 500 including a data processing device and one or more computer-readable storage devices. The term "data processing device" encompasses all types of apparatus, devices, nodes, and machines for processing data, including, by way of example, a programmable processor, a computer, a system on a chip, or a plurality or combination of the foregoing, such as processor 510. An apparatus may include, for example, special-purpose logic circuitry such as an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit). In addition to hardware, an apparatus may also include code that creates an execution environment for the computer program, such as code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform execution environment, a virtual machine, or one or more combinations thereof.

[0098] A computer program (also known as a program, software, software application, script, or code), e.g., computer program 524, can be written in any type of programming language, including compiled or interpreted, declarative or procedural, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program can, but need not, correspond to a file in a file system. A program can be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program, or in multiple coordinated files (e.g., files storing one or more modules, subprograms, or portions of code). A computer program can be deployed to run on one computer, on multiple computers located at a single site, or on multiple computers distributed across multiple sites and interconnected by a communications network.

[0099] Some of the processes and logic flows described herein may be performed by one or more programmable processors, such as processor 510, executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows may also be performed by, and apparatus may also be implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0100] Processors suitable for executing a computer program include, by way of example, general-purpose and special-purpose microprocessors, and processors of any kind of digital computer. Generally, a processor receives instructions and data from a read-only memory or a random-access memory, or both (e.g., memory 520). Elements of a computer may include a processor, which performs operations in accordance with the instructions, and one or more memory devices for storing instructions and data. A computer may also include one or more mass storage devices for storing data, such as magnetic, magneto-optical, or optical disks, operatively coupled to receive data from, or transfer data to, one or both. However, a computer need not include such devices. Furthermore, a computer may be incorporated into another device, such as a telephone, electronic device, portable audio or video player, game console, Global Positioning System (GPS) receiver, or portable storage device (e.g., a Universal Serial Bus (USB) flash drive). Devices suitable for the storage of computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, flash memory devices, etc.), magnetic disks (e.g., internal hard disks, removable disks, etc.), magneto-optical disks, CD-ROM and DVD-ROM disks, etc. In some cases, the processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0101] The exemplary power supply unit 540 provides power to other components of the computer system 500. For example, the other components may operate based on power provided by the power supply unit 540 via a voltage bus or other connection. In some implementations, the power supply unit 540 includes a battery or battery system, such as a rechargeable battery. In some implementations, the power supply unit 540 includes an adapter (e.g., an AC adapter) that receives an external power signal (from an external source) and converts the external power signal into an internal power signal conditioned for the components of the computer system 500. The power supply unit 540 may include or otherwise operate with other components.

[0102] To provide for user interaction, operations can be performed on a computer having a display device (e.g., display 550) for displaying information to the user (e.g., a monitor or another type of display device), and a keyboard and pointing device (e.g., a mouse, trackball, tablet, touch-sensitive screen, or another type of pointing device) by which the user can provide input to the computer. Similarly, other types of devices can be used to provide for user interaction; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, tactile feedback, etc., and input from the user can be received in any form, such as acoustic input, voice input, tactile input, etc. Furthermore, the computer can interact with the user by sending documents to and receiving documents from devices used by the user, for example, by sending a web page to a web browser on the user's client device in response to a request received from the web browser.

[0103] Computer system 500 may include a single computing device or multiple computers operating within close proximity or substantially remote proximity to each other and typically interacting through a communications network (e.g., interface 530). Examples of communications networks include local area networks ("LANs") and wide area networks ("WANs"), internetworks (e.g., the Internet), networks including satellite links, and peer-to-peer networks (e.g., ad hoc peer-to-peer networks). The relationship of client and server may arise by virtue of computer programs running on the respective computers having a client-server relationship to each other.

[0104] The exemplary interface 530 can provide for communication with other systems or devices. In some cases, the interface 530 includes a wireless communication interface that provides wireless communication under various wireless protocols, such as Bluetooth, Wi-Fi, near field communication (NFC), GSM voice calls, SMS, EMS, or MMS messaging, wireless standards (e.g., CDMA, TDMA, PDC, WCDMA, CDMA2000, GPRS), etc. Such communication can occur, for example, via a radio frequency transceiver or another type of component. In some cases, the interface 530 includes a wired communication interface (e.g., USB, Ethernet) that can be connected to one or more input / output devices, such as a keyboard, a pointing device, a scanner, or a network device, such as a switch or router, via a network adapter.

[0105] FIG. 6 is a schematic diagram illustrating an example process 600 for generating a cryptographically authenticated database of root certificates. For example, process 600 may generate the example chain of data blocks 120 shown in FIG. 1 , the example chain of data blocks shown in FIGS. 2A and 2B , or another type of cryptographically authenticated database of root certificates. The example process 600 may be performed by a computer system, such as a computer system associated with the root CA 112 shown in FIG. 1A or another type of computer system. In some cases, one or more of the operations in process 300 may be performed by the example computer system 128 shown in FIG. 1C . The example process 600 may include additional or different operations, and operations may be performed in the order shown or in a different order. In some cases, one or more of the operations shown in FIG. 6 are implemented as a process including multiple operations, subprocesses, or other types of routines. In some cases, operations may be combined, performed in a different order, performed in parallel, repeated, or otherwise repeated, or performed in a different manner.

[0106] At 602, multiple different cryptographic key pairs are generated for the root certificate authority. Each of the different cryptographic key pairs includes a public key and a private key. The key pairs may include ECC key pairs, RSA key pairs, or combinations of these and other types of cryptographic key pairs. In various implementations, the root certificate authority may be, for example, the root certificate authority 112 shown in FIG. 1A or another root certificate authority.

[0107] At 604, multiple different self-signed root certificates of the root certification authority are generated based on the multiple cryptographic key pairs. In various implementations, the different self-signed root certificates may include, for example, root certificates 202A, 202B, and 202C shown in FIG. 2B or multiple other root certificates. The root certificates may be formatted according to a standard (e.g., X.509 or another standard) or may have another format. Each self-signed root certificate includes the identity of the root certification authority, one public key of the cryptographic key pair, and a digital signature created using the private key corresponding to the public key of the root certificate.

[0108] At 606, a cryptographic authentication database representing the root certificate authority is generated. In various implementations, the cryptographically authenticated database can be, for example, a chain of data blocks 120 shown in FIG. 1A or a chain of other data blocks. In some cases, the cryptographic authentication database is generated by process 300 shown in FIG. 3. For example, the cryptographic authentication database can be generated by adding one or more signatures to multiple different self-signed root certificates of the root certificate authority. As an example, generating the cryptographically authenticated database can include generating digital signatures 205A, 205B, and 205C shown in FIG. 2B.

[0109] At 608, the cryptographically authenticated database is distributed to other entities in the public key infrastructure. The other entities then use the information contained in the cryptographically authenticated database to cryptographically verify the validity or invalidity of each of the different self-signed root certificates. In various implementations, the other entities may include, for example, intermediate certificate authorities or end entities.

[0110] In a general aspect, the encryption system utilizes a cryptographically authenticated database representing multiple key pair root certificate authorities (CAs). In some implementations, the encryption system also enables validation of the certificates of the multiple key pair root CAs.

[0111] In a first example, a query regarding the validity of an identified root certificate of a root CA is received from an entity. The validity of the identified root certificate is cryptographically verified against a cryptographically authenticated database representing the root CA. The cryptographically authenticated database includes multiple distinct root certificates of the root CA, such that the multiple distinct root certificates include the identified root certificate. The cryptographically authenticated database also includes validity information representing the validity or invalidity of each of the multiple distinct root certificates. A determination regarding the validity of the identified root certificate is provided to the entity.

[0112] In a first example implementation, the root certificate authority has multiple distinct cryptographic key pairs, each of which includes a public key and a private key, and each of the multiple distinct root certificates corresponds to a respective key pair of the multiple distinct cryptographic key pairs and includes the identity of the root certificate authority, the public key of the respective key pair, and a digital signature generated using the private key of the respective key pair.

[0113] In some instances of the first example, the digital signatures of the plurality of different root certificates are a first plurality of digital signatures of a root certificate authority, and the validity information includes a second plurality of digital signatures of the root certificate authority, each of the second plurality of digital signatures being generated by a respective private key of the plurality of different cryptographic key pairs. Cryptographically verifying the validity of the root certificate includes verifying the second plurality of digital signatures of the root certificate authority.

[0114] In some implementations of the first example, the validity information records changes to multiple different cryptographic key pairs. In some cases, the changes may include updating, replacing, revoking, or adding key pairs.

[0115] In some implementations of the first example, the cryptographically authenticated database includes a cryptographically authenticated chain of data blocks. In some implementations of the first example, in response to cryptographically verifying that the identified root certificate is valid, the identified root certificate is used to cryptographically verify the validity of digital certificates issued by the root certificate authority.

[0116] In a second embodiment, a computer system includes one or more processors and a memory storing instructions operable, when executed by the one or more processors, to perform one or more operations of the first embodiment. In a third embodiment, a non-transitory computer-readable medium includes instructions operable, when executed by a data processing apparatus, to perform one or more operations of the first embodiment.

[0117] In a fourth embodiment, a plurality of different cryptographic key pairs are generated for the root certification authority. Each of the plurality of different cryptographic key pairs includes a public key and a corresponding private key. A plurality of different self-signed root certificates are generated for the root certification authority. The plurality of different self-signed root certificates are based on the plurality of different cryptographic key pairs. Each of the plurality of different self-signed root certificates corresponds to a respective key pair of the plurality of different cryptographic key pairs. Each of the plurality of different self-signed root certificates includes the identity of the root certification authority, the public key of the respective key pair, and a digital signature generated using the private key of the respective key pair. A cryptographically authenticated database representing the root certification authority is generated. The cryptographically authenticated database includes the plurality of different self-signed root certificates of the root certification authority and validity information representing the validity or invalidity of each of the plurality of self-signed root certificates. The cryptographically authenticated database is distributed to entities of a public key infrastructure. The entities can use the validity information to cryptographically verify the validity or invalidity of each of the plurality of different self-signed root certificates.

[0118] In some implementations of the fourth example, the digital signatures in the plurality of different self-signed root certificates are a first plurality of digital signatures of a certificate authority, and the validity information includes a second plurality of digital signatures of the root certificate authority, each of which is generated by a respective private key of a plurality of different cryptographic key pairs.

[0119] In some aspects of the fourth embodiment, generating the cryptographically authenticated database includes generating an initial block of a cryptographically authenticated chain of data blocks.

[0120] In some implementations of the fourth embodiment, generating the initial block includes generating a data block including a plurality of different self-signed root certificates, generating a second plurality of digital signatures based on the data block, and appending the second plurality of digital signatures to the data block to form the initial block.

[0121] In some aspects of the fourth embodiment, generating the cryptographically authenticated database includes generating an initial block and a first action block of a cryptographically authenticated chain of data blocks.

[0122] In some aspects of the fourth embodiment, generating the initial block includes generating a first data block including a first subset of the different self-signed root certificates, generating a first subset of a second plurality of digital signatures based on the first data block, and appending the first subset of the second plurality of digital signatures to the first data block to form the initial block. Generating the first action block includes generating a second data block including a second subset of the different self-signed root certificates, generating a hash of the initial block, generating a second subset of the second plurality of digital signatures based on a concatenation of the second data block and the hash, and appending the hash and the second subset of the second plurality of digital signatures to the second data block to form the first action block.

[0123] In some aspects of the fourth embodiment, generating the second action block includes generating a third data block including a third subset of the different self-signed root certificate, generating a hash of the immediately preceding action block, generating a third subset of the second plurality of digital signatures based on a concatenation of the second data block and the hash, and appending the hash and the third subset of the second plurality of digital signatures to the third data block to form the second action block.

[0124] In some implementations of the fourth embodiment, the initial block includes a plurality of different root certificates, and the action block indicates that at least one of the plurality of different root certificates is invalid.

[0125] In a fifth embodiment, a computer system includes one or more processors and a memory storing instructions operable when executed by the one or more processors to perform one or more operations of the fourth embodiment. In a sixth embodiment, a non-transitory computer-readable medium includes instructions operable when executed by a data processing apparatus to perform one or more operations of the fourth embodiment.

[0126] In some aspects, methods and systems are provided for building a cryptographically authenticated database of multiple different root certificates of a root CA and managing the cryptographically authenticated database. In some cases, an initial block is built with a data entry for each different root certificate of the multiple different root certificates. In another example, a new data block is built with one or more data entries, each entry including an action type field indicating a change (e.g., a change in the status of a different root certificate of the multiple different root certificates). The new data block is chained from the initial block or a subsequent block in the chain of data blocks.

[0127] While this specification contains many details, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of features specific to particular examples. Certain features described in this specification or shown in the drawings in the context of separate implementations may also be combined. Conversely, various features described or shown in the context of a single implementation may also be implemented in multiple embodiments separately or in any suitable subcombination.

[0128] Similarly, although operations are depicted in the figures in a particular order, this should not be understood as requiring such operations to be performed in the particular order shown, or in a sequential order, or that all of the illustrated operations be performed, to achieve desirable results. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the above-described implementations should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems may generally be integrated together in a single product or packaged in multiple products.

[0129] A number of embodiments have been described. However, it will be understood that various modifications are possible. Accordingly, other embodiments are within the scope of the following claims.

Claims

1. 1. A method comprising: receiving a query from an entity regarding the validity of an identified root certificate of a root certification authority; cryptographically verifying the validity of the identified root certificate against a cryptographically authenticated database representative of the root certificate authority, the cryptographically authenticated database including a plurality of different root certificates of the root certificate authority, the different root certificates including the identified root certificate, and validity information representing the validity or invalidity of each of the plurality of different root certificates; providing a determination regarding the validity of the identified root certificate to an entity; and A method comprising:

2. the root certificate authority has a plurality of different cryptographic key pairs, each of the plurality of different cryptographic key pairs including a public key and a private key; each of the plurality of different root certificates corresponds to a respective key pair of the plurality of different encryption key pairs; and the identity of the root certificate authority; the public key of each of said key pairs; a digital signature generated using the private key of each of said key pairs; Including, The method of claim 1.

3. the digital signatures in the plurality of different root certificates are a first plurality of digital signatures of the root certificate authority; the validity information includes a second plurality of digital signatures of the root certificate authority, each of the second plurality of digital signatures generated by a respective private key of the plurality of different cryptographic key pairs; cryptographically verifying the validity of a root certificate includes verifying the second plurality of digital signatures of the root certificate authority; The method of claim 2.

4. 4. The method of claim 3, wherein the second plurality of digital signatures are generated using a private key corresponding to another root certificate from the plurality of different root certificates that is different from the identified root certificate.

5. The method of claim 2 , wherein the validity information records changes to the plurality of different cryptographic key pairs.

6. The said changes are: updating one of the plurality of encryption key pairs; replacing one of said plurality of cryptographic key pairs; Revoking one of said plurality of cryptographic key pairs; or Adding one of a number of different cryptographic key pairs; The method of claim 5 , comprising at least one of:

7. A method according to any preceding claim, wherein the cryptographically authenticated database comprises a chain of cryptographically authenticated data blocks.

8. 7. The method of claim 1, wherein, in response to determining that the identified root certificate is valid, the entity cryptographically validates a digital certificate issued by the root certificate authority using the identified root certificate.

9. 1. A computer system comprising: one or more processors; a memory storing instructions operable to perform operations when executed by the one or more processors; Equipped with The operation is receiving a query from an entity regarding the validity of an identified root certificate of a root certification authority; cryptographically verifying the validity of the identified root certificate against a cryptographically authenticated database representative of the root certificate authority, the cryptographically authenticated database including a plurality of different root certificates of the root certificate authority, the different root certificates including the identified root certificate, and validity information representing the validity or invalidity of each of the plurality of different root certificates; providing a determination regarding the validity of the identified root certificate to an entity; and 2. A computer system comprising:

10. the root certificate authority has a plurality of different cryptographic key pairs, each of the plurality of different cryptographic key pairs including a public key and a private key; each of the plurality of different root certificates corresponds to a respective key pair of the plurality of different encryption key pairs; and the identity of the root certificate authority; the public key of each of said key pairs; a digital signature generated using the private key of each of said key pairs; Including, The system of claim 9.

11. the digital signatures in the plurality of different root certificates are a first plurality of digital signatures of the root certificate authority; the validity information includes a second plurality of digital signatures of the root certificate authority, each of the second plurality of digital signatures generated by a respective private key of the plurality of different cryptographic key pairs; cryptographically verifying the validity of a root certificate includes verifying the second plurality of digital signatures of the root certificate authority; The system of claim 10.

12. 12. The system of claim 11, wherein the second plurality of digital signatures are generated using a private key corresponding to another root certificate from the plurality of different root certificates that is different from the identified root certificate.

13. The system of claim 10 , wherein the validity information records changes to the plurality of different cryptographic key pairs.

14. The said changes are: updating one of the plurality of encryption key pairs; replacing one of said plurality of cryptographic key pairs; Revoking one of said plurality of cryptographic key pairs; or Adding one of a number of different cryptographic key pairs; The system of claim 13 , comprising at least one of:

15. A system according to any one of claims 9 to 14, wherein the cryptographically authenticated database comprises a cryptographically authenticated chain of data blocks.

16. 15. The system of claim 9, wherein, in response to cryptographically verifying that the identified root certificate is valid, the system cryptographically verifies the validity of a digital certificate issued by the root certificate authority using the identified root certificate.

17. A non-transitory computer-readable medium containing instructions that, when executed by a data processing apparatus, perform operations, comprising: The operation is receiving a query from an entity regarding the validity of an identified root certificate of a root certification authority; cryptographically verifying the validity of the identified root certificate against a cryptographically authenticated database representative of the root certificate authority, the cryptographically authenticated database including a plurality of different root certificates of the root certificate authority, the different root certificates including the identified root certificate, and validity information representing the validity or invalidity of each of the plurality of different root certificates; providing a determination regarding the validity of the identified root certificate to an entity; and 1. A non-transitory computer-readable medium comprising:

18. the root certificate authority has a plurality of different cryptographic key pairs, each of the plurality of different cryptographic key pairs including a public key and a private key; each of the plurality of different root certificates corresponds to a respective key pair of the plurality of different encryption key pairs; and the identity of the root certificate authority; the public key of each of said key pairs; a digital signature generated using the private key of each of said key pairs; 20. The computer-readable medium of claim 17, comprising:

19. the digital signatures in the plurality of different root certificates are a first plurality of digital signatures of the root certificate authority; the validity information includes a second plurality of digital signatures of the root certificate authority, each of the second plurality of digital signatures generated by a respective private key of the plurality of different cryptographic key pairs; cryptographically verifying the validity of a root certificate includes verifying the second plurality of digital signatures of the root certificate authority; 20. The computer-readable medium of claim 18.

20. 20. The computer-readable medium of claim 19, wherein the second plurality of digital signatures are generated using a private key corresponding to another root certificate from the plurality of different root certificates that is different from the identified root certificate.

21. 21. The computer-readable medium of claim 20, wherein the validity information records changes to the plurality of different cryptographic key pairs.

22. The said changes are: updating one of the plurality of encryption key pairs; replacing one of said plurality of cryptographic key pairs; Revoking one of said plurality of cryptographic key pairs; or Adding one of a number of different cryptographic key pairs; 22. The computer-readable medium of claim 21, comprising at least one of:

23. 23. The computer-readable medium of any one of claims 17 to 22, wherein the cryptographically authenticated database comprises a cryptographically authenticated chain of data blocks.

24. 23. The computer-readable medium of claim 17, wherein, in response to cryptographically verifying that the identified root certificate is valid, the identified root certificate is used to cryptographically verify the validity of a digital certificate issued by the root certificate authority.

Images