WO2022116734A1 - Procédé et appareil d'émission de certificat numérique, entité terminale et système - Google Patents

Procédé et appareil d'émission de certificat numérique, entité terminale et système Download PDF

Info

Publication number
WO2022116734A1
WO2022116734A1 PCT/CN2021/125960 CN2021125960W WO2022116734A1 WO 2022116734 A1 WO2022116734 A1 WO 2022116734A1 CN 2021125960 W CN2021125960 W CN 2021125960W WO 2022116734 A1 WO2022116734 A1 WO 2022116734A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
terminal entity
entity
proxy device
terminal
Prior art date
Application number
PCT/CN2021/125960
Other languages
English (en)
Chinese (zh)
Inventor
易孟
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2022116734A1 publication Critical patent/WO2022116734A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3249—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using RSA or related signature schemes, e.g. Rabin scheme
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]

Definitions

  • the embodiments of the present invention relate to the fields of information technology and communication technology, and in particular, to a method, an apparatus, a terminal entity and a system for issuing a digital certificate.
  • Communication between communication devices usually requires mutual trust, trusting communication between communication devices can be considered as cross-trust domain communication, and communication devices can also be referred to as network entities (NEs).
  • NEs network entities
  • the communication between multiple boards in a communication device is considered to belong to the communication in the same trust domain, and the communication between boards does not provide any security function.
  • transport layer security TLS
  • datagram transport layer security DTLS
  • internet protocol security IPSEC
  • MACSEC media access control layer security protocol
  • MACSEC media access control security protocol
  • CA certificate authority
  • the embodiments of the present invention provide a method, device, terminal entity and system for issuing a digital certificate.
  • the CA server authorizes the proxy device to send the intermediate certificate, and the proxy device issues the terminal entity certificate of each terminal to each terminal entity.
  • each terminal entity does not need to request the issuance of the digital certificate from the authorized certification CA server, thus reducing the burden on the CA server.
  • a first aspect provides a method for issuing a digital certificate.
  • the method includes: the terminal entity pre-generates a key pair of its own first terminal entity public key and the first terminal entity private key, and the proxy device pre-generates its own first terminal entity public key. A key pair of the proxy device public key and the first proxy device private key.
  • the proxy device receives the terminal entity certificate authorization request sent by the terminal entity.
  • the terminal entity certificate authorization request includes the public key of the first terminal entity. Since the proxy device itself has an intermediate certificate, it can issue a digital certificate for the terminal entity.
  • the authorization request generates a first terminal entity certificate for the first terminal entity public key, digitally signs the first terminal entity certificate using the first proxy device private key, obtains the digital signature value of the first terminal entity certificate, and generates a terminal entity certificate authorization response , and returns a terminal entity certificate authorization response to the terminal entity, thus realizing the issuance of the first terminal entity certificate by the proxy device.
  • the terminal entity certificate authorization response includes the first terminal entity certificate and the certificate chain of the first terminal entity certificate, the first terminal entity certificate includes the first terminal entity public key and the digital signature value of the first terminal entity certificate, and the first terminal entity certificate includes the first terminal entity public key and the digital signature value of the first terminal entity certificate.
  • the certificate chain of the certificate is used to verify whether the digital signature value of the first terminal entity certificate is correct, the certificate chain of the first terminal entity certificate includes the CA root certificate and the first intermediate certificate, and the first intermediate certificate is issued by the CA server to the proxy device,
  • the first intermediate certificate contains the public key of the first proxy device, so that the proxy device possessing the first intermediate certificate can issue a digital certificate for the terminal entity.
  • the proxy device possessing the intermediate certificate can issue digital certificates to each terminal entity.
  • there is only one CA server in a digital certificate management system and there can be multiple proxy devices, which avoids a large number of end entities from requesting a unique CA server for digital certificate authentication for end entities, thus reducing the risk of It reduces the load on the CA server and saves network bandwidth resources.
  • the proxy device since there may be a plurality of proxy devices, and the proxy devices can be set near the terminal entity, the proxy device can provide the terminal entity with a very secure, fast and convenient digital certificate authentication.
  • the method further includes: the proxy device sends an intermediate certificate authorization request including the public key of the first proxy device to the CA server, and the proxy device receives an intermediate certificate authorization response sent by the CA server, where the intermediate certificate authorization response includes the first intermediate certificate and the certificate chain of the first intermediate certificate, wherein the first intermediate certificate includes the public key of the first proxy device and the digital signature value of the first intermediate certificate, and the certificate chain of the first intermediate certificate includes the CA root certificate , the CA root certificate contains the CA root public key, the digital signature value of the first intermediate certificate is obtained by the CA server using the CA root private key to digitally sign the first intermediate certificate, and the CA root public key and the CA root private key are all A pair of key pairs generated by the CA server; the proxy device uses the certificate chain of the first intermediate certificate to verify that the digital signature value of the first intermediate certificate is correct. Therefore, the CA server can issue an intermediate certificate to the proxy device, so that the proxy device possessing the intermediate certificate can issue the digital certificate of the terminal entity to each terminal entity.
  • the method further includes: when the terminal entity needs to update its own terminal entity certificate, the terminal entity will generate a new key pair: the second terminal entity public key and the second terminal entity private key.
  • the proxy device receives a first certificate update request containing the public key of the second terminal entity sent by the terminal entity, the proxy device generates a second terminal entity certificate for the second terminal entity public key according to the first certificate update request, and uses the first certificate update request to generate a second terminal entity certificate for the public key of the second terminal entity.
  • a proxy device private key digitally signs the certificate of the second terminal entity, obtains the digital signature value of the certificate of the second terminal entity, generates and sends a first certificate update response to the terminal entity, wherein the first certificate update response contains the second terminal entity
  • terminal entity certificate needs to be updated, it is not necessary to go to the CA server to request to update the terminal entity certificate, but only need to request the proxy device located near the terminal entity to update the terminal entity certificate. In this way, a large number of terminal entities are prevented from going to the unique CA server to request the renewal of the digital certificate authentication, which reduces the load of the CA server and saves network bandwidth resources.
  • the method further includes: when the proxy device needs to update the intermediate certificate, the proxy device will generate a new key pair: the second proxy device public key and the second proxy device private key.
  • the proxy device sends a second certificate update request containing the public key of the second proxy device to the CA server, and the proxy device receives a second certificate update response sent by the CA server, wherein the second certificate update response contains the second intermediate certificate and the second intermediate certificate
  • the certificate chain of the certificate, the second intermediate certificate contains the public key of the second proxy device and the digital signature value of the second intermediate certificate, and the digital signature value of the second intermediate certificate is used by the CA server to use the CA root private key for the second intermediate certificate.
  • the certificate is obtained by digitally signing the certificate; when the proxy device uses the certificate chain of the second intermediate certificate to verify that the digital signature value of the second intermediate certificate is correct, the proxy device replaces the first intermediate certificate with the second intermediate certificate Intermediate certificate.
  • the proxy device requests the CA server to update the intermediate certificate in time, thus realizing the timely update of the intermediate certificate.
  • the method further includes: after the intermediate certificate is updated, the terminal entity needs to update and re-issue the terminal entity certificate to the proxy device, and the proxy device receives the first terminal entity public key sent by the terminal entity and contains the first terminal entity public key.
  • the proxy device generates a third terminal entity certificate for the first terminal entity public key according to the third certificate update request, and uses the second proxy device private key to digitally sign the third terminal entity certificate to obtain the third terminal entity certificate
  • the digital signature value of the entity certificate generate and send a third certificate update response to the terminal entity, wherein the third certificate update response contains the third terminal entity certificate and the certificate chain of the third terminal entity certificate, and the third terminal entity certificate contains the first The public key of the terminal entity and the digital signature value of the certificate of the third terminal entity.
  • the certificate chain of the certificate of the third terminal entity is used to verify whether the digital signature value of the certificate of the third terminal entity is correct.
  • the certificate chain of the certificate of the third terminal entity contains the CA root certificate. and the second intermediate certificate. After the intermediate certificate is updated, the proxy device re-issues a new terminal entity certificate for the terminal entity, and at this time, the validity of the terminal entity certificate is extended.
  • the method further includes: using the certificate chain of the second intermediate certificate to verify that the digital signature value of the second intermediate certificate is correct, specifically: the proxy device uses the CA root public key to verify the CA Whether the digital signature value of the root certificate is correct, when verifying that the digital signature value of the CA root certificate is incorrect, determine that the second intermediate certificate is incorrect; when verifying that the digital signature value of the CA root certificate is correct, use the CA root certificate key to verify whether the digital signature value of the second intermediate certificate is correct, when verifying that the digital signature value of the second intermediate certificate is incorrect, the second intermediate certificate is determined to be incorrect; when verifying that the digital signature value of the second intermediate certificate is incorrect When correct, it is determined that the second intermediate certificate is correct.
  • the present invention provides a method for issuing a digital certificate, including: the terminal entity pre-generates a key pair of its own first terminal entity public key and the first terminal entity private key, and the proxy device pre-generates its own key pair. A key pair of the first proxy device public key and the first proxy device private key.
  • the terminal entity sends the entity certificate authorization request including the public key terminal of the first terminal entity to the proxy device, and the terminal entity receives the terminal entity certificate authorization response sent by the proxy device, wherein the terminal entity certificate authorization response includes the first terminal entity certificate and the first terminal entity certificate.
  • the certificate chain of the entity certificate, the first terminal entity certificate contains the first terminal entity public key and the digital signature value of the first terminal entity certificate, and the certificate chain of the first terminal entity certificate is used to verify the digital signature of the first terminal entity certificate Whether the value is correct; use the certificate chain of the first terminal entity certificate to verify whether the digital signature value of the first terminal entity certificate is correct.
  • the proxy device possessing the intermediate certificate can issue digital certificates to each terminal entity.
  • there is only one CA server in a digital certificate management system and there can be multiple proxy devices, which avoids a large number of end entities from requesting a unique CA server for digital certificate authentication for end entities, thus reducing the risk of It reduces the load on the CA server and saves network bandwidth resources.
  • the proxy device since there may be a plurality of proxy devices, and the proxy devices can be set near the terminal entity, the proxy device can provide the terminal entity with a very secure, fast and convenient digital certificate authentication.
  • the method further includes: regenerating a key pair at the terminal entity: the public key of the second terminal entity and the private key of the second terminal entity, and the terminal entity sends the proxy device a key pair containing the public key of the second terminal entity.
  • the terminal entity receives the first certificate update response sent by the device, wherein the first certificate update response contains the second terminal entity certificate and the certificate chain of the second terminal entity certificate, and the second terminal entity certificate contains all the certificates.
  • the certificate chain of the second terminal entity certificate is used to verify whether the digital signature value of the second terminal entity certificate is correct; using the certificate chain of the second terminal entity certificate
  • the first terminal entity certificate is replaced with the second terminal entity certificate.
  • the method further includes: when the proxy device needs to update the intermediate certificate, the proxy device will generate a new key pair: the second proxy device public key and the second proxy device private key.
  • the terminal entity sends a third certificate update request containing the public key of the first terminal entity to the proxy device, and the terminal entity receives a third certificate update response sent by the proxy device, wherein the third certificate update response contains the third terminal entity certificate and the third certificate update response.
  • the certificate chain of the terminal entity certificate, the third terminal entity certificate contains the first terminal entity public key and the digital signature value of the third terminal entity certificate, and the certificate chain of the third terminal entity certificate is used to verify the digital signature value of the third terminal entity certificate Is it correct?
  • the proxy device When verifying that the digital signature value of the third terminal entity certificate is correct by using the certificate chain of the third terminal entity certificate, replace the first terminal entity certificate with the third terminal entity certificate. After the intermediate certificate is updated, the proxy device re-issues a new terminal entity certificate for the terminal entity, and at this time, the validity of the terminal entity certificate is extended.
  • the method further includes: the certificate chain of the first terminal entity certificate includes an authorized certification CA root certificate and a first intermediate certificate, and the first terminal entity certificate is verified by using the certificate chain of the first terminal entity certificate Whether the digital signature value of the CA root certificate is correct, specifically: using the CA root public key to verify whether the digital signature value of the CA root certificate is correct, and when verifying that the digital signature value of the CA root certificate is incorrect, determine that the first terminal entity certificate is incorrect.
  • verifying that the digital signature value of the CA root certificate is correct use the CA root public key to verify whether the digital signature value of the first intermediate certificate is correct, and when verifying that the digital signature value of the first intermediate certificate is incorrect, then determine that the first intermediate certificate is correct.
  • the terminal entity certificate is incorrect; when verifying that the digital signature value of the first intermediate certificate is correct, use the first proxy device public key included in the first intermediate certificate to verify whether the digital signature value of the first terminal entity certificate is correct.
  • the digital signature value of the first terminal entity certificate is incorrect, it is determined that the first terminal entity certificate is incorrect; when it is verified that the digital signature value of the first terminal entity certificate is correct, it is determined that the first terminal entity certificate is correct of.
  • the present application provides an apparatus for issuing a digital certificate, the apparatus including one or more units for implementing the method for issuing a digital certificate described in the first aspect.
  • the present application provides a terminal entity, where the terminal entity includes one or more modules for implementing the method for issuing a digital certificate described in the second aspect.
  • the present application provides a computer-readable storage medium, in which a computer program or instruction is stored, and when the computer program or instruction is executed by a proxy device, the proxy device is made to execute the above-mentioned first aspect or the first aspect.
  • a method in any possible implementation of an aspect.
  • the present application provides a computer-readable storage medium
  • the computer program product includes a computer program or instruction, which, when the computer program or instruction is executed by a terminal entity, causes the terminal entity to perform the above-mentioned second aspect or the second aspect method in any possible implementation of .
  • FIG. 1 is a schematic diagram of a chain relationship of a certificate chain provided by an embodiment of the present invention
  • FIG. 2 is a schematic structural diagram of a digital certificate management system provided by an embodiment of the present invention.
  • FIG. 3 is a flowchart of a digital certificate issuance provided by an embodiment of the present invention.
  • FIG. 5 is a flowchart of a digital certificate update provided by an embodiment of the present invention.
  • FIG. 6 is a schematic structural diagram of an apparatus for issuing a digital certificate according to an embodiment of the present invention.
  • FIG. 7 is a schematic structural diagram of a terminal entity according to an embodiment of the present invention.
  • FIG. 8 is a schematic structural diagram of an apparatus for issuing a digital certificate according to an embodiment of the present invention.
  • FIG. 9 is a schematic structural diagram of a terminal entity according to an embodiment of the present invention.
  • Symmetric encryption algorithm The encryption and decryption parties use the same rules to encrypt and decrypt information.
  • Asymmetric encryption algorithm also known as public key cryptography or two-key cryptography.
  • Asymmetric encryption algorithms require two keys: a public key (public key, referred to as public key) and a private key (private key, referred to as private key).
  • the public key and the private key are a pair. If the data is encrypted with the public key, it can only be decrypted with the corresponding private key. If the data is encrypted with the private key, only the corresponding public key can be decrypted. Because encryption and decryption use two different keys.
  • the current typical asymmetric encryption algorithm is the RSA algorithm, designed by three mathematicians Rivest, Shamir and Adleman.
  • RSA cryptosystem is a public key cryptosystem, the public key is public, the private key is kept secret, and its encryption and decryption algorithms are public. Content encrypted by the public key can and only be decrypted by the private key, or content encrypted by the private key can and only be decrypted by the public key. That is to say, the pair of public and private keys of RSA can be used to encrypt and decrypt, and the encrypted content of one party can be decrypted by and only by the other party.
  • Digital signature also known as public key digital signature
  • digital signature is a piece of content appended to the data unit, or a cryptographic transformation of the data unit, which can prove that the data unit has not been modified. This data or transformation allows the recipient of the data unit to confirm the origin of the data unit and the integrity of the data unit and to protect the data from forgery by a person (eg, the recipient). It is a method of signing messages in electronic form, and a signed message can be transmitted over a communication network. Digital signatures can be obtained based on both public key cryptosystems and private key cryptosystems.
  • PKI Public key infrastructure
  • CA public key infrastructure
  • RA Registration Authority
  • the RA agency ensures the public key and personal identity link, which is non-repudiation.
  • PKI usually consists of the following parts: CA organization, RA organization, certificate store, key backup and recovery system, certificate revocation processing system, application system interface and certificate.
  • CA agency is the core executive agency of PKI, also known as certification authority or CA server.
  • the CA agency is the agency responsible for issuing certificates, certifying certificates and managing the issued certificates. Specifically, the CA agency can formulate policies and specific steps to verify, identify the user's identity, and sign the user's certificate to ensure the certificate holder's identity. Ownership of identity and public key, CA is an authoritative, trustworthy and impartial third-party organization.
  • the CA organization also has a hierarchical structure. In a large-scale PKI facility, due to the large number of users, using a CA organization for certificate verification and issuance services may be overloaded, so it is necessary to carry out the hierarchical deployment of the CA organization. In the hierarchical deployment of CA agencies, a top-down trust certificate chain needs to be established between CA agencies. The lower-level CA agency trusts the upper-level CA agency. Hierarchical relationships can be seen in the certificate chain.
  • RA organization It is an integral part of the CA organization, and is the application registration, approval, proofreading and management organization of the certificate.
  • the RA organization is also called the hierarchical structure.
  • RA is the general registration center, which is responsible for the summary of certificate application registration.
  • the RA agency is the window of the CA agency to the user. It is responsible for receiving the user's certificate application and verifying the user's identity.
  • the RA organization in PKI usually does not exist independently, but is merged with the CA organization.
  • Digital certificate a certificate for short, a certificate is a file issued by an issuing authority that contains the public key owner information and public key, and is digitally signed by the issuing authority, which is the technical basis for digital signatures.
  • the certificate generally contains the certificate version, certificate serial number, certificate signature algorithm, issuer information, certificate validity period, public key and user information.
  • the certificate serial number is issued by the issuing authority and is guaranteed to be unique within the scope of use of the certificate; the certificate The validity period includes the valid time of the certificate and the expiration time of the certificate; the issuer information is determined by the issuing authority, and the user information is determined by the certificate applicant.
  • a certificate can also contain key usage, certificate type, extended key usage, and certificate revocation list distribution point, where key usage indicates the functions and services that the certificate's public key can support, such as certificate signature, Key encryption (key encipherment), data encryption (data encipherment), key agreement (key agreement), certificate revocation list (Certification Revocation List, CRL) signature.
  • certificate signature and certificate revocation list signature can only be used by CA certificates. Therefore, although the key usage extension field is optional, it is an indispensable key extension for the root CA. item, and must have the two key usages of certificate signature and Certification Revocation List (CRL) signature.
  • the certificate types are root certificate (root certificate), intermediate certificate (intermediate certificate), and end-entity certificate (end-entity certificate).
  • the root certificate is a certificate issued by the CA agency to itself, and the digital signature of the root certificate is the root private certificate. Therefore, the root public key is required to verify the root certificate signature.
  • the digital signature of the root certificate is called a self-signature.
  • the intermediate certificate is issued by the CA agency.
  • the intermediate certificate contains the name of the root certificate.
  • the signature of the intermediate certificate is digitally signed with the root private key. Therefore, the validity of the intermediate certificate needs to be verified with the root public key.
  • the end entity certificate is signed by the owner of the intermediate certificate.
  • the end entity certificate contains the name of the intermediate certificate.
  • the digital signature of the end entity certificate is issued by the intermediate private key. Therefore, the validity of the end entity certificate needs to be verified with the intermediate public key. .
  • the root certificate or intermediate certificate has the ability to issue a certificate for its lower-level certificate.
  • the intermediate certificate has only one level.
  • the intermediate certificate can be called the second-level certificate, but the intermediate certificate can also have multiple levels.
  • the terminal entity certificate does not have the authorization ability to issue certificates, but only has the function of proving the identity of the terminal entity. It should be noted that the terminal entity here includes mobile phones, computers, single boards, servers, and network equipment. Various terminal entity certificates are used. A device to identify yourself.
  • a certificate chain is an ordered list of certificates and a trust relationship between certificates.
  • a certificate chain usually includes a three-level structure, a root certificate, an intermediate certificate, and an end-entity certificate, as shown in Figure 1.
  • the end entity certificate is at the bottom.
  • the end entity certificate contains the end entity information, the end entity public key and the digital signature value.
  • the upper level of the end-entity certificate is the intermediate certificate, that is, the end-entity certificate is issued by the authority that owns the intermediate certificate.
  • the intermediate certificate is authorized and issued by the CA authority.
  • Figure 1 shows only one intermediate certificate, but the certificate chain can have multiple intermediate certificates.
  • the top-level intermediate certificate is issued by the root certificate
  • the bottom-level intermediate certificate is used to issue the end entity certificate
  • the root certificate is issued by the CA issued by the institution.
  • the legitimacy of each certificate issuer of the entire certificate chain needs to be verified. Find the issuer's certificate layer by layer according to the certificate chain until the self-signed root certificate is found, and then verify the correctness of the digital signature value of the next level through the corresponding public key. If verified to be correct, the end-entity certificate is correct.
  • Certificate Management Protocol is an Internet protocol used for the behavior between the client (certificate owner and user) and the CA (certificate issuer) during certificate application and renewal operations in the PKI system .
  • CMP developed to the second version, referred to as CMPv2.
  • a network system architecture provided by an embodiment of the present invention includes: a CA server and a plurality of NEs, wherein the NEs may further include a service board (service board) and a control board (main control board).
  • a certificate management agent can be installed on the service board and the control board.
  • the security of communication between different network elements is increased by means of an encryption algorithm.
  • each service board in the NE can independently request a certificate issuance or certificate update service from the CA server.
  • the specific process of the certificate service may include the following: All the boards including the service board and the control board will be pre-set with an initial terminal entity certificate and an initial certificate chain indicating the identity of the board when they leave the factory.
  • the initial intermediate certificate and initial root certificate of the terminal certificate, the initial terminal entity certificate is usually issued by the network equipment manufacturer, not by the CA server.
  • the service veneer and the control veneer use the preset initial terminal entity certificate as the identity credential to establish the secure communication channel. DTLS/MACSEC.
  • control board and the service board can respectively request the CA server to issue a new certificate (ie, the terminal entity certificate certified by the CA server), and the CA server returns the certified certificate to the control board and the service board respectively.
  • the control board and the service board use the authenticated terminal entity certificate to replace the preset initial terminal entity certificate, so that the authenticated terminal entity certificate can be used as the authentication credential for communication between the control board and the service board.
  • an embodiment of the present invention discloses a new method for obtaining a certificate.
  • different stages of certificate obtaining are divided into four different embodiments for description below.
  • the device manufacturer can pre-configure the device's own initial end-entity certificate and initial certificate chain for each end-entity (such as a service board) and an agent device (such as a control board).
  • the initial certificate chain includes the initial intermediate certificate and the initial root certificate for issuing the initial terminal certificate.
  • the administrator can load the CA root certificate of the CA server itself for the proxy device in the network device.
  • the CA root certificate contains the CA root public key.
  • the CA root certificate is used by the CA server to contain the first key pair.
  • the CA root private key is a self-signed digital certificate, the first key pair is generated by the CA server, and the first key pair includes the CA root public key and the CA root private key.
  • the CA root public key can be used to verify whether the digital signature value of the message sent by the CA server to the proxy device is correct.
  • the digital signature value is signed with the CA root private key.
  • the CA certificate can also be loaded for the proxy device Chain, for the convenience of description, the following content is described by taking only the CA root certificate loaded as an example. If the CA certificate chain is loaded, it is necessary to use the digital certificates at all levels contained in the certificate chain to include various public keys to verify whether the digital signature values of the digital certificates at all levels are correct. The process will be described in detail in process step 308 below. Similarly, the CA server will import the preset initial end entity certificate and initial certificate chain of the proxy device.
  • the preset initial end entity certificate of the proxy device contains the public key of the initial proxy device
  • the preset end entity certificate of the proxy device is A digital certificate issued by the network device or an authority trusted by the network device using the private key of the initial proxy device contained in the second key pair, where the second key pair contains the public key of the initial proxy device and the private key of the initial proxy device.
  • the pre-set initial proxy device public key of the initial terminal entity certificate of the proxy device is used to verify whether the digital signature value of the message sent by the proxy device to the CA server is correct, and the digital signature is signed with the initial proxy device private key.
  • the method for implementing digital certificate issuance of the proxy device includes:
  • Step 301 The proxy device generates a third key pair of the proxy device itself, where the third key pair includes the first proxy device public key and the first proxy device private key.
  • the third key pair includes the first proxy device public key and the first proxy device private key.
  • the proxy device constructs an intermediate certificate authorization request, which includes the applicant information (that is, the proxy device information, such as the proxy device name, etc.) and the public key of the first proxy device, and uses the initial proxy device private key to perform the intermediate certificate authorization request. Digitally sign, and then send the digitally signed intermediate certificate authorization request to the CA server.
  • the intermediate certificate authorization request may be carried by a CMP message, a CMPv2 message, or a message of other message types, for example, the CMPv2 message is specifically an initialization request (initialization request, IR).
  • Step 302 The CA server receives the intermediate certificate authorization request, and the CA server verifies whether the digital signature value of the intermediate certificate authorization request is correct using the initial proxy device public key contained in the initial terminal entity certificate of the preloaded proxy device. Generate a first intermediate certificate for the proxy device according to the applicant information contained in the intermediate certificate authorization request and the public key of the first proxy device, and use the CA root private key to digitally sign the first intermediate certificate.
  • the first intermediate certificate contains the first intermediate certificate. Agent device public key.
  • the CA server generates an intermediate certificate authorization response including the first intermediate certificate, and uses the CA root private key to digitally sign the intermediate certificate authorization response, and sends the digitally signed intermediate certificate authorization response to the proxy device.
  • the intermediate certificate authorization response also includes The certificate chain of the first intermediate certificate.
  • the intermediate certificate authorization response may be carried by an IP message or a message in a format such as CMPv2, and the certificate chain of the first intermediate certificate includes the CA root certificate.
  • intermediate certificate a there are multiple intermediate certificates, for example, there are three intermediate certificates, namely: intermediate certificate a, intermediate certificate b, and intermediate certificate c
  • the relationship between these three certificates is: the first intermediate certificate a
  • the first-level certificate is the CA root certificate, that is to say, the CA root certificate is used to digitally sign the intermediate certificate a
  • the upper-level certificate of the intermediate certificate b is the intermediate certificate a, that is to say, the public key contained in the intermediate certificate a is used as the intermediate certificate b.
  • Digital signature the upper-level certificate of intermediate certificate c is intermediate certificate b, that is to say, the public key contained in intermediate certificate b is used to digitally sign intermediate certificate c.
  • intermediate certificate c is the above-mentioned first intermediate certificate.
  • the certificate chain of the first intermediate certificate includes the CA root certificate, the intermediate certificate a, and the intermediate certificate b.
  • the embodiment of the present invention uses only one intermediate certificate as an example to describe the solution, and there are multiple intermediate certificates.
  • the scheme process of the certificate is similar to that of the existence of an intermediate certificate, so it is not repeated here.
  • Step 303 The proxy device receives the intermediate certificate authorization response, and uses the preloaded CA root public key of the CA root certificate to respectively verify the digital signature value of the intermediate certificate authorization response, and uses the certificate chain of the first intermediate certificate to verify the first intermediate certificate.
  • the proxy device sends a certificate confirmation message to the CA server to confirm receipt of the first intermediate certificate.
  • the certificate confirmation message can be a CertConf message.
  • the process of using the certificate chain of the first intermediate certificate to verify whether the digital signature value of the first intermediate certificate is correct is as follows: the proxy device obtains all the certificates from the certificate chain of the first intermediate certificate, in this embodiment of the present invention, it is only the CA root certificate, Then use the pre-loaded CA root public key to verify whether the digital signature value of the CA root certificate is correct. If the digital signature value of the CA root certificate is incorrect, it is determined that the first intermediate certificate is incorrect. If it is correct, the CA root certificate is used. The public key verifies whether the digital signature value of the first intermediate certificate is correct. If the digital signature value of the first intermediate certificate is verified to be incorrect, it is determined that the first intermediate certificate is incorrect. If the digital signature value of the first intermediate certificate is verified to be incorrect is correct, it is determined that the first intermediate certificate is correct.
  • the process of verifying whether the digital signature value of the first intermediate certificate is correct by using the certificate chain of the first intermediate certificate is as follows: The proxy device obtains all certificates from the certificate chain of the first intermediate certificate, and then uses the pre-loaded CA root public key to verify whether the digital signature value of the CA root certificate is correct, if the digital signature value of the CA root certificate is incorrect , then it is determined that the first intermediate certificate is incorrect. If the digital signature value of the CA root certificate is verified to be correct, then the CA root public key is used to verify whether the digital signature value of the intermediate certificate a is correct.
  • the digital signature of the intermediate certificate a is verified If the value is incorrect, it is determined that the first intermediate certificate is incorrect. If it is verified that the digital signature value of intermediate certificate a is correct, the public key contained in intermediate certificate a is used to verify whether the digital signature value of intermediate certificate b is correct. If the digital signature value of the intermediate certificate b is incorrect, it means that the first intermediate certificate is incorrect. If the digital signature value of the intermediate certificate b is verified to be correct, the public key contained in the intermediate certificate b is used to verify the first intermediate certificate.
  • Step 304 After receiving the certificate confirmation message, the CA server sends a PKI confirmation (PKIConf) message to the proxy device to confirm receipt of the certificate confirmation message.
  • PKIConf PKI confirmation
  • Step 305 After the proxy device receives the first intermediate certificate sent by the CA server, the proxy device sends a certificate application notification to each terminal entity.
  • each terminal entity and proxy device are pre-set with the initial terminal entity certificate and initial terminal root certificate and proxy device issued by the manufacturer. After the terminal entity goes online, it automatically establishes a secure communication channel (TLS/DTLS/MASEC, etc.) with the proxy device. Pre-set end-entity certificates are used as authentication credentials.
  • the proxy device in addition to an intermediate certificate that can issue a digital certificate for the terminal entity, the proxy device also has a terminal entity certificate that certifies the identity of the proxy device.
  • Step 306 The terminal entity generates a fourth key pair of the terminal entity itself, where the fourth key pair includes the public key of the first terminal entity and the private key of the first terminal entity.
  • the terminal entity constructs the terminal entity certificate authorization request, and the terminal entity certificate authorization request includes the applicant information (that is, the terminal entity information, such as the name of the terminal entity) and the public key of the first terminal entity, And use the initial terminal entity private key of the initial terminal entity certificate to digitally sign the terminal entity certificate authorization request, and then send the digitally signed terminal entity certificate authorization request to the proxy device through the secure channel between the boards.
  • the end-entity certificate authorization request may be carried by a CMP message, a CMPv2 message, or a message of other message types.
  • Step 307 the proxy device receives the end entity certificate authorization request from the secure channel, and uses the initial end entity public key obtained from the preloaded initial end entity certificate of the first end entity to verify the end entity certificate authorization request Is the digital signature value correct. If the verification fails, the terminal entity certificate authorization request is considered to be an untrusted message, and the proxy device does not process the terminal entity certificate authorization request, or returns a warning message to the terminal entity. If the verification is passed, the proxy device generates the first terminal entity certificate for the terminal entity according to the first intermediate certificate, the applicant information contained in the terminal entity certificate authorization request, and the public key of the first terminal entity, and uses the first proxy device private key to generate the first terminal entity certificate for the terminal entity.
  • a terminal entity certificate is digitally signed, and the first terminal entity certificate contains the first terminal entity public key.
  • the proxy device generates a terminal entity certificate authorization response that includes the digitally signed first terminal entity certificate and the certificate chain of the first terminal entity certificate, and the proxy device can use the initial proxy device private key of the proxy device's initial terminal entity certificate as the terminal entity certificate.
  • the authorization response is digitally signed, and the terminal entity certificate authorization response is sent to the terminal entity through the secure channel between the boards.
  • the certificate chain of the first terminal entity certificate includes the CA root certificate and the first intermediate certificate.
  • Step 308 The terminal entity receives the terminal entity certificate authorization response of the proxy device from the secure channel, and uses the initial terminal entity public key of the initial terminal certificate of the proxy device to verify whether the digital signature value of the terminal entity certificate authorization response is correct, if the verification result is If it is incorrect, it is considered that the certificate authorization response of the terminal entity is an untrusted message, and the proxy device does not process the certificate authorization response of the terminal entity, or returns a warning message to the terminal entity. If the verification result is correct, the certificate chain of the first terminal entity certificate is used to verify whether the digital signature value of the first terminal entity certificate is correct, so as to ensure that the first terminal entity certificate is correct.
  • the process of verifying whether the digital signature value of the first terminal entity certificate is correct by using the certificate chain of the first terminal entity certificate includes: the terminal entity first obtains all digital certificates included in the certificate chain from the certificate chain of the first terminal entity certificate, namely: the first intermediate
  • the certificate and the CA root certificate are used to verify whether the digital signature value contained in the CA root certificate is correct by using the CA root public key.
  • the verification result is incorrect, it means that the first terminal entity certificate is incorrect.
  • use the CA root certificate containing the CA root public key to verify whether the digital signature value contained in the first intermediate certificate is correct, and when the verification result is incorrect, it means that the first terminal entity certificate is incorrect .
  • the verification result uses the first intermediate certificate to include the first proxy device public key to verify whether the digital signature value contained in the first terminal entity certificate is correct, and when the verification result is incorrect, it means that the first terminal entity certificate is incorrect.
  • the verification result it means that the certificate of the first terminal entity is correct.
  • the process of verifying the CA root certificate, the intermediate certificate a and the intermediate certificate b is the same as the content introduced in step 303
  • the present invention if the certificate chain of the second intermediate certificate or the certificate chain of the third terminal entity certificate includes the CA root certificate, the intermediate certificate a and the intermediate certificate b, the process of verifying the CA root certificate, the intermediate certificate a and the intermediate certificate b is the same as step 303. content presented.
  • the terminal entity and the proxy device use their respective initial terminal entity private keys to digitally sign the message respectively, and the terminal entity and the proxy device use the corresponding initial terminal entity public key to verify the message respectively. Is the digital signature value correct.
  • the proxy device can also generate a fifth key pair of the proxy device itself, where the fifth key For including the public key of the terminal entity of the proxy device and the private key of the terminal entity of the proxy device, the proxy device can use the first proxy device private key of the first intermediate certificate to issue a terminal entity certificate for the proxy device, and the terminal entity of the proxy device can use the first proxy device private key of the first intermediate certificate to issue the proxy device.
  • the certificate contains the public key of the end entity of the proxy device.
  • the terminal entity can also use the private key of the first terminal entity to digitally sign the message, and the proxy device can also use the public key of the first terminal entity to check whether the digital signature value of the message is correct
  • the proxy device can also use the private key of the terminal entity of the proxy device to digitally sign the message
  • the terminal entity can also use the public key of the terminal entity of the proxy device to check whether the digital signature value of the message is correct.
  • the terminal entity may send a certificate obtaining notification to the proxy device.
  • Step 309 The proxy device detects that all terminal entities have successfully applied for the certificate of the first terminal entity, and sends a certificate switching notification to each terminal entity through a secure channel.
  • the proxy device may store a terminal entity list locally, where the terminal entity list records whether the terminal entity has received the first terminal entity certificate.
  • Step 310 After receiving the certificate switching notification, each terminal entity replaces the preset initial terminal entity certificate with the first terminal entity certificate issued by the proxy device.
  • the CA server in the digital certificate management system, can issue an intermediate certificate to the proxy device, so the proxy device having the intermediate certificate can issue digital certificates to each terminal entity.
  • the CA server there is only one CA server in a digital certificate management system, and there can be multiple proxy devices, which avoids a large number of end entities from requesting a unique CA server for digital certificate authentication for end entities, thus reducing the risk of It reduces the load on the CA server and saves network bandwidth resources.
  • the proxy device can be set near the terminal entity, for example, the service veneer (as the terminal entity) and the control veneer (as the proxy device) located in the same network device, the service veneer The communication with the control board is faster and more secure, so the proxy device can provide the end entity with a very secure, fast and convenient digital certificate authentication.
  • the terminal entity needs to request the proxy device to update the first terminal entity certificate in time. After the first end entity certificate is updated successfully.
  • the flow of the certificate update method is as follows:
  • Step 401 When the terminal entity determines that it needs to re-apply for the terminal entity certificate to the proxy device, it regenerates a sixth key pair of the terminal entity itself, and the sixth key pair includes the second terminal entity public key and the second terminal entity private key.
  • the terminal entity constructs a first certificate update request, the first certificate update request includes the second terminal entity public key and the applicant information (that is, the information of the terminal entity), and uses the second terminal entity private key to digitize the first certificate update request. Sign, and send the first certificate update request to the proxy device through the inter-board security channel.
  • the terminal entity can periodically detect whether the expiration date of the first terminal entity certificate is within the update range, when it is detected that the expiration date of the first terminal entity certificate of the terminal entity is already within the update range, or the terminal entity periodically detects When the corresponding private key is damaged or leaked, the terminal entity determines that it needs to apply for the terminal entity certificate from the CA server again.
  • Step 402 The proxy device receives the first certificate update request, first uses the second terminal entity public key in the first certificate update request to verify whether the digital signature value of the first certificate update request is correct, and when the verification result is correct, according to the first certificate update request.
  • the applicant information and the public key of the second terminal entity contained in a certificate update request generate a second terminal entity certificate, and use the private key of the first proxy device related to the first intermediate certificate to digitally sign the second terminal entity certificate.
  • the proxy device generates a first certificate update response, where the first certificate update response includes the digitally signed second terminal entity certificate and the certificate chain of the second terminal entity certificate, and the proxy device sends the first certificate update response to the terminal through the secure channel entity, the certificate chain of the second terminal entity certificate at this time includes the CA root certificate and the first intermediate certificate.
  • Step 403 The terminal entity receives the first certificate update response of the proxy device from the secure channel, and uses the public key of the first proxy device related to the first intermediate certificate to verify whether the digital signature value of the first certificate update response is correct. If it is correct, confirm that the first certificate update response is untrusted; if the verification result is correct, confirm that the first certificate update response is trusted, and use the certificate chain of the second terminal entity certificate to verify the digital signature of the second terminal entity certificate Check whether the value is correct to ensure that the certificate of the second terminal entity is trusted. After the verification is passed, the certificate of the second terminal entity is used to replace the certificate of the first terminal entity.
  • the process of verifying whether the digital signature value of the certificate of the second terminal entity is correct by using the certificate chain of the certificate of the second terminal entity includes: the terminal entity first obtains all the digital certificates included in the certificate chain from the certificate chain of the certificate of the second terminal entity, namely: the first intermediate certificate and the CA root certificate, and use the CA root public key to verify whether the digital signature value contained in the CA root certificate is correct.
  • the verification result is incorrect, it means that the second terminal entity certificate is incorrect.
  • the verification result When the verification result is correct, continue to use the first intermediate certificate to include the public key of the first proxy device to verify whether the digital signature value contained in the certificate of the second terminal entity is correct.
  • the verification result When the verification result is incorrect, it means that the second terminal entity The certificate is incorrect.
  • the verification result is correct, it means that the certificate of the second terminal entity is correct.
  • the proxy device possessing the intermediate certificate can issue digital certificates to each terminal entity, when the terminal entity certificate needs to be updated, it is not necessary to go to the CA server to request to update the terminal entity certificate , but only need to request the renewal of the certificate of the terminal entity from the proxy device located near the terminal entity. In this way, a large number of terminal entities are prevented from going to the unique CA server to request the renewal of the digital certificate authentication, which reduces the load of the CA server and saves network bandwidth resources.
  • the proxy device can provide very secure, fast and convenient renewal management of digital certificates to end entities.
  • the network device When the first intermediate certificate of the network device is about to expire or the corresponding private key is damaged or leaked, the network device needs to request the CA server to update the first intermediate certificate in time. After the first intermediate certificate is successfully updated, the proxy device needs to notify each terminal entity to update the first terminal entity certificate, and use the new intermediate certificate (ie the second intermediate certificate) to re-issue a new terminal entity certificate (ie the third terminal entity certificate) to each terminal entity. entity certificate).
  • the flow of the certificate update method includes the following:
  • Step 501 When the proxy device determines that it needs to re-apply for an intermediate certificate from the CA server, it regenerates a seventh key pair of the proxy device itself, where the seventh key pair includes the second proxy device public key and the second proxy device private key.
  • the proxy device constructs a second certificate update request, and the second certificate update request includes the applicant information (specifically, proxy device information, such as proxy device name) and the second proxy device public key, and uses the second proxy device private key to pair the first proxy device.
  • the second certificate update request is digitally signed, and then the digitally signed second certificate update request is sent to the CA server through the https channel.
  • the second certificate update request may be carried by a key update request (Key Update Request, KUR).
  • the proxy device can periodically detect whether the expiration date of the first intermediate certificate is within the update range. When it detects that the expiration date of the first intermediate certificate of the terminal entity is already within the update range, or the proxy device periodically detects the private key corresponding to the first intermediate certificate When damage or leakage occurs, the proxy device determines that it needs to apply for an intermediate certificate from the CA server again.
  • Step 502 The CA server receives the second certificate update request, and uses the public key of the second proxy device included in the second certificate update request to verify whether the digital signature value of the second certificate update request is correct.
  • the public key of the second proxy device and the applicant information in the certificate update request generate a new intermediate certificate for the proxy device (referred to as the second intermediate certificate later), and use the CA root private key to digitally sign the second intermediate certificate.
  • the CA server generates a second certificate update response including the second intermediate certificate and the certificate chain of the second intermediate certificate, and uses the CA root private key to digitally sign the second certificate update response.
  • the CA server uses the https channel to digitally sign the second certificate update response.
  • the certificate update response is sent to the proxy device.
  • the second certificate update response may be carried by a key update response (Key Update Response, KUP).
  • KUP Key Update Response
  • Step 503 The proxy device receives the second certificate update response, and uses the CA root public key of the CA root certificate to verify whether the digital signature value of the second certificate update response is correct. When the verification result is correct, it means that the received second certificate update If the response is correct, the proxy device sends a certificate confirmation message to the CA server to confirm receipt of the second intermediate certificate.
  • Step 504 The CA server sends a PKI confirmation message to the main control unit to confirm receipt of the certificate confirmation message.
  • Step 505 After receiving the PKI confirmation message, the proxy device sends an intermediate certificate update notification to each terminal entity.
  • Step 506 After receiving the intermediate certificate update notification, the terminal entity generates a third certificate update request, the third certificate update request includes the public key of the first terminal entity and the applicant information (information of the terminal entity), using the first terminal entity The private key digitally signs the third certificate update request, and sends the third certificate update request to the proxy device through the inter-board security channel.
  • Step 507 After receiving the third certificate update request, the proxy device first uses the public key of the first terminal entity in the third certificate update request to verify whether the digital signature value of the third certificate update request is correct.
  • the applicant information and the public key of the first terminal entity included in the certificate update request generate a third terminal entity certificate, and use the second proxy device private key related to the second intermediate certificate to digitally sign the third terminal entity certificate.
  • the proxy device generates a third certificate update response, where the third certificate update response includes the digitally signed third terminal entity certificate and the certificate chain of the third terminal entity certificate, and the proxy device sends the third certificate update response to the terminal through the secure channel entity, the certificate chain of the third terminal entity certificate at this time includes the CA root certificate and the second intermediate certificate.
  • Step 508 The terminal entity receives the third certificate update response from the proxy device from the secure channel, and verifies whether the digital signature value of the third terminal entity certificate and the certificate chain of the third terminal entity certificate is correct to ensure its legality. Replace the first end-entity certificate with the third end-entity certificate.
  • the terminal entity first obtains all the digital certificates contained in the certificate chain from the certificate chain of the certificate of the third terminal entity, namely: the second intermediate certificate and the CA root certificate, and uses the CA root certificate containing the CA root public key to verify the digital signature value contained in the CA root certificate Whether it is correct or not, when the verification result is incorrect, it means that the certificate of the third terminal entity is incorrect.
  • the verification result use the CA root certificate containing the CA root public key to verify whether the digital signature value contained in the second intermediate certificate is correct, and when the verification result is incorrect, it means that the third terminal entity certificate is incorrect .
  • the verification result When the verification result is correct, use the second intermediate certificate containing the public key of the second proxy device to verify whether the digital signature value contained in the third terminal entity certificate is correct, and when the verification result is incorrect, it means that the third terminal entity certificate is incorrect. When the verification result is correct, it means that the certificate of the third terminal entity is correct.
  • Step 509 After the proxy device detects that all terminal entities have successfully updated their certificates, it revokes all the first terminal entity certificates issued using the private key of the initial proxy device, generates a certificate revocation notification including CRL information, and passes the inter-board security channel. A certificate revocation notification is sent so as to notify each end entity to revoke the certificate of the first end entity.
  • Step 510 The terminal entity receives the certificate revocation notification, and imports the CRL information carried in the message into the context of the inter-board secure connection to revoke the certificate of the first terminal entity.
  • the proxy device possessing the intermediate certificate can issue digital certificates to each terminal entity, when the intermediate certificate needs to be updated, a large number of terminal entities do not need to request the CA server to update the intermediate certificate
  • the proxy device only needs to request the CA server to update the intermediate certificate, which avoids the need for a large number of terminal entities to update the intermediate certificate to the unique CA server, which reduces the load of the CA server and saves network bandwidth resources.
  • the proxy device updates the intermediate certificate, it sends an intermediate certificate update notification to the terminal entity in time, so that the terminal entity updates the terminal entity certificate in time.
  • an embodiment of the present application provides an apparatus 600 for issuing a digital certificate.
  • the apparatus 600 may be deployed in the proxy device provided in the embodiment shown in FIG. 3, FIG. 4, or FIG. 5, and includes: a receiving unit 601, which uses receiving a terminal entity certificate authorization request sent by a terminal entity, where the terminal entity certificate authorization request includes the first terminal entity public key;
  • a certificate issuing unit 602 configured to generate a first terminal entity certificate for the first terminal entity public key according to the terminal entity certificate authorization request, and use the first proxy device private key to digitally sign the first terminal entity certificate , obtain the digital signature value of the first terminal entity certificate, and generate a terminal entity certificate authorization response, wherein the terminal entity certificate authorization response includes the first terminal entity certificate and the certificate chain of the first terminal entity certificate,
  • the first terminal entity certificate includes the first terminal entity public key and the digital signature value of the first terminal entity certificate
  • the certificate chain of the first terminal entity certificate is used to verify the authenticity of the first terminal entity certificate.
  • the certificate chain of the first terminal entity certificate includes the authorized certification CA root certificate and the first intermediate certificate, wherein the first intermediate certificate includes the public key of the first proxy device, the first proxy device
  • the public key and the private key of the first proxy device are a pair of key pairs generated by the proxy device.
  • the sending unit 603 is configured to send the terminal entity certificate authorization response to the terminal entity.
  • the apparatus 600 further includes a verification unit 604 .
  • the sending unit 603 is further configured to send an intermediate certificate authorization request to the authorized certification CA server, where the intermediate certificate authorization request includes the public key of the first proxy device.
  • the receiving unit 601 is further configured to receive an intermediate certificate authorization response sent by the CA server, where the intermediate certificate authorization response includes the first intermediate certificate and the certificate chain of the first intermediate certificate, the first intermediate certificate
  • the intermediate certificate includes the public key of the first proxy device and the digital signature value of the first intermediate certificate, wherein the certificate chain of the first intermediate certificate includes the CA root certificate, the CA root certificate includes the CA root public key, and the The digital signature value of the first intermediate certificate is obtained by the CA server using the CA root private key to digitally sign the first intermediate certificate, and the CA root public key and the CA root private key are one generated by the CA server. key pair.
  • a verification unit 604 configured to verify that the digital signature value of the first intermediate certificate is correct using the certificate chain of the first intermediate certificate.
  • the receiving unit 601 is further configured to receive a first certificate update request sent by the terminal entity, where the first certificate update request includes the public key of the second terminal entity.
  • the certificate issuing unit 602 is further configured to generate a second terminal entity certificate for the second terminal entity public key according to the first certificate update request, and use the first proxy device private key to pair the The second terminal entity certificate is digitally signed, the digital signature value of the second terminal entity certificate is obtained, and a first certificate update response is generated, wherein the first certificate update response includes the second terminal entity certificate and the first certificate update response.
  • a certificate chain of two end-entity certificates the second end-entity certificate includes the second end-entity public key and the digital signature value of the second end-entity certificate, and the certificate chain of the second end-entity certificate is used for verification Whether the digital signature value of the second terminal entity certificate is correct, and the certificate chain of the second terminal entity certificate includes the CA root certificate and the first intermediate certificate.
  • the sending unit 603 is further configured to send the first certificate update response to the terminal entity.
  • the apparatus 600 further includes a replacement unit 605, and the replacement unit 605 is configured to use the certificate chain of the second intermediate certificate to verify that the digital signature value of the second intermediate certificate is correct. , and replace the first intermediate certificate with the second intermediate certificate.
  • the sending unit 603 is further configured to send a second certificate update request to the CA server, where the second certificate update request includes the public key of the second proxy device.
  • the receiving unit 601 is further configured to receive a second certificate update response sent by the CA server, where the second certificate update response includes a second intermediate certificate and a certificate chain of the second intermediate certificate, the The second intermediate certificate contains the public key of the second proxy device and the digital signature value of the second intermediate certificate, wherein the digital signature value of the second intermediate certificate is used by the CA server to use the CA root private key for the second intermediate certificate.
  • the intermediate certificate is digitally signed.
  • the receiving unit 601 is further configured to receive a third certificate update request sent by the terminal entity, where the third certificate update request includes the public key of the first terminal entity.
  • the certificate issuing unit 602 is further configured to generate a third terminal entity certificate for the first terminal entity public key according to the third certificate update request, and use the second proxy device private key to pair the The third terminal entity certificate is digitally signed, the digital signature value of the third terminal entity certificate is obtained, and a third certificate update response is generated, wherein the third certificate update response includes the third terminal entity certificate and the third certificate update response.
  • the certificate chain of the terminal entity certificate, the third terminal entity certificate contains the public key of the first terminal entity and the digital signature value of the third terminal entity certificate, and the certificate chain of the third terminal entity certificate is used to verify all Whether the digital signature value of the third terminal entity certificate is correct, the certificate chain of the third terminal entity certificate includes the CA root certificate and the second intermediate certificate, the second proxy device private key and the second proxy device
  • the public key is a pair of key pairs generated by the proxy device.
  • the sending unit 603 is further configured to send the third certificate update response to the terminal entity.
  • the replacement unit 605 is specifically configured to use the CA root public key to verify whether the digital signature value of the CA root certificate is correct, and when verifying that the digital signature value of the CA root certificate is incorrect, determine the second The intermediate certificate is incorrect; when verifying that the digital signature value of the CA root certificate is correct, use the CA root public key to verify whether the digital signature value of the second intermediate certificate is correct.
  • the digital signature value of the certificate is incorrect, it is determined that the second intermediate certificate is incorrect; when it is verified that the digital signature value of the second intermediate certificate is correct, it is determined that the second intermediate certificate is correct .
  • the proxy device with the intermediate certificate can issue digital certificates to each end entity.
  • there is only one CA server in a digital certificate management system and there can be multiple proxy devices, which avoids a large number of terminal entities requesting a unique CA server for digital certificate authentication for terminal entities, which reduces the It reduces the load on the CA server and saves network bandwidth resources.
  • the proxy device can provide the terminal entity with a very secure, fast and convenient digital certificate authentication.
  • an embodiment of the present application provides a terminal entity 700, and the terminal entity 700 may be deployed in the terminal entity provided in the embodiment shown in FIG. 3, FIG. 4, or FIG. 5, including:
  • the sending module 701 is configured to send a terminal entity certificate authorization request to the proxy device, where the terminal entity certificate authorization request includes the first terminal entity public key.
  • a receiving module 702 configured to receive a terminal entity certificate authorization response sent by the proxy device, wherein the terminal entity certificate authorization response includes a first terminal entity certificate and a certificate chain of the first terminal entity certificate, the first terminal entity certificate
  • the terminal entity certificate contains the first terminal entity public key and the digital signature value of the first terminal entity certificate, and the certificate chain of the first terminal entity certificate is used to verify whether the digital signature value of the first terminal entity certificate is correct.
  • a verification module 703, configured to verify whether the digital signature value of the first terminal entity certificate is correct by using the certificate chain of the first terminal entity certificate.
  • the sending module 701 is further configured to send a first certificate update request to the proxy device, where the first certificate update request includes the public key of the second terminal entity.
  • the receiving module 702 is further configured to receive the first certificate update response sent by the proxy device, where the first certificate update response includes the second terminal entity certificate and the second terminal entity certificate
  • the certificate chain of the second terminal entity includes the public key of the second terminal entity and the digital signature value of the certificate of the second terminal entity, and the certificate chain of the certificate of the second terminal entity is used to verify the second terminal entity certificate. Whether the digital signature value of the end-entity certificate is correct.
  • the terminal entity further includes a replacement module 704, configured to use the certificate chain of the second terminal entity certificate to verify that the digital signature value of the second terminal entity certificate is correct, replace the first terminal The entity certificate is replaced with the second end entity certificate.
  • the sending module 701 is further configured to send a third certificate update request to the proxy device, where the third certificate update request includes the public key of the first terminal entity.
  • the receiving module 702 is further configured to receive a third certificate update response sent by the proxy device, where the third certificate update response includes the third terminal entity certificate and the third terminal entity certificate.
  • a certificate chain, the third terminal entity certificate includes the first terminal entity public key and the digital signature value of the third terminal entity certificate, and the certificate chain of the third terminal entity certificate is used to verify the third terminal Whether the digital signature value of the entity certificate is correct.
  • the replacement module 704 is further configured to use the certificate chain of the third terminal entity certificate to verify that the digital signature value of the third terminal entity certificate is correct, and replace the first terminal entity certificate with the third end entity certificate.
  • the verification module 703 is specifically configured to use the CA root public key to verify whether the digital signature value of the CA root certificate is correct, and when verifying that the digital signature value of the CA root certificate is incorrect When verifying that the first terminal entity certificate is incorrect; when verifying that the digital signature value of the CA root certificate is correct, use the CA root public key to verify whether the digital signature value of the first intermediate certificate is correct , when verifying that the digital signature value of the first intermediate certificate is incorrect, it is determined that the first terminal entity certificate is incorrect; when verifying that the digital signature value of the first intermediate certificate is correct, use the The first proxy device public key included in the first intermediate certificate verifies whether the digital signature value of the first terminal entity certificate is correct, and when it is verified that the digital signature value of the first terminal entity certificate is incorrect, it is determined that the digital signature value of the first terminal entity certificate is incorrect. The first terminal entity certificate is incorrect; when it is verified that the digital signature value of the first terminal entity certificate is correct, it is determined that the first terminal entity certificate is correct.
  • the receiving module 702 is further configured to receive a certificate application notification sent by the proxy device.
  • an embodiment of the present application provides a schematic diagram of an apparatus 800 for issuing a digital certificate.
  • the apparatus 800 may be the proxy device in any of the foregoing embodiments.
  • the apparatus 800 includes at least one processor 801 , internal connections 802 , memory 803 and at least one transceiver 804 .
  • the apparatus 800 is an apparatus with a hardware structure, and can be used to implement the functional modules in the apparatus 600 described in FIG. 6 .
  • the certificate issuing unit 602, the verification unit 604 or the replacement unit 605 in the apparatus 600 shown in FIG. 6 can be implemented by calling the code in the memory 803 by the at least one processor 801, as shown in FIG. 6
  • the receiving unit 601 and the sending unit 603 in the apparatus 600 can be implemented by the transceiver 804 .
  • the apparatus 800 may also be used to implement the function of the proxy apparatus in any of the foregoing embodiments.
  • processor 801 may be a general-purpose central processing unit (central processing unit, CPU), network processor (network processor, NP), microprocessor, application-specific integrated circuit (application-specific integrated circuit, ASIC) , or one or more integrated circuits used to control the execution of the program of this application.
  • CPU central processing unit
  • NP network processor
  • ASIC application-specific integrated circuit
  • the internal connection 802 described above may include a path to transfer information between the above described components.
  • the internal connection 802 is a single board or a bus or the like.
  • the above transceiver 804 is used to communicate with other devices or communication networks.
  • the above-mentioned memory 803 can be a read-only memory (read-only memory, ROM) or other types of static storage devices that can store static information and instructions, a random access memory (random access memory, RAM) or other types of storage devices that can store information and instructions.
  • types of dynamic storage devices which can also be electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM), or other optical disk storage, optical disks storage (including compact discs, laser discs, compact discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or capable of carrying or storing desired program code in the form of instructions or data structures and capable of being accessed by Any other medium accessed by the computer without limitation.
  • the memory can exist independently and be connected to the processor through a bus.
  • the memory can also be integrated with the processor.
  • the memory 803 is used to store the application code for executing the solution of the present application, and the execution is controlled by the processor 801 .
  • the processor 801 is configured to execute the application program code stored in the memory 803, and cooperate with at least one transceiver 804, so that the apparatus 800 realizes the functions in the method of the present patent.
  • the processor 801 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 8 .
  • the apparatus 800 may include multiple processors, for example, the processor 801 and the processor 807 in FIG. 8 .
  • processors can be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor.
  • a processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (eg, computer program instructions).
  • an embodiment of the present application provides a schematic diagram of a terminal entity 900 .
  • the terminal entity 900 may be the terminal entity in any of the foregoing embodiments.
  • the end entity 900 includes at least one processor 901 , internal connections 902 , memory 903 and at least one transceiver 904 .
  • the terminal entity 900 is a device with a hardware structure, which can be used to implement the functional modules in the terminal entity 700 described in FIG. 7 .
  • the verification module 703 or the replacement module 704 in the terminal entity 700 shown in FIG. 7 can be implemented by calling the code in the memory 903 by the at least one processor 901.
  • the terminal entity 700 shown in FIG. 7 The sending module 701 and the receiving module 702 in the above can be implemented by the transceiver 904 .
  • the terminal entity 900 may also be used to implement the function of the proxy device in any of the foregoing embodiments.
  • processor 901 may be a general-purpose central processing unit (central processing unit, CPU), a network processor (network processor, NP), a microprocessor, an application-specific integrated circuit (application-specific integrated circuit, ASIC) , or one or more integrated circuits used to control the execution of the program of this application.
  • CPU central processing unit
  • NP network processor
  • ASIC application-specific integrated circuit
  • the internal connection 902 described above may include a path to transfer information between the above described components.
  • the internal connection 902 is a single board or a bus or the like.
  • the above transceiver 904 is used to communicate with other devices or communication networks.
  • the above-mentioned memory 903 can be a read-only memory (read-only memory, ROM) or other types of static storage devices that can store static information and instructions, a random access memory (random access memory, RAM) or other types of storage devices that can store information and instructions.
  • ROM read-only memory
  • RAM random access memory
  • Types of dynamic storage devices which can also be electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM), or other optical storage, CD-ROM storage (including compact discs, laser discs, compact discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or capable of carrying or storing desired program code in the form of instructions or data structures and capable of being accessed by Any other medium accessed by the computer, but not limited to this.
  • the memory can exist independently and be connected to the processor through a bus.
  • the memory can also be integrated with the processor.
  • the memory 903 is used for storing the application program code for executing the solution of the present application, and the execution is controlled by the processor 901 .
  • the processor 901 is configured to execute the application program code stored in the memory 903, and cooperate with at least one transceiver 904, so that the end entity 900 realizes the functions in the method of the present patent.
  • the processor 901 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 9 .
  • the terminal entity 900 may include multiple processors, for example, the processor 901 and the processor 907 in FIG. 9 .
  • Each of these processors can be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor.
  • a processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (eg, computer program instructions).
  • Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
  • a storage medium can be any available medium that a computer can access.
  • computer readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage media or other magnetic storage devices, or be capable of carrying or storing instructions or data structures in the form of desired program code and any other medium that can be accessed by a computer. also.
  • any connection can be appropriately made into a computer-readable medium.
  • the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave
  • coaxial cable , fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, wireless, and microwave
  • Disk and disc includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc, where disks usually reproduce data magnetically, and discs Lasers are used to optically copy data. Combinations of the above should also be included within the scope of computer-readable media.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente demande concerne un procédé et un appareil d'émission de certificat numérique, ainsi qu'une entité terminale et un système. Ledit procédé comprend les étapes suivantes : un dispositif mandataire reçoit une demande d'autorisation de certificat d'entité terminale, comprenant une première clé publique d'entité terminale, envoyée par une entité terminale ; et comme le dispositif mandataire lui-même possède un certificat intermédiaire et peut émettre un certificat numérique pour l'entité terminale, le dispositif mandataire génère, en fonction de la demande d'autorisation de certificat d'entité terminale, un premier certificat d'entité terminale pour la première clé publique d'entité terminale à l'aide d'une première clé privée de dispositif mandataire afin de signer numériquement le premier certificat d'entité terminale pour obtenir une valeur de signature numérique du premier certificat d'entité terminale, puis génère une réponse d'autorisation de certificat d'entité terminale et l'envoie à l'entité terminale. De cette manière, l'émission du premier certificat d'entité terminale par le dispositif mandataire est réalisée. Comme il peut y avoir une pluralité de dispositifs mandataires, cela permet d'éviter qu'un grand nombre d'entités terminales demandent au serveur CA unique d'effectuer une authentification de certificat numérique pour les entités terminales, ce qui permet de réduire la charge du serveur CA et d'économiser les ressources de bande passante du réseau.
PCT/CN2021/125960 2020-12-04 2021-10-25 Procédé et appareil d'émission de certificat numérique, entité terminale et système WO2022116734A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011402744.8A CN114598455A (zh) 2020-12-04 2020-12-04 数字证书签发的方法、装置、终端实体和系统
CN202011402744.8 2020-12-04

Publications (1)

Publication Number Publication Date
WO2022116734A1 true WO2022116734A1 (fr) 2022-06-09

Family

ID=81812368

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/125960 WO2022116734A1 (fr) 2020-12-04 2021-10-25 Procédé et appareil d'émission de certificat numérique, entité terminale et système

Country Status (2)

Country Link
CN (1) CN114598455A (fr)
WO (1) WO2022116734A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115567314A (zh) * 2022-10-14 2023-01-03 中电云数智科技有限公司 一种基于硬件可信信任链的License安全代理方法和平台
CN118487878A (zh) * 2024-07-16 2024-08-13 蔚来汽车科技(安徽)有限公司 数字证书获取方法、车辆、存储介质及计算机设备

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116865971B (zh) * 2023-06-12 2024-02-27 淮南市公安局 一种基于数字证书的物联网终端身份认证方法
CN118413321B (zh) * 2024-06-28 2024-10-01 鹏城实验室 资源公钥基础设施的资源签发方法、资源验证方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101488851A (zh) * 2009-02-25 2009-07-22 中国人民解放军信息工程大学 一种可信计算中签发身份证明证书的方法及装置
CN102546173A (zh) * 2011-12-19 2012-07-04 河海大学 基于证书的数字签名系统及签名方法
CN104486356A (zh) * 2014-12-29 2015-04-01 芜湖乐锐思信息咨询有限公司 基于互联网在线交易的数据传输方法
CN107360003A (zh) * 2017-08-17 2017-11-17 上海市数字证书认证中心有限公司 数字证书的签发方法、系统、存储介质以及移动终端
US10547457B1 (en) * 2016-10-21 2020-01-28 Wells Fargo Bank N.A. Systems and methods for notary agent for public key infrastructure names

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106453330B (zh) * 2016-10-18 2019-11-12 深圳市金立通信设备有限公司 一种身份认证的方法和系统
CN111934870B (zh) * 2020-09-22 2020-12-29 腾讯科技（深圳）有限公司 区块链网络中的根证书更新方法、装置、设备以及介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101488851A (zh) * 2009-02-25 2009-07-22 中国人民解放军信息工程大学 一种可信计算中签发身份证明证书的方法及装置
CN102546173A (zh) * 2011-12-19 2012-07-04 河海大学 基于证书的数字签名系统及签名方法
CN104486356A (zh) * 2014-12-29 2015-04-01 芜湖乐锐思信息咨询有限公司 基于互联网在线交易的数据传输方法
US10547457B1 (en) * 2016-10-21 2020-01-28 Wells Fargo Bank N.A. Systems and methods for notary agent for public key infrastructure names
CN107360003A (zh) * 2017-08-17 2017-11-17 上海市数字证书认证中心有限公司 数字证书的签发方法、系统、存储介质以及移动终端

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115567314A (zh) * 2022-10-14 2023-01-03 中电云数智科技有限公司 一种基于硬件可信信任链的License安全代理方法和平台
CN115567314B (zh) * 2022-10-14 2024-01-30 中电云计算技术有限公司 一种基于硬件可信信任链的License安全代理方法和平台
CN118487878A (zh) * 2024-07-16 2024-08-13 蔚来汽车科技(安徽)有限公司 数字证书获取方法、车辆、存储介质及计算机设备

Also Published As

Publication number Publication date
CN114598455A (zh) 2022-06-07

Similar Documents

Publication Publication Date Title
US10382485B2 (en) Blockchain-assisted public key infrastructure for internet of things applications
WO2022116734A1 (fr) Procédé et appareil d'émission de certificat numérique, entité terminale et système
US8788811B2 (en) Server-side key generation for non-token clients
US7512785B2 (en) Revocation distribution
US9621355B1 (en) Securely authorizing client applications on devices to hosted services
US20190166117A1 (en) System and method for securing data transport between a non-ip endpoint device that is connected to a gateway device and a connected service
US7181620B1 (en) Method and apparatus providing secure initialization of network devices using a cryptographic key distribution approach
US9225525B2 (en) Identity management certificate operations
US9137017B2 (en) Key recovery mechanism
US7865721B2 (en) Method and system for configuring highly available online certificate status protocol
US20110296171A1 (en) Key recovery mechanism
US7516326B2 (en) Authentication system and method
JP5215289B2 (ja) 分散式の委任および検証のための方法、装置、およびシステム
US20110213966A1 (en) Automatically generating a certificate operation request
US20060155855A1 (en) Apparatus, methods and computer software productus for judging the validity of a server certificate
KR20040013668A (ko) 공개키 기반구조에서 인증서 정책 및 인증서 정책사상을이용한 인증서 검증서버에서의 인증서 검증방법
EP1836798A2 (fr) Procede et appareil fournissant une revocation a base de politique de justificatifs d'identite de securite de reseau
US20110213961A1 (en) Dynamic user interface generation based on constraints of a certificate profile
JP2004032311A (ja) Ｐｋｉ対応の証明書確認処理方法及びその装置、並びにｐｋｉ対応の証明書確認処理プログラム
CN113472790A (zh) 基于https协议的信息传输方法、客户端及服务器
US20100223464A1 (en) Public key based device authentication system and method
Perugini et al. On the integration of Self-Sovereign Identity with TLS 1.3 handshake to build trust in IoT systems
JP2004248220A (ja) 公開鍵証明書発行装置、公開鍵証明書記録媒体、認証端末装置、公開鍵証明書発行方法、及びプログラム
JP2022552420A (ja) 証明書認証用の分散台帳に基づく方法およびシステム
JP2024513521A (ja) 組み込みデバイスの安全な信頼の起点登録及び識別管理

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21899768

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21899768

Country of ref document: EP

Kind code of ref document: A1