ConceptioArchiveGoogle Patents
Google Patentsopen access

Using a digital certificate with multiple cryptosystems — ISARA Corporation (US9660978B1)

ISARA Corporation · Google Patents
Google Patents · Patents · License: Open Access
Open Source ↗
isaracorporation
patent, google patents, intellectual property, US9660978B1, ISARA Corporation, Alexander Truskovsky, en, 2017

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&#39;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

パナソニックIpマネジメント株式会社

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

Related documents

Record · ID 607036
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.