ABSTRACT
Abstract
In a general aspect, a digital certificate can be used with multiple cryptography systems (âcryptosystemsâ). In some cases, the digital certificate includes a public key field, which contains a first public key of an entity. The first public key of the entity is associated with a first cryptosystem. The digital certificate includes a signature value field, which contains a first digital signature of a certificate authority. The first digital signature is associated with the first cryptosystem. The digital certificate includes an extension. The extension contains a second public key of the entity, a second digital signature of the certificate authority or both. The second public key is associated with a second cryptosystem, and the second digital signature is associated with the second cryptosystem.
Description
BACKGROUND
The following description relates to using a digital certificate with multiple cryptography systems (âcryptosystemsâ), for example, in a public key infrastructure.
Cryptography systems are used to communicate securely over public channels. For example, some cryptosystems provide confidentiality by encrypting messages, and some cryptosystems provide authenticity through digital signatures. Many cryptosystems include protocols that use cryptographic keys. For example, in a public key infrastructure (PKI), the cryptographic keys include public and private keys for each entity, and a certificate authority can issue digital certificates to certify the public keys.
DESCRIPTION OF DRAWINGS
FIG. 1 is a block diagram showing aspects of an example communication system.
FIG. 2A is a block diagram showing an example enterprise system transitioning between cryptosystems.
FIG. 2B is a flow diagram showing an example process for transitioning between cryptosystems.
FIG. 3 is a flow diagram showing an example process for issuing a digital certificate for multiple cryptosystems.
FIG. 4 is a flow diagram showing an example process for using a digital certificate in multiple cryptosystems.
FIG. 5 is a block diagram showing an example digital certificate that includes a public key for a quantum-resistant cryptosystem.
FIG. 6 is a block diagram showing an example certificate chain with a digital certificate that includes a public key for a quantum-resistant cryptosystem.
FIG. 7 is a block diagram showing an example digital certificate that includes a certificate authority signature for a quantum-resistant cryptosystem.
FIG. 8 is a block diagram showing an example certificate chain with a digital certificate that includes a certificate authority signature for a quantum-resistant cryptosystem.
FIG. 9 is a block diagram showing an example digital certificate that includes a certificate authority signature and public key for a quantum-resistant cryptosystem.
FIG. 10 is a block diagram showing an example certificate chain with a digital certificate that includes a certificate authority signature and public key for a quantum-resistant cryptosystem.
DETAILED DESCRIPTION
In some aspects of what is described here, a digital certificate can be used with multiple cryptosystems. The digital certificate can include components (e.g., digital signatures, public keys, etc.) for each of the cryptosystems. In some cases, such digital certificates can be used in the context of deploying a new authentication algorithm within an enterprise infrastructure. For instance, such âhybridâ digital certificates can be used in a phased approach to gradually rollout the new cryptosystem as various system components are upgraded to support the new cryptosystem.
In some implementations, hybrid digital certificates can be used by a quantum-vulnerable cryptosystem (e.g., a conventional quantum-vulnerable cryptosystem) and an upgraded quantum-resistant cryptosystem, for example, during a transition from the quantum-vulnerable cryptosystem to the quantum-resistant cryptosystem. In some examples, by placing components for the quantum-resistant cryptosystem (e.g., a quantum-resistant public key, a quantum-resistant digital signature, etc.) and components for the quantum-vulnerable cryptosystem (e.g., a quantum-vulnerable public key, a quantum-vulnerable digital signature, etc.) in a single certificate, multiple effective certificate chains can be embedded into a single certificate chain structure or encoding. With such hybrid certificates, legacy applications can continue using the quantum-vulnerable cryptosystem while upgraded applications can start using the quantum-resistant cryptosystem, allowing both cryptosystems to co-exist in a communication system.
In some implementations, a multi-phase upgrade is used to transition between cryptosystems. With each phase of the transition, additional system components are upgraded, and the reliance on the upgraded (e.g., quantum-resistant) cryptosystem increases. In some examples, a phase of the transition includes upgrading one or more applications and modifying end-entity certificates. In some examples, another phase of the transition includes upgrading a public key infrastructure (PKI) and modifying CA certificates. In some examples, another phase of the transition includes upgrading all remaining applications and removing certificate modifications. Such multi-phase upgrades can be used, for example, in migrations from a quantum-vulnerable cryptosystem to a quantum-resistant cryptosystem or in another type of migration (e.g., in an upgrade to a more secure digital signature algorithm, etc.).
Enterprise systems using PKI can be complex and may involve a number of entities spanning wide geographical or organizational ranges. For example, some large organizations (e.g., corporate organizations, government organizations, etc.) may have millions of users and associated credentials, and they may be deployed across multiple affiliated groups who maintain trust associations (e.g., via entities such as, for example, âBridge CAsâ or other types of entities). In these and other examples, when two entities communicate, the trust relationship between them may involve traversing a number of different certificate authorities maintained within different organizations. Systems having such features and complexities can be transitioned using multiple phases, for example, to ensure continuity and security. In some implementations, entities can perform authentication and identification using the old cryptosystem or the new cryptosystem during one or more phases of the transition, for example, after PKIs and associated applications are upgraded.
FIG. 1 is a block diagram showing aspects of an example communication system 100 . The example communication system 100 shown in FIG. 1 includes a four nodesâtwo entity nodes
102 , 104 , and two certificate authority nodes
112 , 114 . The nodes use a cryptographic scheme to communicate with each other over a network 106 . In the example shown, a quantum-enabled adversary 108 has access to the network 106 , information exchanged on the network 106 or both. In some instances, the quantum-enabled adversary can modify information on the network 106 . The communication system 100 may include additional or different features, and the components in a communication system may be configured to operate as shown in FIG. 1 or in another manner.
In some implementations, nodes in the communication system 100 may have a server-client relationship. For example, the node 102 can be a server and the node 104 can be its client in a served network, or vice-versa. In some implementations, nodes in the communication system 100 may have a peer-to-peer relationship. For example, the nodes
102 , 104 can be peers in a served network, in a peer-to-peer network or another type of network. Nodes may have another type of relationship in the communication system 100 .
In the example shown in FIG. 1 , the communication system 100 uses a public key infrastructure (PKI) for cryptographic correspondence. In a typical public key infrastructure (PKI), entities can authenticate each other based on certificates issued by trusted certificate authorities. The entities in the PKI (e.g., users, user accounts, devices or machines, software modules or other types of entities) each have a user identity and a key pair that includes a public key and a private key, and a certificate authority can issue a digital certificate to bind the public key to the entity's user identity.
In some example PKIs, there are two types of digital certificatesâcertificate authority (CA) certificates and end-entity certificates. A CA certificate can be used to authenticate other certificates. An end-entity certificate can be used to identify an entity (the certificate owner). In the example shown in FIG. 1 , each of the entity nodes
102 , 104 can be associated with an entity that has an end-entity certificate, and each of the certificate authority nodes
112 , 114 can be associated with a certificate authority that has a CA certificate.
Some example PKIs use certificate chains. In a typical certificate chain, a root CA certificate resides at the top of the certificate chain, an end-entity certificate resides at the bottom of the certificate chain, and one or more intermediate CA certificates reside in the middle of the certificate chain (between the root CA certificate and the end-entity certificate). A root CA certificate can be hardcoded and explicitly trusted by the entities in the PKI. An end-entity certificate can be issued to an entity in the PKI and contain the entity's user identity. In some instances, a root certificate authority may issue intermediate CA certificates to subordinate certificate authorities, or a root certificate authority may issue end-entity certificates. In some instances, an intermediate certificate authority may issue intermediate CA certificates to subordinate certificate authorities, or an intermediate certificate authority may issue end-entity certificates. As an example, the certificate authority node 112 in FIG. 1 may be associated with a root certificate authority that has a root CA certificate, and the root certificate authority may issue an intermediate CA certificate to a certificate authority associated with the other certificate authority node 114 . The intermediate certificate authority may issue end-entity certificates to entities associated with the entity nodes
102 , 104 .
An example of a standardized public key infrastructure is the X.509 public key infrastructure, which uses X.509 digital certificates. X.509 certificates typically include a number of basic fields and one or more extensions. The basic fields of an X.509 certificate may include, for example, a signature value field, an issuer field, a validity field, a subject field, a public key field (also called the âsubject public key infoâ field) and others. The signature value field of an X.509 certificate may contain the digital signature computed by the certificate authority to sign the certificate. The issuer field of an X.509 certificate may contain information that identifies the entity that has signed and issued the certificate. The validity field of an X.509 certificate may contain information that identifies the time interval during which the certificate authority warrants that it will maintain information about the status of the certificate. The subject field of an X.509 certificate may contain information (e.g., a user identity) that identifies the entity associated with the public key stored in the public key field (the certificate owner). The public key field of an X.509 certificate may contain the public key of the entity. The public key field of an X.509 certificate may also contain information identifying the cryptographic algorithm with which the pubic key is used.
The extensions of an X.509 certificate may include, for example, standard extensions, private extensions and possibly other types of extensions. Standard extensions may include, for example, key identifiers, key usage information, certificate policies, alternative names, constraints and other types of information. In some implementations, an X.509 certificate can be modified to include additional extensions that are not included in the standard extensions. For instance, an X.509 certificate can be modified to have a private extension that includes another signature value (e.g., another digital signature computed by the certificate authority to sign the certificate using a priv
BACKGROUND
The following description relates to using a digital certificate with multiple cryptography systems (âcryptosystemsâ), for example, in a public key infrastructure.
Cryptography systems are used to communicate securely over public channels. For example, some cryptosystems provide confidentiality by encrypting messages, and some cryptosystems provide authenticity through digital signatures. Many cryptosystems include protocols that use cryptographic keys. For example, in a public key infrastructure (PKI), the cryptographic keys include public and private keys for each entity, and a certificate authority can issue digital certificates to certify the public keys.
DESCRIPTION OF DRAWINGS
FIG. 1 is a block diagram showing aspects of an example communication system.
FIG. 2A is a block diagram showing an example enterprise system transitioning between cryptosystems.
FIG. 2B is a flow diagram showing an example process for transitioning between cryptosystems.
FIG. 3 is a flow diagram showing an example process for issuing a digital certificate for multiple cryptosystems.
FIG. 4 is a flow diagram showing an example process for using a digital certificate in multiple cryptosystems.
FIG. 5 is a block diagram showing an example digital certificate that includes a public key for a quantum-resistant cryptosystem.
FIG. 6 is a block diagram showing an example certificate chain with a digital certificate that includes a public key for a quantum-resistant cryptosystem.
FIG. 7 is a block diagram showing an example digital certificate that includes a certificate authority signature for a quantum-resistant cryptosystem.
FIG. 8 is a block diagram showing an example certificate chain with a digital certificate that includes a certificate authority signature for a quantum-resistant cryptosystem.
FIG. 9 is a block diagram showing an example digital certificate that includes a certificate authority signature and public key for a quantum-resistant cryptosystem.
FIG. 10 is a block diagram showing an example certificate chain with a digital certificate that includes a certificate authority signature and public key for a quantum-resistant cryptosystem.
DETAILED DESCRIPTION
In some aspects of what is described here, a digital certificate can be used with multiple cryptosystems. The digital certificate can include components (e.g., digital signatures, public keys, etc.) for each of the cryptosystems. In some cases, such digital certificates can be used in the context of deploying a new authentication algorithm within an enterprise infrastructure. For instance, such âhybridâ digital certificates can be used in a phased approach to gradually rollout the new cryptosystem as various system components are upgraded to support the new cryptosystem.
In some implementations, hybrid digital certificates can be used by a quantum-vulnerable cryptosystem (e.g., a conventional quantum-vulnerable cryptosystem) and an upgraded quantum-resistant cryptosystem, for example, during a transition from the quantum-vulnerable cryptosystem to the quantum-resistant cryptosystem. In some examples, by placing components for the quantum-resistant cryptosystem (e.g., a quantum-resistant public key, a quantum-resistant digital signature, etc.) and components for the quantum-vulnerable cryptosystem (e.g., a quantum-vulnerable public key, a quantum-vulnerable digital signature, etc.) in a single certificate, multiple effective certificate chains can be embedded into a single certificate chain structure or encoding. With such hybrid certificates, legacy applications can continue using the quantum-vulnerable cryptosystem while upgraded applications can start using the quantum-resistant cryptosystem, allowing both cryptosystems to co-exist in a communication system.
In some implementations, a multi-phase upgrade is used to transition between cryptosystems. With each phase of the transition, additional system components are upgraded, and the reliance on the upgraded (e.g., quantum-resistant) cryptosystem increases. In some examples, a phase of the transition includes upgrading one or more applications and modifying end-entity certificates. In some examples, another phase of the transition includes upgrading a public key infrastructure (PKI) and modifying CA certificates. In some examples, another phase of the transition includes upgrading all remaining applications and removing certificate modifications. Such multi-phase upgrades can be used, for example, in migrations from a quantum-vulnerable cryptosystem to a quantum-resistant cryptosystem or in another type of migration (e.g., in an upgrade to a more secure digital signature algorithm, etc.).
Enterprise systems using PKI can be complex and may involve a number of entities spanning wide geographical or organizational ranges. For example, some large organizations (e.g., corporate organizations, government organizations, etc.) may have millions of users and associated credentials, and they may be deployed across multiple affiliated groups who maintain trust associations (e.g., via entities such as, for example, âBridge CAsâ or other types of entities). In these and other examples, when two entities communicate, the trust relationship between them may involve traversing a number of different certificate authorities maintained within different organizations. Systems having such features and complexities can be transitioned using multiple phases, for example, to ensure continuity and security. In some implementations, entities can perform authentication and identification using the old cryptosystem or the new cryptosystem during one or more phases of the transition, for example, after PKIs and associated applications are upgraded.
FIG. 1 is a block diagram showing aspects of an example communication system 100 . The example communication system 100 shown in FIG. 1 includes a four nodesâtwo entity nodes
102 , 104 , and two certificate authority nodes
112 , 114 . The nodes use a cryptographic scheme to communicate with each other over a network 106 . In the example shown, a quantum-enabled adversary 108 has access to the network 106 , information exchanged on the network 106 or both. In some instances, the quantum-enabled adversary can modify information on the network 106 . The communication system 100 may include additional or different features, and the components in a communication system may be configured to operate as shown in FIG. 1 or in another manner.
In some implementations, nodes in the communication system 100 may have a server-client relationship. For example, the node 102 can be a server and the node 104 can be its client in a served network, or vice-versa. In some implementations, nodes in the communication system 100 may have a peer-to-peer relationship. For example, the nodes
102 , 104 can be peers in a served network, in a peer-to-peer network or another type of network. Nodes may have another type of relationship in the communication system 100 .
In the example shown in FIG. 1 , the communication system 100 uses a public key infrastructure (PKI) for cryptographic correspondence. In a typical public key infrastructure (PKI), entities can authenticate each other based on certificates issued by trusted certificate authorities. The entities in the PKI (e.g., users, user accounts, devices or machines, software modules or other types of entities) each have a user identity and a key pair that includes a public key and a private key, and a certificate authority can issue a digital certificate to bind the public key to the entity's user identity.
In some example PKIs, there are two types of digital certificatesâcertificate authority (CA) certificates and end-entity certificates. A CA certificate can be used to authenticate other certificates. An end-entity certificate can be used to identify an entity (the certificate owner). In the example shown in FIG. 1 , each of the entity nodes
102 , 104 can be associated with an entity that has an end-entity certificate, and each of the certificate authority nodes
112 , 114 can be associated with a certificate authority that has a CA certificate.
Some example PKIs use certificate chains. In a typical certificate chain, a root CA certificate resides at the top of the certificate chain, an end-entity certificate resides at the bottom of the certificate chain, and one or more intermediate CA certificates reside in the middle of the certificate chain (between the root CA certificate and the end-entity certificate). A root CA certificate can be hardcoded and explicitly trusted by the entities in the PKI. An end-entity certificate can be issued to an entity in the PKI and contain the entity's user identity. In some instances, a root certificate authority may issue intermediate CA certificates to subordinate certificate authorities, or a root certificate authority may issue end-entity certificates. In some instances, an intermediate certificate authority may issue intermediate CA certificates to subordinate certificate authorities, or an intermediate certificate authority may issue end-entity certificates. As an example, the certificate authority node 112 in FIG. 1 may be associated with a root certificate authority that has a root CA certificate, and the root certificate authority may issue an intermediate CA certificate to a certificate authority associated with the other certificate authority node 114 . The intermediate certificate authority may issue end-entity certificates to entities associated with the entity nodes
102 , 104 .
An example of a standardized public key infrastructure is the X.509 public key infrastructure, which uses X.509 digital certificates. X.509 certificates typically include a number of basic fields and one or more extensions. The basic fields of an X.509 certificate may include, for example, a signature value field, an issuer field, a validity field, a subject field, a public key field (also called the âsubject public key infoâ field) and others. The signature value field of an X.509 certificate may contain the digital signature computed by the certificate authority to sign the certificate. The issuer field of an X.509 certificate may contain information that identifies the entity that has signed and issued the certificate. The validity field of an X.509 certificate may contain information that identifies the time interval during which the certificate authority warrants that it will maintain information about the status of the certificate. The subject field of an X.509 certificate may contain information (e.g., a user identity) that identifies the entity associated with the public key stored in the public key field (the certificate owner). The public key field of an X.509 certificate may contain the public key of the entity. The public key field of an X.509 certificate may also contain information identifying the cryptographic algorithm with which the pubic key is used.
The extensions of an X.509 certificate may include, for example, standard extensions, private extensions and possibly other types of extensions. Standard extensions may include, for example, key identifiers, key usage information, certificate policies, alternative names, constraints and other types of information. In some implementations, an X.509 certificate can be modified to include additional extensions that are not included in the standard extensions. For instance, an X.509 certificate can be modified to have a private extension that includes another signature value (e.g., another digital signature computed by the certificate authority to sign the certificate using a private key associated with another cryptosystem), another public key of the entity (e.g., a public key associated with another cryptosystem). An X.509 certificate may include other types of information and other extensions or fields.
The nodes in the example communication system 100 include secure communication modules (e.g., a Virtual Private Network (VPN), secure web browsing, secure mail, etc.) or other types of system components that use the PKI for authentication and use the related cryptographic keys for identification (e.g., in a digital signature-based zero-knowledge proof or another type of identification mechanism) to establish the trusted identity of participating entities. The security of such authentication and identification mechanisms may rely on one or more cryptography systems (âcryptosystemsâ). Examples of crypto-systems include a variety of RSA-based cryptosystems, ECC-based cryptosystems, lattice-based cryptosystems and others. A cryptosystem typically defines a set of cryptographic protocols and parameters to be used in the cryptographic protocols.
In some instances, the communication system 100 can use multiple cryptosystems, for example, to provide an additional layer of security, to transition from one cryptosystem to another cryptosystem, to test a new cryptosystem or for another purpose. As an example, the communication system 100 may transition from relying on an ECC-based cryptosystem to relying on a lattice-based cryptosystem for security. As another example, the communication system 100 may transition from relying on one type of ECC-based cryptosystem to relying on another type of ECC-based cryptosystem for security. Since the secure communication modules interface with other nodes in the communication system 100 , the cryptosystems can be transitioned in phases. For example, the new cryptosystem can be introduced through one or more transition phases in which the new and old cryptosystems are both available. The transition phases can allow the new cryptosystem to be introduced without significant interruption in service. An example of a multi-phase transition is shown in FIGS. 2A and 2B ; a cryptosystem may be transitioned in another manner.
In the example shown in FIG. 1 , the communication system 100 can be transitioned from an initial cryptosystem to an upgraded cryptosystem. In some instances, the upgraded cryptosystem uses the same cryptographic protocols as the initial cryptosystem, and uses different parameters in those protocols. For example, an ECC-based cryptosystem can be upgraded to use a new elliptic curve that provides better security. In some instances, the upgraded cryptosystem uses different cryptographic protocols than the initial cryptosystem uses. For example, an ECC-based cryptosystem can be replaced by a lattice-based cryptosystem that provides better security.
In some cases, the communication system 100 is transitioned in a manner that allows the PKI to use a single digital certificate per user identity during the transition. For instance, a single digital certificate may be used in both the initial cryptosystem and the upgraded cryptosystem before, after and during the transition. Maintaining a single digital certificate per user identity can simplify the transition, for example, by reducing the resources needed for secure communication during the transition. For instance, some systems use physical solutions for credential storage which are limited in terms of space as well as limited in terms of ways to interact with them (e.g., for updates), and maintaining a single end-entity certificate can provide a simpler solution for upgrading such system components.
In some instances, the communication system 100 can use both a quantum-vulnerable cryptosystem and a quantum-resistant cryptosystem, for instance, while transitioning from the quantum-vulnerable cryptosystem to the quantum-resistant cryptosystem. For example, it is known that many conventional cryptosystems (e.g., some classic digital signature algorithms such as RSA, DSA, or ECDSA) can be vulnerable to attacks by a quantum computer, and upgrading to quantum-resistant cryptosystems may improve security. In some implementations, the communication system 100 can be transitioned from a quantum-vulnerable cryptosystem to a quantum-resistant cryptosystem using a phased migration. The phased migration can be designed to smoothly transition secure communication modules (e.g., a Virtual Private Network (VPN), secure web browsing, secure mail, etc.) or other types of system components from the quantum-vulnerable cryptosystem to the quantum-resistant cryptosystem.
In the example shown in FIG. 1 , the example entity nodes
102 , 104 and the certificate authority nodes
112 , 114 each have computational resources (e.g., hardware, software, firmware) that are used to communicate with other nodes. In some implementations, nodes in the communication system 100 can be implemented in various systems, such as, for example, laptops, desktops, workstations, smartphones, tablets, personal digital assistants, servers, server clusters, mainframes, and other types of computer systems. As shown in FIG. 1 , the example node 102 includes a memory 110 , a processor 111 and an interface 113 . Each of the entity nodes
102 , 104 and the certificate authority nodes
112 , 114 may include the same, additional or different components. The entity nodes
102 , 104 and the certificate authority nodes
112 , 114 may be configured to operate as shown and described with respect to FIG. 1 or in another manner. In some cases, a single device may operate both as an entity node and as a certificate authority node.
In the example node 102 shown in FIG. 1 , the memory 110 can include, for example, random access memory (RAM), a storage device (e.g., a writable read-only memory (ROM) or others), a hard disk, or another type of storage medium. The example memory 110 can store instructions (e.g., computer code, a computer program, etc.) associated with an operating system, computer applications and other resources. The memory 110 can also store application data and data objects that can be interpreted by one or more applications or virtual machines running on the node 102 . The node 102 can be preprogrammed, or it can be programmed (and reprogrammed), by loading a program from another source (e.g., from a DVD-ROM, from a removable memory device, from a remote server, from a data network or in another manner). In some cases, the memory 110 stores computer-readable instructions for software applications, scripts, programs, functions, executables or other modules that are interpreted or executed by the processor 111 . For example, the computer-readable instructions can be configured to perform one or more of the operations shown in FIGS. 3 and 4 .
In the example node 102 shown in FIG. 1 , the processor 111 can execute instructions, for example, to generate output data based on data inputs. For example, the processor 111 can run computer programs by executing or interpreting the software, scripts, programs, functions, executables, or other modules stored in the memory 110 . In some instances, the processor 111 may perform one or more of the operations shown in FIGS. 3 and 4 .
The example processor 111 shown in FIG. 1 can include one or more chips or chipsets that include analog circuitry, digital circuitry or a combination thereof. In some cases, the processor 111 includes multiple processor devices such as, for example, one or more main processors and one or more co-processors. For instance, the processor 111 may include a main processor that can delegate certain computational tasks to a cryptographic co-processor, which may be configured to perform the computational tasks more efficiently than the main processor or in parallel with other computational tasks performed by other processor devices. In some instances, the processor 111 coordinates or controls operation of other components of the node 102 , such as, for example, user interfaces, communication interfaces, peripheral devices and possibly other components.
In the example node 102 shown in FIG. 1 , the interface 113 provides communication with other nodes or devices. In some cases, the interface 113 includes a wireless communication interface that provides wireless communication under various wireless protocols, such as, for example, 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) among others. Such communication may occur, for example, through a radio-frequency transceiver or another type of component. In some cases, the interface 113 includes a wired communication interface (e.g., USB, Ethernet) that can be connected to one or more input/output devices, such as, for example, a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, for example, through a network adapter.
The example network 106 can include all or part of a connector, a data communication network or another type of communication link. For example, the network 106 can include one or more wired or wireless connections, one or more wired or wireless networks or other communication 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 network involving machine-to-machine (M2M) communication, or another type of data communication network.
In the example shown, the quantum-enabled adversary 108 has access to quantum computational resources. For example, the quantum-enabled adversary 108 can be, include, or have access to a quantum computer, a quantum information processor, a quantum memory, a quantum communication interface or a combination of these and possibly other quantum technologies. In some implementations, the quantum-enabled adversary 108 can include a hybrid computing system, for instance, that includes a quantum processor driven by a classical front end processor, or another type of hybrid computing system.
In some examples, the quantum-enabled adversary 108 can store and process information in a quantum system. For instance, the quantum-enabled adversary 108 may encode information as quantum bits (âqubitsâ) and process the information by manipulating the qubits. The information may be encoded in physical qubits, logical qubits, or a combination of these and other types of qubits encodings. In some implementations, the quantum-enabled adversary 108 can operate in a fault-tolerant regime, or the quantum-enabled adversary may operate below the fault-tolerant regime.
Many public-key cryptography systems are known to be insecure against an attacker armed with a scalable quantum computer. For example, the Diffie-Hellman (DH) and elliptic curve Diffie-Hellman (ECDH) key agreement protocols are vulnerable to certain types of attacks by quantum-enabled adversaries. The threat of quantum computers to public key cryptography can be mitigated by switching to other public key cryptosystems that are believed to be invulnerable to quantum attack. For example, lattice-based cryptosystems have been proposed as quantum-resistant replacements for certain RSA-based or ECC-based cryptosystems that are believed to be quantum-vulnerable.
In some implementations, the example quantum-enabled adversary 108 can perform quantum computing algorithms, execute quantum computing circuits or quantum communication protocols, or perform other types of quantum information processing tasks. In the example shown, the quantum-enabled adversary 108 can perform Shor's algorithm, which allows the quantum-enabled adversary to efficiently solve problems that are believed to be hard on a classical computer. For example, the quantum-enabled adversary 108 may use Shor's algorithm to factor large integers, find discrete logarithms or possibly to solve other problems in a computationally-efficient manner. Accordingly, the example quantum-enabled adversary 108 can compromise the security of certain quantum-vulnerable cryptosystems (e.g., by computing a private key of a certificate authority or other entity based on public information).
The example quantum-enabled adversary 108 shown in FIG. 1 can access information exchanged on the network 106 . For example, the quantum-enabled adversary 108 may access some or all of the information exchanged between the entity nodes
102 , 104 or between an entity node and a certificate authority node. In some instances, the quantum-enabled adversary 108 can directly observe correspondence on the network 106 ; in some instances, the quantum-enabled adversary 108 indirectly obtains such correspondence, for example, by receiving information observed on the network 106 by another entity or system.
In some implementations, the quantum-enabled adversary 108 can factor integers, compute discrete logarithms or perform other classically-hard computational tasks fast enough to compromise the security of certain cryptography systems. For example, the quantum-enabled adversary 108 may be capable of computing prime factors fast enough to compromise certain RSA encryption standards or computing discrete logarithms fast enough to compromise certain ECC encryption standards.
In the example shown in FIG. 1 , the entity nodes
102 , 104 and the certificate authority nodes
112 , 114 may use a quantum-resistant cryptosystem that cannot be compromised by the example quantum-enabled adversary 108 . For instance, the entity nodes
102 , 104 may communicate using a cryptosystem that is secure against a quantum computer that can efficiently execute Shor's algorithm or other types of algorithms that are known to compromise the security of certain conventional cryptography standards. In some instances, the quantum-resistant cryptosystem can be used in parallel with a quantum-vulnerable cryptosystem. For example, the communication system 100 may transition from using a quantum-vulnerable cryptosystem to using a quantum-resistant cryptosystem in one or more transition phases, and both cryptosystems can be available for use during a transition phase.
In some implementations, the nodes
102 , 104 use a digital signature scheme that allows each node to verify the authenticity of messages received from the other node. In some implementations, the nodes
102 , 104 use an encryption scheme that allows each node to send confidential messages to the other nodes. Such digital signature schemes and encryption schemes can include or be performed based on a digital certificate. In some example schemes, the entity nodes
102 , 104 and the certificate authority nodes
112 , 114 can use the example techniques shown in or described with respect to any one or more of FIG. 2A, 2B, 3, 4, 5, 6, 7, 8, 9 or 10 ; or the entity nodes
102 , 104 and the certificate authority nodes
112 , 114 may use variations of these and other techniques to communicate in the network 106 . In some instances, multiple digital signature schemes or multiple encryption schemes are used, for example, during a transition between cryptosystems.
In some implementations, the entity nodes
102 , 104 and the certificate authority nodes
112 , 114 use an elliptic curve cryptography (ECC) scheme in their communications over the network 106 . In some ECC schemes, information is encoded in elliptic curve points in an elliptic curve group. An elliptic curve group can be described in terms of a solution to an equation over a finite field, for example, a prime finite field or a characteristic-two extension field. Each point in the elliptic curve group is a pair of field elements corresponding to a solution to an elliptic curve equation. A number of ECC digital signature algorithms have been standardized, for example, ECDSA (Elliptic Curve Digital Signature Algorithm), ECNR (Elliptic Curve Nyberg Rueppel), ECPVS (Elliptic Curve Pintsov Vanstone Signatures), ECQV (Elliptic Curve Qu Vanstone) and EdDSA (Edwards-curve Digital Signature Algorithm). Some ECC schemes are believed to be vulnerable to quantum attacks.
In some implementations, the entity nodes
102 , 104 and the certificate authority nodes
112 , 114 use a lattice-based cryptography scheme in their communications over the network 106 . The security of lattice-based cryptography schemes is based on the apparent hardness of certain problems on point lattices in
n . Some lattice-based cryptography schemes are believed to be secure against quantum-enabled adversaries. For example, it is believed that no efficient quantum algorithms are known for the hard problems typically used in lattice-based cryptography. Examples of lattice-based cryptography techniques include ring-learning-with-errors-based (Ring-LWE) key agreement protocols, Ring-LWE encryption protocols, NTRU algorithms (e.g., NTRUEncrypt, NTRUSign, etc.), Bimodal Lattice Signature Schemes (BLISS), PASS algorithms (e.g., PASSSign, etc.), TESLA (Tightly-secure, Efficient signature scheme from Standard LAttices) protocols, ring-TESLA protocols and others. Some lattice-based schemes are believed to be resistant to quantum attacks.
FIG. 2A is a block diagram showing example enterprise system 200 transitioning between cryptosystems. The example enterprise system 200 shown in FIG. 2A includes a public key infrastructure (PKI) 201 and
applications
202 , 204 , 206 . The enterprise system 200 shown in FIG. 2A is transitioned according to an example transition process 220 . In some implementations, the example transition process 220 can be used to fully upgrade an enterprise infrastructure in a manner that reduces or eliminates interruptions. FIG. 2B is a flow diagram showing the example transition process 220 that is used in FIG. 2A for transitioning between cryptosystems. Another type of transition process may be used in some cases.
Components of the enterprise system 200 shown in FIG. 2A may be implemented in the example communication system 100 shown in FIG. 1 or in another type of system. For example, each of the
applications
202 , 204 , 206 can be executed on the entities nodes
102 , 104 and certificate authority nodes
112 , 114 . The
applications
202 , 204 , 206<
CLAIMS
Claims ( 39 )
What is claimed is:
1. A method of issuing a digital certificate comprising:
receiving, at a node in a communication system, a certificate request comprising a first public key of an entity, the first public key being associated with a first cryptosystem;
generating a digital certificate comprising unpopulated fields;
populating a public key field of the digital certificate with the first public key of the entity;
populating an extension of the digital certificate with a second public key of the entity, the second public key being associated with a second cryptosystem;
by operation of one or more processors, using a first private key of the certificate authority to generate a first digital signature based on information in the certificate request, the first private key of the certificate authority being associated with the first cryptosystem, the first digital signature generated from the digital certificate comprising the first public key in the public key field and the second public key in the extension; and
populating a signature value field of the digital certificate with the first digital signature.
2. The method of claim 1 , wherein the first cryptosystem comprises a quantum-vulnerable cryptosystem, and the second cryptosystem comprises a quantum-resistant cryptosystem.
3. The method of claim 1 , further comprising sending the digital certificate from a certificate authority node to a node associated with the entity.
4. The method of claim 1 , wherein the certificate request comprises a certificate request signature, and the method comprises verifying the certificate request signature using the first public key of the entity.
5. The method of claim 1 , wherein:
the certificate request comprises the second public key of the entity, a first certificate request signature and a second certificate request signature, the first certificate request signature being associated with the first cryptosystem, the second certificate request signature being associated with the second cryptosystem, and
the method comprises:
verifying the first certificate request signature using the first public key of the entity; and
verifying the second certificate request signature using the second public key of the entity.
6. A method of issuing a digital certificate comprising:
receiving, at a node in a communication system, a certificate request comprising a first public key of an entity, the first public key being associated with a first cryptosystem;
generating a digital certificate comprising unpopulated fields;
populating a public key field of the digital certificate with the first public key of the entity;
by operation of one or more processors, using a second private key of the certificate authority to generate a second digital signature, the second private key of the certificate authority being associated with a second cryptosystem, the second digital signature generated from the digital certificate comprising the first public key in the public key field;
populating an extension of the digital certificate with the second digital signature;
by operation of one or more processors, using a first private key of the certificate authority to generate a first digital signature based on information in the certificate request, the first private key of the certificate authority being associated with the first cryptosystem, the first digital signature generated from the digital certificate comprising the first public key in the public key field and the second digital signature in the extension; and
populating a signature value field of the digital certificate with the first digital signature.
7. The method of claim 6 , wherein the first cryptosystem comprises a quantum-vulnerable cryptosystem, and the second cryptosystem comprises a quantum-resistant cryptosystem.
8. The method of claim 6 , further comprising sending the digital certificate from a certificate authority node to a node associated with the entity.
9. The method of claim 6 , wherein the certificate request comprises a certificate request signature, and the method comprises verifying the certificate request signature using the first public key of the entity.
10. The method of claim 6 , wherein:
the certificate request comprises the second public key of the entity, a first certificate request signature and a second certificate request signature, the first certificate request signature being associated with the first cryptosystem, the second certificate request signature being associated with the second cryptosystem, and
the method comprises:
verifying the first certificate request signature using the first public key of the entity; and
verifying the second certificate request signature using the second public key of the entity.
11. A method of issuing a digital certificate comprising:
receiving, at a node in a communication system, a certificate request comprising a first public key of an entity, the first public key being associated with a first cryptosystem;
generating a digital certificate comprising unpopulated fields;
populating a public key field of the digital certificate with the first public key of the entity;
populating an extension of the digital certificate with a second public key of the entity, the second public key being associated with a second cryptosystem;
by operation of one or more processors, using a second private key of the certificate authority to generate a second digital signature, the second private key of the certificate authority being associated with the second cryptosystem, the second digital signature generated from the digital certificate comprising the first public key in the public key field and the second public key in the extension;
populating the extension of the digital certificate with the second digital signature;
by operation of one or more processors, using a first private key of the certificate authority to generate a first digital signature based on information in the certificate request, the first private key of the certificate authority being associated with the first cryptosystem, the first digital signature generated from the digital certificate comprising the first public key in the public key field, the second public key in the extension and the second digital signature in the extension; and
populating a signature value field of the digital certificate with the first digital signature.
12. The method of claim 11 , wherein the first cryptosystem comprises a quantum-vulnerable cryptosystem, and the second cryptosystem comprises a quantum-resistant cryptosystem.
13. The method of claim 11 , further comprising sending the digital certificate from a certificate authority node to a node associated with the entity.
14. The method of claim 11 , wherein the certificate request comprises a certificate request signature, and the method comprises verifying the certificate request signature using the first public key of the entity.
15. The method of claim 11 , wherein:
the certificate request comprises the second public key of the entity, a first certificate request signature and a second certificate request signature, the first certificate request signature being associated with the first cryptosystem, the second certificate request signature being associated with the second cryptosystem, and
the method comprises:
verifying the first certificate request signature using the first public key of the entity; and
verifying the second certificate request signature using the second public key of the entity.
16. A computer system comprising:
a data processing apparatus; and
a non-transitory computer-readable medium storing instructions that are operable when executed by the data processing apparatus to perform operations comprising:
receiving a certificate request comprising a first public key of an entity, the first public key being associated with a first cryptosystem;
generating a digital certificate comprising unpopulated fields;
populating a public key field of the digital certificate with the first public key of the entity;
populating an extension of the digital certificate with a second public key of the entity;
using a first private key of the certificate authority to generate the first digital signature based on information in the certificate request, the first private key of the certificate authority being associated with the first cryptosystem, the first digital signature generated from the digital certificate comprising the first public key in the public key field and the second public key in the extension; and
populating a signature value field of the digital certificate with the first digital signature.
17. The system of claim 16 , wherein the certificate request comprises a certificate request signature, and the method comprises verifying the certificate request signature using the first public key of the entity.
18. The system of claim 16 , wherein:
the certificate request comprises the second public key of the entity, a first certificate request signature and a second certificate request signature, the first certificate request signature being associated with the first cryptosystem, the second certificate request signature being associated with the second cryptosystem, and
the operations comprise:
verifying the first certificate request signature using the first public key of the entity; and
verifying the second certificate request signature using the second public key of the entity.
19. The system of claim 16 , wherein the first cryptosystem comprises a quantum-vulnerable cryptosystem, and the second cryptosystem comprises a quantum-resistant cryptosystem.
20. A computer system comprising:
a data processing apparatus; and
a non-transitory computer-readable medium storing instructions that are operable when executed by the data processing apparatus to perform operations comprising:
receiving a certificate request comprising a first public key of an entity, the first public key being associated with a first cryptosystem;
generating a digital certificate comprising unpopulated fields;
populating a public key field of the digital certificate with the first public key of the entity;
using a second private key of the certificate authority to generate a second digital signature, the second private key of the certificate authority being associated with a second cryptosystem, the second digital signature generated from the digital certificate comprising the first public key in the public key field;
populating an extension of the digital certificate with the second digital signature;
using a first private key of the certificate authority to generate a first digital signature based on information in the certificate request, the first private key of the certificate authority being associated with the first cryptosystem, the first digital signature generated from the digital certificate comprising the first public key in the public key field and the second digital signature in the extension; and
populating a signature value field of the digital certificate with the first digital signature.
21. The system of claim 20 , wherein the certificate request comprises a certificate request signature, and the method comprises verifying the certificate request signature using the first public key of the entity.
22. The system of claim 20 , wherein:
the certificate request comprises the second public key of the entity, a first certificate request signature and a second certificate request signature, the first certificate request signature being associated with the first cryptosystem, the second certificate request signature being associated with the second cryptosystem, and
the operations comprise:
verifying the first certificate request signature using the first public key of the entity; and
verifying the second certificate request signature using the second public key of the entity.
23. The system of claim 20 , wherein the first cryptosystem comprises a quantum-vulnerable cryptosystem, and the second cryptosystem comprises a quantum-resistant cryptosystem.
24. A computer system comprising:
a data processing apparatus; and
a non-transitory computer-readable medium storing instructions that are operable when executed by the data processing apparatus to perform operations comprising:
receiving a certificate request comprising a first public key of an entity, the first public key being associated with a first cryptosystem;
generating a digital certificate comprising unpopulated fields;
populating a public key field of the digital certificate with the first public key of the entity;
populating an extension of the digital certificate with a second public key of the entity, the second public key being associated with a second cryptosystem;
using a second private key of the certificate authority to generate a second digital signature, the second private key of the certificate authority being associated with the second cryptosystem, the second digital signature generated from the digital certificate comprising the first public key in the public key field and the second public key in the extension;
populating the extension of the digital certificate with the second digital signature;
using a first private key of the certificate authority to generate a first digital signature based on information in the certificate request, the first private key of the certificate authority being associated with the first cryptosystem, the first digital signature generated from the digital certificate comprising the first public key in the public key field, the second public key in the extension and the second digital signature in the extension; and
populating a signature value field of the digital certificate with the first digital signature.
25. The system of claim 24 , wherein the certificate request comprises a certificate request signature, and the method comprises verifying the certificate request signature using the first public key of the entity.
26. The system of claim 24 , wherein:
the certificate request comprises the second public key of the entity, a first certificate request signature and a second certificate request signature, the first certificate request signature being associated with the first cryptosystem, the second certificate request signature being associated with the second cryptosystem, and
the operations comprise:
verifying the first certificate request signature using the first public key of the entity; and
verifying the second certificate request signature using the second public key of the entity.
27. The system of claim 24 , wherein the first cryptosystem comprises a quantum-vulnerable cryptosystem, and the second cryptosystem comprises a quantum-resistant cryptosystem.
28. A cryptography method comprising:
receiving, at a node in a communication system, a digital certificate comprising:
a public key field comprising a first public key of an entity, the first public key of the entity being associated with a first cryptosystem:
a signature value field comprising a first digital signature of a certificate authority, the first digital signature being associated with the first cryptosystem; and
an extension comprising a second digital signature of a certificate authority, the second digital signature being associated with a second cryptosystem; and
by operation of one or more processors, generating a certificate digest based at least in part on the extension; and
using the certificate digest and a public key of the certificate authority to verify the second digital signature of the certificate authority, the public key of the certificate authority being associated with the second cryptosystem.
29. The method of claim 28 , further comprising:
receiving a message and a digital signature of the entity; and
using the first public key of the entity to verify the digital signature of the entity.
30. The method of claim 28 , further comprising using the first public key of the entity to encrypt a message addressed to the entity.
31. The method of claim 28 , wherein the first cryptosystem comprises a quantum-vulnerable cryptosystem, and the second cryptosystem comprises a quantum-resistant cryptosystem.
32. A cryptography method comprising:
receiving, at a node in a communication system, a digital certificate comprising:
a public key field comprising a first public key of an entity, the first public key of the entity being associated with a first cryptosystem;
a signature value field comprising a first digital signature of a certificate authority, the first digital signature being associated with the first cryptosystem; and
an extension comprising a second public key of the entity, the second public key being associated with a second cryptosystem
by operation of one or more processors, generating a certificate digest based at least in part on the extension; and
using the certificate digest and a public key of the certificate authority to verify the first digital signature of the certificate authority, and the public key of the certificate authority being associated with the first cryptosystem.
33. The method of claim 32 , further comprising:
receiving a message and a digital signature of the entity; and
using the second public key of the entity to verify the digital signature of the entity.
34. The method of claim 32 , further comprising using the second public key of the entity to encrypt a message addressed to the entity.
35. The method of claim 32 , wherein the first cryptosystem comprises a quantum-vulnerable cryptosystem, and the second cryptosystem comprises a quantum-resistant cryptosystem.
36. A computer system comprising:
a data processing apparatus; and
a non-transitory computer-readable medium storing instructions that are operable when executed by the data processing apparatus to perform operations comprising:
receiving a digital certificate comprising:
a public key field comprising a first public key of an entity, the first public key of the entity being associated with a first cryptosystem;
a signature value field comprising a first digital signature of a certificate authority, the first digital signature being associated with the first cryptosystem; and
an extension comprising a second public key of the entity, the second public key being associated with a second cryptosystem;
generating a certificate digest based at least in part on the extension; and using the certificate digest and a public key of the certificate authority to verify the first digital signature of the certificate authority, the public key of the certificate authority being associated with the first cryptosystem.
37. The system of claim 36 , wherein the first cryptosystem comprises a quantum-vulnerable cryptosystem, and the second cryptosystem comprises a quantum-resistant cryptosystem.
38. The system of claim 36 , wherein the operations further comprise:
receiving a message and a digital signature of the entity; and
using the second public key of the entity to verify the digital signature of the entity.
39. The system of claim 36 , wherein the operations further comprise using the second public key of the entity to encrypt a message addressed to the entity.
US15/230,819
2016-08-08
2016-08-08
Using a digital certificate with multiple cryptosystems
Expired - Fee Related
US9660978B1
( en )
Priority Applications (6)
Application Number
Priority Date
Filing Date
Title
US15/230,819
US9660978B1
( en )
2016-08-08
2016-08-08
Using a digital certificate with multiple cryptosystems
EP17838243.8A
EP3497879A4
( en )
2016-08-08
2017-03-10
USE OF A DIGITAL CERTIFICATE WITH SEVERAL CRYPTOSYSTEMS
JP2018533833A
JP6644894B2
( en )
2016-08-08
2017-03-10
Using digital certificates with multiple cryptosystems
PCT/CA2017/050317
WO2018027300A1
( en )
2016-08-08
2017-03-10
Using a digital certificate with multiple cryptosystems
US15/480,529
US9794249B1
( en )
2016-08-08
2017-04-06
Using a digital certificate with multiple cryptosystems
JP2019172555A
JP2020010396A
( en )
2016-08-08
2019-09-24
Plurality of cryptographic systems and use of digital certificate
Applications Claiming Priority (1)
Application Number
Priority Date
Filing Date
Title
US15/230,819
US9660978B1
( en )
2016-08-08
2016-08-08
Using a digital certificate with multiple cryptosystems
Related Child Applications (1)
Application Number
Title
Priority Date
Filing Date
US15/480,529
Continuation
US9794249B1
( en )
2016-08-08
2017-04-06
Using a digital certificate with multiple cryptosystems
Publications (1)
Publication Number
Publication Date
US9660978B1
true
US9660978B1 ( en )
2017-05-23
Family
ID=58708225
Family Applications (2)
Application Number
Title
Priority Date
Filing Date
US15/230,819
Expired - Fee Related
US9660978B1
( en )
2016-08-08
2016-08-08
Using a digital certificate with multiple cryptosystems
US15/480,529
Expired - Fee Related
US9794249B1
( en )
2016-08-08
2017-04-06
Using a digital certificate with multiple cryptosystems
Family Applications After (1)
Application Number
Title
Priority Date
Filing Date
US15/480,529
Expired - Fee Related
US9794249B1
( en )
2016-08-08
2017-04-06
Using a digital certificate with multiple cryptosystems
Country Status (4)
Country
Link
US
( 2 )
US9660978B1
( en )
EP
( 1 )
EP3497879A4
( en )
JP
( 2 )
JP6644894B2
( en )
WO
( 1 )
WO2018027300A1
( en )
Cited By (51)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US9794249B1
( en )
2016-08-08
2017-10-17
ISARA Corporation
Using a digital certificate with multiple cryptosystems
US20180343127A1
( en )
*
2017-05-08
2018-11-29
Amazon Technologies, Inc.
Communication protocol using implicit certificates
CN109039604A
( en )
*
2018-08-07
2018-12-18
å京é®çµå¤§å¦
A kind of passive type trick state Quantum Digital Signature Research method
EP3432510A1
( en )
*
2017-07-18
2019-01-23
Siemens Aktiengesellschaft
Managing a digital certificate
CN109672537A
( en )
*
2019-01-18
2019-04-23
å¦è¬éåç§ææéå ¬å¸
Anti- quantum certificate acquisition system and acquisition methods based on public key pond
WO2019111513A1
( en )
*
2017-12-08
2019-06-13
ã½ãã¼æ ªå¼ä¼ç¤¾
Information processing device, registration device, information processing method, registration method, and program
US20190260595A1
( en )
*
2018-02-21
2019-08-22
Microsoft Technology Licensing, Llc
Management of public key certificates within a distributed architecture
US10425401B1
( en )
2018-10-31
2019-09-24
ISARA Corporation
Extensions for using a digital certificate with multiple cryptosystems
US10511591B2
( en )
2017-05-08
2019-12-17
Amazon Technologies, Inc.
Generation of shared secrets using pairwise implicit certificates
US10552827B2
( en )
*
2014-09-02
2020-02-04
Google Llc
Dynamic digital certificate updating
US10742420B1
( en )
*
2018-03-09
2020-08-11
Wells Fargo Bank, N.A.
Quantum-resistant double signature system
CN111628860A
( en )
*
2019-02-28
2020-09-04
æ¦æ±ä¿¡å®ççç§ææéå ¬å¸
Method for generating and applying double-key system digital certificate
US10798086B2
( en )
2017-05-08
2020-10-06
Amazon Technologies, Inc.
Implicit certificates using ring learning with errors
CN112104453A
( en )
*
2020-08-06
2020-12-18
å¦è¬éåç§ææéå ¬å¸
Anti-quantum computation digital signature system and signature method based on digital certificate
US10958450B1
( en )
2020-10-15
2021-03-23
ISARA Corporation
Constructing a multiple-entity root certificate data block chain
US11146397B2
( en )
*
2017-10-31
2021-10-12
Micro Focus Llc
Encoding abelian variety-based ciphertext with metadata
US20210377049A1
( en )
*
2020-06-02
2021-12-02
John A. Nix
Combined Digital Signature Algorithms for Security Against Quantum Computers
US20210377736A1
( en )
*
2020-05-28
2021-12-02
Fujifilm Business Innovation Corp.
Radio base station apparatus, non-transitory computer readable medium storing radio base station program, and radio communication system
US11265159B1
( en )
2021-01-11
2022-03-01
ISARA Corporation
Determining upgradability scores and identifying remedial security measures in a computing environment
US11316701B1
( en )
*
2019-10-22
2022-04-26
ZT Group Int'l, Inc.
Decentralized system for generation and deployment of digital certificates
US11533161B1
( en )
*
2018-07-20
2022-12-20
Verisign, Inc.
DNS-based public key infrastructure for digital object architectures
US11615060B2
( en )
2018-04-12
2023-03-28
ISARA Corporation
Constructing a multiple entity root of trust
US11632246B2
( en )
2020-12-30
2023-04-18
International Business Machines Corporation
Hybrid key derivation to secure data
CN116155515A
( en )
*
2023-04-20
2023-05-23
䏿±½æºèææ¯æéå ¬å¸
Type-selectable double-key certificate generation method, electronic device and storage medium
US11716206B2
( en )
2020-11-02
2023-08-01
International Business Machines Corporation
Certificate based security using post quantum cryptography
US20230269331A1
( en )
*
2022-02-22
2023-08-24
Google Llc
Using STIR/SHAKEN ID Headers to Allow Access into VoIP Networks
US11757659B2
( en )
2020-12-01
2023-09-12
International Business Machines Corporation
Post-quantum certificate binding
US11764972B2
( en )
*
2021-02-25
2023-09-19
International Business Machines Corporation
Generating a hybrid security certificate using multiple cryptosystems
US20240106834A1
( en )
*
2022-09-27
2024-03-28
Fujitsu Limited
Computer-readable recording medium storing information management program, information management method, information processing device, and information sharing system
US20240121615A1
( en )
*
2021-02-02
2024-04-11
Mercedes-Benz Group AG
Method for securing communication between a communication system of a vehicle and a vehicle-external server
EP4407928A1
( en )
2023-01-30
2024-07-31
Siemens Aktiengesellschaft
Authentication as a function of other digital certificates
US12107878B1
( en )
2023-09-05
2024-10-01
ISARA Corporation
Identifying cryptography usage risks
CN118827067A
( en )
*
2024-09-19
2024-10-22
ä¸ééè认è¯ä¸å¿æéå ¬å¸
Post-quantum digital certificate application method, device, electronic device and storage medium
CN118827066A
( en )
*
2024-09-19
2024-10-22
ä¸ééè认è¯ä¸å¿æéå ¬å¸
Method, device, electronic device and storage medium for generating post-quantum digital certificates
EP4459924A1
( en )
2023-05-05
2024-11-06
Siemens Aktiengesellschaft
Attribute certificate comprising cryptographic additional information relating to a digital certificate
US12184792B1
( en )
*
2022-12-06
2024-12-31
Wells Fargo Bank, N.A.
Systems and methods for managing keys of digital certificates
US20250141696A1
( en )
*
2023-10-25
2025-05-01
Oracle International Corporation
Authorizing Requests For Access Credentials, For Accessing Cloud Resources, Based On Successful Stateless Validation Of Digital Certificates
US12381737B2
( en )
2022-02-21
2025-08-05
Fujitsu Limited
Verification method and information processing apparatus
US20250267013A1
( en )
*
2024-02-15
2025-08-21
Wells Fargo Bank, N.A.
Public key infrastructure attribute certificate tweak (pact)
US12401526B2
( en )
2023-07-18
2025-08-26
Oracle International Corporation
Updating digital certificates associated with a virtual cloud network
US12401634B2
( en )
2023-09-14
2025-08-26
Oracle International Corporation
Distributing certificate bundles according to fault domains
US12401657B2
( en )
2023-09-13
2025-08-26
Oracle International Corporation
Aggregating certificate authority certificates for authenticating network entities located in different trust zones
US12425239B2
( en )
2023-08-10
2025-09-23
Oracle International Corporation
Authenticating certificate bundles with asymmetric keys
US12425236B2
( en )
2022-07-22
2025-09-23
ISARA Corporation
Certificate validation using a multiple-key-pair root certificate authority
US12425240B2
( en )
2023-09-13
2025-09-23
Oracle International Corporation
Certificate revocation list management services
US12432076B2
( en )
2023-10-24
2025-09-30
Oracle International Corporation
Provisioning hosts with operator accounts for use by clients to access target resources
US12495032B2
( en )
2024-03-08
2025-12-09
Oracle International Corporation
Orchestrating distribution of digital certificates to an execution environment of a computing network
EP4683271A1
( en )
2024-07-19
2026-01-21
Siemens Aktiengesellschaft
Certification authority device, a subject device and a method for operating a certification authority device
EP4687320A1
( en )
*
2024-08-01
2026-02-04
Nagravision Sarl
Method for updating a quantum-resistant cryptographic key pair and certificate for use in a public-key infrastructure
US12563029B2
( en )
2023-07-18
2026-02-24
Oracle International Corporation
Provisioning cloud resource instances associated with a virtual cloud network
US12562966B2
( en )
2023-05-19
2026-02-24
Oracle International Corporation
Transitioning network entities associated with a virtual cloud network through a series of phases of a certificate bundle distribution process
Families Citing this family (14)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
CN107453865B
( en )
*
2017-07-18
2020-09-11
ä¼å®ä¿¡æ¯ææ¯æå¡æéå ¬å¸
A multi-party data sharing method and system for protecting the privacy of data transmission source
CN107919956B
( en )
*
2018-01-04
2020-09-22
éåºé®çµå¤§å¦
An end-to-end security assurance method for IoT cloud environment
FR3076923A1
( en )
*
2018-01-16
2019-07-19
Stmicroelectronics (Rousset) Sas
METHOD AND AUTHENTICATION CIRCUIT
CN109586918B
( en )
*
2018-10-31
2021-08-31
å¦è¬éåç§ææéå ¬å¸
Anti-quantum-computation signature method and signature system based on symmetric key pool
CN109600218B
( en )
*
2018-11-21
2021-02-12
å京èªç©ºèªå¤©å¤§å¦
Anonymous PKI system with traceable user identity
FR3098949B1
( en )
2019-07-15
2023-10-06
St Microelectronics Rousset
One-way function
CN114830602B
( en )
*
2019-12-17
2024-08-02
å¾®è¯çææ¯è¡ä»½æéå ¬å¸
Mutual authentication protocol for systems of low throughput communication links and devices for performing the protocol
US11489830B2
( en )
2020-01-09
2022-11-01
Kyndryl, Inc.
Source authentication of website content
US11374975B2
( en )
*
2020-07-02
2022-06-28
International Business Machines Corporation
TLS integration of post quantum cryptographic algorithms
WO2022040215A1
( en )
*
2020-08-18
2022-02-24
Entrust, Inc.
Binding of multiple heterogeneous root certificate authorities
US20230412397A1
( en )
*
2022-06-16
2023-12-21
ISARA Corporation
Transitioning To and From Crypto-Agile Hybrid Public Key Infrastructures
WO2024192130A1
( en )
2023-03-13
2024-09-19
Microchip Technology Incorporated
Connectivity framework having session layer security for embedded secure connectivity
EP4440033B1
( en )
2023-03-31
2025-03-12
Sick Ag
Authenticating data based on certificates
WO2024236896A1
( en )
*
2023-05-12
2024-11-21
ããã½ããã¯ï¼©ï½ããã¸ã¡ã³ãæ ªå¼ä¼ç¤¾
Communication method, communication terminal, and communication system
Citations (11)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US5432852A
( en )
1993-09-29
1995-07-11
Leighton; Frank T.
Large provably fast and secure digital signature schemes based on secure hash functions
US20030009694A1
( en )
*
2001-02-25
2003-01-09
Storymail, Inc.
Hardware architecture, operating system and network transport neutral system, method and computer program product for secure communications and messaging
US20030041110A1
( en )
*
2000-07-28
2003-02-27
Storymail, Inc.
System, Method and Structure for generating and using a compressed digital certificate
US20040003235A1
( en )
*
2002-06-28
2004-01-01
Mehmet Musa
Method for upgrading a host/agent security system that includes digital certificate management and an upgradable backward compatible host/agent security system digital certificate infrastructure
US20050144437A1
( en )
*
1994-12-30
2005-06-30
Ransom Douglas S.
System and method for assigning an identity to an intelligent electronic device
US20110055585A1
( en )
*
2008-07-25
2011-03-03
Kok-Wah Lee
Methods and Systems to Create Big Memorizable Secrets and Their Applications in Information Engineering
US20120233457A1
( en )
2011-03-08
2012-09-13
Certicom Corp.
Issuing implicit certificates
US20120284508A1
( en )
2011-05-06
2012-11-08
Certicom Corp.
Validating a batch of implicit certificates
US20130097420A1
( en )
2011-10-14
2013-04-18
Certicom Corp.
Verifying Implicit Certificates and Digital Signatures
US20130290713A1
( en )
2012-04-27
2013-10-31
Certicom Corp.
Hashing prefix-free values in a certificate scheme
US20140365779A1
( en )
2011-12-28
2014-12-11
Certicom Corp.
Generating digital signatures
Family Cites Families (17)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US6035402A
( en )
1996-12-20
2000-03-07
Gte Cybertrust Solutions Incorporated
Virtual certificate authority
GB2321741B
( en )
1997-02-03
2000-10-04
Certicom Corp
Data card verification system
US7404077B1
( en )
1999-01-29
2008-07-22
International Business Machines Corporation
Extension of X.509 certificates to simultaneously support multiple cryptographic algorithms
US20020038420A1
( en )
2000-04-13
2002-03-28
Collins Timothy S.
Method for efficient public key based certification for mobile and desktop environments
JP2002207427A
( en )
*
2001-01-10
2002-07-26
Sony Corp
Public key certificate issuing system, public key certificate issuing method, information processing device, information recording medium, and program storage medium
JP2002207426A
( en )
2001-01-10
2002-07-26
Sony Corp
Public key certificate issuing system, public key certificate issuing method, electronic authentication device, and program storage medium
DE10260406B4
( en )
2002-12-16
2007-03-08
Francotyp-Postalia Gmbh
Method and arrangement for different generation of cryptographic backups of messages in a host device
US8225096B2
( en )
*
2006-10-27
2012-07-17
International Business Machines Corporation
System, apparatus, method, and program product for authenticating communication partner using electronic certificate containing personal information
US7522723B1
( en )
*
2008-05-29
2009-04-21
Cheman Shaik
Password self encryption method and system and encryption by keys generated from personal secret information
JP2010081154A
( en )
*
2008-09-25
2010-04-08
Fuji Xerox Co Ltd
Information processing device, program, and information processing system
US20100241852A1
( en )
<td itemprop="priorit