Remote key injection method and system based on asymmetric cryptography

Abstract

The invention discloses a remote key injection method and system based on asymmetric cryptography. The method comprises the following steps: establishing a three-level CA system, presetting a certificate, and strictly defining a theme identifier and an expansion key usage of the terminal certificate; both the device side and the server side verify the certificate chain and the extended key usage of the opposite side, actively acquire and verify the certificate revocation list of the intermediate CA of the opposite side, and perform anti-replay certificate state verification in combination with the OCSP; the two parties are bound with a specified communication party by comparing the certificate theme identifier with a preset authorization list; the two parties generate a temporary key pair, and an initial key is securely transmitted by adopting an asymmetric cryptography mechanism; and S4, the device end decrypts to obtain the initial key and securely stores the initial key. Through bidirectional peer-to-peer deep verification, service binding and forward security key negotiation mechanisms, the problems of insufficient authentication strength, easy replay attack, lack of forward security and poor flexibility in the prior art are solved.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a method and system for secure remote key distribution, injection and management in scenarios such as Internet of Things devices and financial terminals (such as POS machines and ATMs). Background Technology

[0002] With the widespread adoption of electronic payments and the Internet of Things (IoT), a massive number of terminal devices require key management. Traditional key injection methods (such as manual offline injection) suffer from inefficiency, high costs, and significant security risks. While existing remote key injection schemes have partially solved the efficiency problem, they still have the following drawbacks: 1) Insufficient authentication strength: Most solutions are only one-way authentication or simple two-way authentication, which cannot effectively prevent man-in-the-middle attacks and server impersonation, and lack strict verification of certificate roles.

[0003] 2) Lack of forward security: If a fixed key pair is used for key transmission, once the device's long-term private key is leaked, all historical session keys may be cracked.

[0004] 3) Weak revocation status verification mechanism: Most solutions neglect to verify the status of intermediate CAs in the certificate chain, and the certificate status query mechanism is vulnerable to replay attacks or is inefficient.

[0005] 4) Poor flexibility: The solution is usually tied to a specific encryption algorithm, making it difficult to adapt to different security level requirements.

[0006] In existing technologies, such as the remote key injection scheme described in publication number CN118118180A, multiple security flaws have been exposed in practical applications, making it difficult to meet the requirements of high-security scenarios: 1) Insufficient authentication strength and lack of cryptographic identity binding and tenant isolation: Existing solutions rely on the "instruction pool" and "operation permissions" of the business layer for authorization, which is application-layer control rather than strong cryptographic authentication. They only verify the extended key usage extensions of the terminal certificate, failing to prevent the device certificate from being used to impersonate servers at the cryptographic level. Furthermore, they lack a tenant isolation mechanism based on certificate subject identification, resulting in weak authentication strength and the risk of unauthorized access.

[0007] 2) Incomplete certificate status verification poses a risk of revocation bypass: Existing solutions only mention using a pre-set upper-level certificate to verify the working certificate, but do not perform effective revocation status verification (such as querying the Certificate Revocation List, CRL) for intermediate CA certificates in the certificate chain. If the private key of the server or intermediate CA is leaked, attackers can use revoked but not expired certificates in conjunction with Key Management Service (KMS) to communicate, and existing solutions cannot identify and prevent such attacks.

[0008] 3) Lack of forward security in key negotiation, leading to the breach of historical data due to long-term key leakage: In existing schemes, the master key generated by the client (such as TMK) is used for a long time. Once this long-term key is leaked, the encryption keys of all historical sessions can be traced and decrypted, completely losing forward security and posing a serious threat to historical communication data.

[0009] 4) The channel security model has flaws and is vulnerable to man-in-the-middle attacks: The existing solution requires the establishment of a "first transparent channel" and a "second transparent channel" with the client and server respectively through PC tools, lacking a true end-to-end secure channel. The PC tools themselves may become a security weakness, and there is a risk that they can be maliciously used as man-in-the-middle (MitM) tools for eavesdropping or tampering.

[0010] 5) Security inversion in key generation and storage logic: The key generation and storage logic of the existing scheme may have design flaws and fail to follow the core principle that "keys should be generated and stored in the most secure environment".

[0011] Therefore, there is an urgent need in this field for a remote key injection scheme that can achieve strong two-way authentication, has role binding capabilities, forward security, and provides efficient and reliable certificate status verification. Summary of the Invention

[0012] The technical problem this invention aims to solve is to provide a remote key injection method and system to address the issues of insufficient authentication strength and lack of forward security in existing solutions. The method constructs a multi-tenant isolated three-level CA certificate system, combined with a deep authentication mechanism where both communicating parties are fully equivalent in verification strength and process (both parties verify each other's certificate chains, the intermediate CA's CRL, and the terminal certificate's OCSP status, and perform service binding), and forward secure key transmission based on temporary key pairs, ultimately achieving highly secure, replay-resistant, and scalable remote initial key injection.

[0013] In a first aspect, the present invention provides a remote key injection method based on asymmetric cryptography, comprising: S1. Establish a three-tier CA system. The system includes a device certificate chain and a server certificate chain; the device terminal certificate chain consists of a device intermediate CA and a device terminal certificate; the server certificate chain consists of a server intermediate CA and a server terminal certificate; the offline root CA certificate or its public key serves as a pre-configured trust anchor for both communicating parties and is not included in the certificate chain transmitted during two-way authentication; wherein, both the device terminal certificate and the server terminal certificate contain strictly defined subject-distinguishable names and extended key usage extensions. S2, peer-to-peer two-way authentication and mixed-state verification, including: S21. The device initiates a connection to the server and sends the device certificate chain; the device certificate chain is a hierarchical certificate sequence that follows the three-level CA system and consists of the device intermediate CA certificate and the device terminal certificate; wherein, the issuer of the device intermediate CA certificate is the offline root CA. S22. The server receives the device's certificate chain and verifies that the signature and extended key usage of the device's certificate chain conform to the client's authentication role. The server actively obtains the latest certificate revocation list signed by the root CA from the preset address to verify the validity of the intermediate certificate authority's certificate on the device. The server queries the OCSP status of the device's terminal certificate to complete the verification. The server binds to the specified device by comparing the identifier in the distinguishable name of the device's certificate subject with the server's preset device authorization list. S23. The server sends a server certificate chain to the device. The server certificate chain is a hierarchical certificate sequence that follows the three-level certificate authority (CA) system and consists of a server intermediate CA certificate and a server terminal certificate. The issuer of the server intermediate CA certificate is also the offline root CA. S24. The device receives the server certificate chain and verifies that the signature and extended key usage of the server certificate chain conform to the server authentication role; the device actively obtains the latest certificate revocation list signed by the offline root CA from the preset address to verify the validity of the server intermediate CA certificate; the device verifies the validity of the OCSP response; and also achieves binding with the specified server by comparing the identifier in the subject distinguishable name of the server terminal certificate with the server authorization list preset on the device. S3. The two communicating parties securely transmit the initial key based on a temporary key pair using an asymmetric cryptographic mechanism; S4. The device decrypts the initial key and stores it securely.

[0014] Furthermore, the extended key usage extension item of the device terminal certificate includes two key purpose identifiers: client authentication and custom business OID; the extended key usage extension item of the server terminal certificate includes two key purpose identifiers: server authentication and custom business OID.

[0015] Furthermore, the public name field of the subject distinguishable name of the device terminal certificate contains a unique device identifier; the public name field of the subject distinguishable name of the server terminal certificate contains a server network identifier, and the server network identifier is a fully qualified domain name, on which client code is structured and integrated.

[0016] The public name field of the subject distinguishable name of the intermediate CA certificate of the device includes the client code and role identifier; the public name field of the subject distinguishable name of the intermediate CA certificate of the server includes the client code and role identifier.

[0017] Furthermore, S3 specifically includes: S31. The device generates a temporary asymmetric key pair and sends an initial key download request to the server. The request includes initial key metadata, the device's temporary asymmetric public key, and a digital signature generated using the device's long-term private key. The digital signature covers the initial key metadata and the device's temporary asymmetric public key. S32. The server receives the initial key download request, uses the device terminal long-term public key extracted from the verified device terminal certificate to verify the digital signature, and after successful verification, obtains the initial key metadata and the device terminal temporary asymmetric public key. S33. The server generates an initial key based on the initial key metadata, and selects one of the following two paths according to the scheme negotiated with the device to construct the ciphertext (i.e., key block) for transmitting the initial key: Scheme A, RSA-based key transmission: The server uses the device's temporary RSA public key corresponding to the device's temporary asymmetric public key to encrypt the initial key, and the resulting ciphertext is used as the "ciphertext key data" for subsequent key block construction; Scheme B, ECC-based key negotiation: The server generates a server-side temporary ECC key pair, and uses the server-side temporary ECC private key and the device-side temporary asymmetric public key corresponding to the device-side temporary ECC public key to generate a shared key through the ECDH key negotiation algorithm. The initial key is then encrypted using this shared key, and the resulting ciphertext is used as the "ciphertext key data" for subsequent key block construction. At the same time, the server-side temporary ECC public key is encoded for embedding in the key block. S34. The server sends the initial key ciphertext (i.e., key block) to the device. The key block is an encapsulation structure that includes at least: a key data header, ciphertext key data, and a digital signature. In Scheme B, the server's temporary ECC public key is encoded in the key data header.

[0018] Furthermore, in Scheme A, the server uses the RSA-OAEP padding scheme to encrypt the initial key using the device's temporary RSA public key; In Scheme B, the server uses the AES algorithm to encrypt the initial key using the shared key.

[0019] Furthermore, the initial key ciphertext sent from the server to the device in S34 is data encapsulated using a key block structure, which includes at least: Key header: Contains metadata information of the initial key; Ciphertext key data: The initial ciphertext key generated by the server; Digital signature: generated by the server using its long-term private key to sign the concatenated data of the key data header and the ciphertext key data; If scheme B is selected, the server's temporary ECC public key is encoded and embedded in the key data header for transmission.

[0020] Furthermore, the offline root CA certificate or its public key is pre-installed in all devices and servers as a public trust anchor; the device intermediate CA certificate, the device terminal certificate, and their corresponding long-term public-private key pairs are pre-installed in the device; wherein, the long-term public-private key pairs are randomly generated by the device; when the server and device perform two-way authentication, the validity period of the OCSP response obtained from the other party is verified, and the validity period does not exceed 5 minutes; when verifying the status of the other party's intermediate CA certificate, both the device and the server obtain the latest certificate revocation list from the designated CRL distribution point of the corresponding intermediate CA certificate via HTTPS protocol for verification.

[0021] Furthermore, if the device cannot directly access the designated certificate revocation list distribution point or online certificate status protocol responder due to network limitations, the server-side agent obtains the certificate status evidence and securely transmits it to the device through the initial key download process, specifically including: The initial key download request initiated by the device to the server includes a status evidence request identifier; After receiving and verifying the request, the server obtains the latest certificate revocation list and the peer's online certificate status protocol response from the specified certificate revocation list distribution point and online certificate status protocol responder. The server generates a composite response message containing the initial key ciphertext, the latest certificate revocation list, and the online certificate status protocol response. The server then digitally signs the composite response message using its long-term private key to generate a server response signature. The server then sends the composite response message and the server response signature to the device. The device receives the composite response message and the server response signature, and verifies the server response signature using the server long-term public key extracted from the verified server terminal certificate. After successful verification, the device obtains the initial key header, initial key ciphertext data, latest certificate revocation list, and online certificate status protocol response from the composite response message, and performs independent verification operations on the latter two, including: verifying the signature and validity period of the latest certificate revocation list, and verifying the digital signature and validity of the online certificate status protocol response.

[0022] Secondly, the present invention provides a remote key injection system based on asymmetric cryptography for implementing the method described in the first aspect. The system includes a three-level CA system, a device, a server, an OCSP responder, and a certificate revocation list distribution point. The three-tier CA system includes a device terminal certificate chain and a server certificate chain. The device terminal certificate chain consists of a device intermediate CA certificate and a device terminal certificate. The server certificate chain consists of a server intermediate CA certificate and a server terminal certificate. The offline root CA certificate or its public key serves as a pre-configured trust anchor for both communicating parties and is not included in the certificate chain transmitted during two-way authentication. Each of the device intermediate CA certificate, the device terminal certificate, the server intermediate CA certificate, and the server terminal certificate contains a strictly defined subject-distinguishable name and extended key usage extension. The device and the server are configured to perform peer-to-peer two-way authentication and mixed-state verification; and are configured to securely transmit the initial key based on a temporary key pair using an asymmetric cryptographic mechanism; and the device decrypts the initial key to obtain it and stores it securely. The OCSP responder is used to provide certificate status query services; The certificate revocation list distribution point is used to publish a certificate revocation list signed by the root CA; The two-way authentication and mixed-state verification include: The device initiates a connection to the server and sends the device's certificate chain; The server receives the device's certificate chain and verifies that the signature and extended key usage of the device's certificate chain conform to the client's authentication role. The server proactively obtains the latest certificate revocation list signed by the root CA from the preset address to verify the validity of the device's intermediate CA certificate. The server queries the OCSP status of the device's terminal certificate to complete the verification. The server binds to the specified device by comparing the identifier in the device's certificate subject distinguishable name with the server's preset device authorization list. The server sends its certificate chain to the device. The device receives the server's certificate chain and verifies that the signature and extended key usage of the server's certificate chain conform to the server's authentication role. The device actively obtains the latest certificate revocation list signed by the root CA from the preset address to verify the validity of the server's intermediate CA certificate. The device queries the OCSP status of the server's terminal certificate to complete the verification. The device binds to the specified server by comparing the identifier in the subject distinguishable name of the server's terminal certificate with the server's preset server authorization list.

[0023] The present invention has the following technical effects: (1) Two-way peer-to-peer deep authentication and role binding security: Through two-way, peer-to-peer certificate chain verification and mandatory checks on the use of subject identifiers and extended keys, strict identity and role binding between the communicating parties is achieved. Even if the long-term private key of a single entity is leaked, attackers cannot use its certificate to impersonate entities of other roles (e.g., impersonate a server with a device certificate), nor can they commit fraud through unverified intermediate CAs, thus building a defense-in-depth from the source of authentication.

[0024] (2) Ensure forward-secure session key establishment: By generating asymmetric key pairs temporarily for each session and transmitting keys based on ECC key negotiation or RSA key transmission mechanism, it is ensured that even if the long-term identity private keys of the two communicating parties are leaked in the future, the historical session keys will remain secure, fundamentally protecting the confidentiality of past communications.

[0025] (3) Replay resistance and complete certificate chain status verification: The hybrid verification mechanism combines short-validity OCSP binding response with HTTPS-based active acquisition of certificate revocation list. This not only achieves efficient and replay-resistant verification of the terminal certificate status, but also forces the other party's intermediate CA certificate status to actively perform CRL verification, thus achieving complete confirmation of the feasible status of the entire certificate chain and eliminating the security risks introduced by the revocation of intermediate CA.

[0026] (4) Algorithm compatibility and deployment flexibility: Supports forward-secure ECC and RSA paths, allowing for selection based on actual deployment needs. The solution adopts standard certificate formats and subject identifiers, ensuring good interoperability with general PKI software and hardware devices. The mechanism is also applicable to local key injection scenarios with high security requirements.

[0027] (5) Efficient hierarchical certificate revocation and business emergency response: A two-tier emergency mechanism combining cryptographic revocation and business control has been established. When a security incident occurs, the authorization list can be updated in real time at the business layer to immediately block the access of suspicious entities; at the same time, a certificate revocation list is published through the PKI system to completely revoke the relevant certificates from the cryptographic root upwards. The combination of the two achieves a security-in-depth response from immediate control to fundamental revocation.

[0028] (6) Adaptability to complex network environments: By supporting a hybrid working mode in which the server-side agent obtains certificate status evidence and the device-side leads the verification, the stringent requirements on the network connectivity of the device-side are reduced without reducing the security strength of the final verification. This enables the solution to adapt to complex IoT deployment scenarios such as firewall restrictions and offline environments.

[0029] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0030] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0031] Figure 1 This is a schematic diagram of the system framework of the present invention; Figure 2 This is a flowchart illustrating the overall method of an embodiment of the present invention; Figure 3 This is a detailed flowchart of the two-way authentication and status verification in an embodiment of the present invention; Figure 4 This is a flowchart of the forward security key negotiation process based on ECC in an embodiment of the present invention; Figure 5 This is a flowchart of the forward security key negotiation process based on RSA in an embodiment of the present invention. Detailed Implementation

[0032] The overall approach of this application is as follows: By establishing a three-level CA system and strictly standardizing the subject-distinguished name and extended key usage extension items of the certificate, combined with peer-to-peer two-way authentication (including hybrid certificate status verification: both parties actively obtain CRL to verify the other party's intermediate CA, and combine OCSP to bind and verify the other party's terminal certificate) and a two-way service binding mechanism, a parallel scheme based on temporary key pairs (RSA-based key transmission or ECC-based forward secure key negotiation) is adopted to achieve secure transmission of the initial key. Finally, the device decrypts and securely stores the key to solve the problems of insufficient authentication strength, lack of forward security, weak revocation verification, and poor flexibility of remote key injection schemes.

[0033] Before introducing specific embodiments, the system framework corresponding to the method in the embodiments of this application will be introduced first, such as... Figure 1 As shown, the system mainly includes the following: A three-tiered CA system comprises a device-side certificate chain and a server-side certificate chain. The device-side certificate chain consists of a device-side intermediate CA certificate and a device terminal certificate; the server-side certificate chain consists of a server-side intermediate CA certificate and a server-side terminal certificate. The offline root CA certificate or its public key serves as a pre-defined trust anchor jointly established by both communicating parties and is not included in the certificate chain transmitted during two-way authentication.

[0034] Device side: Configured to initiate connections, provide its own certificate chain, verify the server's certificate chain, and its... Extended key usage includes: actively obtaining and verifying the Certificate Revocation List (CRL) of the server-side intermediate CA; verifying the OCSP status of the server-side terminal certificate; performing service binding; generating temporary key pairs; participating in key negotiation; or decrypting and securely storing the initial key.

[0035] Server-side: Configures for verifying the device-side certificate chain and its extended key usage extensions, actively obtains and verifies the Certificate Revocation List (CRL) of the device's intermediate CA, queries the OCSP status of the device terminal certificate, performs device binding, generates temporary key pairs, participates in key negotiation, and encrypts and transmits the initial key.

[0036] Online Certificate Status Protocol (OCSP) responder: Used to provide real-time query and response services for certificate status.

[0037] Certificate Revocation List (CRL) distribution points are used to publish a list of certificates revocation signed by the appropriate root CA.

[0038] Example 1 like Figure 2 As shown, this embodiment provides a remote key injection method based on asymmetric cryptography, including: S1. Establish a three-level CA system.

[0039] The system includes a device terminal certificate chain and a server-side certificate chain; The device terminal certificate chain consists of an intermediate CA certificate on the device side and a device terminal certificate. The server certificate chain consists of a server intermediate CA certificate and a server terminal certificate; Offline root CA certificates or their public keys serve as a pre-defined trust anchor for both communicating parties and are not included in the certificate chain transmitted during two-way authentication. The device-side intermediate CA certificate, the device terminal certificate, the server-side intermediate CA certificate, and the server-side terminal certificate all contain strictly defined subject-distinguishable names and extended key usage extensions. The offline root CA certificate is generally issued by a dedicated CA institution. The device intermediate CA certificate and the server intermediate CA certificate are both issued by the offline root CA certificate. The device end - user certificate is issued by the device intermediate CA certificate, and the server end - user certificate is issued by the server intermediate CA certificate.

[0040] As Figure 1 shown, this system is designed for a multi - tenant architecture, and the specific specifications are as follows: (1)Intermediate CA certificate subject identification specification To achieve multi - tenant management and business isolation, for the device intermediate CA certificate and the server intermediate CA certificate, the common name (CN) field of their subject distinguished name is configured to include the customer code and the role identifier.

[0041] Specifically, the subject distinguished name of the intermediate CA certificate issued for this solution follows the following specifications: Device - side intermediate CA certificate: The format of its CN (common name) field is <KMS provider>-KMS-<customer code>-Device - CA, which is used to sign all device - side end - user certificates for a specified customer.

[0042] Server - side intermediate CA certificate: The format of its CN (common name) field is <KMS provider>-KMS -<customer code>-Server - CA, which is used to sign the key management server end - user certificates for a specified customer.

[0043] Among them, <customer code> and the role identifier -Device - CA or -Server - CA together constitute the unique identifier of this intermediate CA, achieving logical isolation based on customers.

[0044] This specification ensures the logical isolation of each customer's certificate system, facilitating fine - grained certificate lifecycle management and security policy implementation.

[0045] (2)Certificate subject identification specification To achieve the unique identification and two - way binding of devices and services: The common name (CN) field of the subject distinguished name of the device end - user certificate contains the device unique identifier (such as the serial number).

[0046] The common name (CN) field of the subject distinguished name of the server end - user certificate contains the server network identifier, which is a fully qualified domain name in the format of <service name>.<customer code>.<primary domain name>, to structurally incorporate the customer code, such as kms.customer - a.example.com.

[0047] The specific format definition is as follows: Device terminal certificate: CN=<Device_Serial_Number> OU = POS-Terminal, O = <pos-oem>(in,<Device_Serial_Number> This is a unique serial number for the device. <pos-oem>(The name of the equipment manufacturer) Server-side terminal certificate: CN=<Server_FQDN> OU = POS-Server, O = <pos-oem>(in,<Server_FQDN> For a fully qualified domain name that conforms to the above format, <pos-oem>(For service provider or vendor name) Note: This specification prioritizes the use of the standard X.500 field to ensure compatibility with common PKI software. OU The value of the field (POS-Terminal / POS-Server) is used to clearly distinguish whether the certificate holder is a device or a server, while the content of the CN field is the core basis for realizing two-way service binding.

[0048] (3) Certificate Extension Key Usage Extension Item Specification Device and server terminal certificates must explicitly include the client authentication OID and server authentication OID in the ExtendedKeyUsage field, respectively, and append a custom business OID. This mandatory policy implements strict role binding, ensuring that even if the private key is leaked, the certificate cannot be used for unauthorized roles.

[0049] (4) Trust anchors and certificate pre-configuration Pre-install the offline root CA certificate or its public key in all devices and servers as a common trust anchor; Pre-configured on the device side: device intermediate CA certificate, device terminal certificate and their corresponding long-term public-private pair, wherein the long-term private key of the device is securely generated and stored on the device side; On the server side, the following are pre-configured: server-side intermediate CA certificate, server-side terminal certificate, and their corresponding long-term public-private key pairs.

[0050] (5) Pre-set two-way service binding identifier To achieve peer-to-peer binding between the communicating parties and ensure that only authorized devices can access the specified server, and vice versa, the following configuration is required: Device-side configuration: The CN field of the server certificate of the KMS instance to which the device is authorized to connect and the CN field of the intermediate CA certificate of the server to which it belongs are pre-set in the device's security configuration for server binding during authentication.

[0051] Server-side configuration: The CN field of the terminal certificate of the terminal device that is allowed to access this KMS instance and the CN field of the intermediate CA certificate of the device to which it belongs are pre-set in the authorization list of the server, which is used to implement device binding during authentication.

[0052] Step S1 establishes a three-tiered CA system for multi-tenant isolation, providing trusted identity credentials for device terminals and servers, laying the foundation for subsequent two-way authentication and secure key transmission. Specifically, a standardized certificate system is constructed to issue certificates to both device terminals and servers, containing strictly defined subject-distinguished names (such as a unique device identifier and a server network identifier) ​​and extended key usage extensions, clearly defining certificate roles and purposes and preventing cross-role abuse. Logically, the three-tiered CA system consists of a device-side certificate chain and a server-side certificate chain, both sharing the same offline root CA as a trust anchor. The offline root CA certificate or its public key serves as a pre-configured trust anchor for both communicating parties and is not included in the certificate chain transmitted during two-way authentication. During two-way authentication, both parties utilize their locally pre-configured root CA certificate or its public key, combined with intermediate CA certificates obtained from each other's certificate chains, to progressively build and verify a complete trust chain leading to the other party's terminal certificate. The subject-distinguished name of the intermediate CA certificate includes a client code and role identifier, thereby achieving business isolation and fine-grained management for different tenants. The above strict certificate specifications ensure that the legitimacy of the other party's identity (such as valid certificate signature and subject-distinguishable name matching) and the correctness of the role (such as extended key usage extension items conforming to server or client authentication roles) can be reliably verified in subsequent two-way authentication, thus providing a crucial pre-security guarantee for the secure transmission of the initial key.

[0053] After certificate pre-configuration is completed, to ensure that the two-way authentication in step S2 can perform CRL verification of the other party's intermediate CA certificate and OCSP status verification of the terminal certificate, the source of these certificate status verification resources (i.e., CRL distribution points and OCSP responder addresses) needs to be clearly defined. The design is as follows: In the PKI system of this scheme, the Certificate Revocation List (CRL) distribution point address and OCSP responder address serve as authoritative status query sources, and their information is encoded in the extended fields of the corresponding certificates.

[0054] Specifically, in a preferred embodiment of the present invention: The CRL Distribution Point extension of the server-side intermediate CA certificate specifies its own certificate revocation list publishing address.

[0055] The CRL distribution point extension of the intermediate CA certificate on the device side also specifies its own certificate revocation list publication address.

[0056] The corresponding OCSP responder address is usually recorded in the Authority Information Access (AIA) extension of the certificate.

[0057] Therefore, when performing the two-way authentication described in S2: When the device needs to verify the status of the server's intermediate CA certificate, the "pre-set address" used to obtain the CRL is derived from the CRL distribution point address declared by the server's intermediate CA certificate, which is parsed from the server's certificate chain.

[0058] When the server needs to verify the status of the intermediate CA certificate on the device, the "pre-set address" used to obtain the CRL is derived from the CRL distribution point address declared by the intermediate CA certificate on the device, which is parsed from the device certificate chain.

[0059] This mechanism ensures that both communicating parties can always obtain the latest status information from the authoritative address specified by the certificate issuer (i.e., the corresponding intermediate CA), thus realizing the dynamic and reliable acquisition of verification resource addresses.

[0060] S2, peer-to-peer two-way authentication and mixed-state verification, including: S21. The device initiates a connection to the server and sends the device's certificate chain. S22. The server receives the device's certificate chain and verifies that the signature and extended key usage of the device's certificate chain conform to the client's authentication role. The server actively obtains the latest certificate revocation list signed by the root CA from a pre-configured address (obtained from the specified CRL distribution point via HTTPS protocol) to verify the validity of the device's intermediate CA certificate. The server queries the OCSP status of the device's terminal certificate to complete the verification. The server binds to the specified device by comparing the identifier in the distinguishable name of the device's certificate subject with the server's pre-configured device authorization list. S23. The server sends the server certificate chain to the device. S24. The device receives the server certificate chain and verifies that the signature and extended key usage of the server certificate chain conform to the server authentication role. The device actively obtains the latest certificate revocation list signed by the root CA from the preset address (obtained from the specified CRL distribution point via HTTPS protocol) to verify the validity of the server intermediate CA certificate. The device queries the OCSP status of the server terminal certificate to complete the verification. The device binds to the specified server by comparing the identifier in the subject distinguishable name of the server terminal certificate with the server's preset server authorization list. The specific process is as follows: Figure 3 As shown: 1) The device sends the solution version and the device certificate chain to the server.

[0061] 2) The server verifies the device's certificate chain, parsing the subject-distinguishable names from the device's intermediate CA certificate and terminal certificate to obtain the tenant client code and device serial number (device unique identifier), and verifies whether they match the server's pre-configured list of authorized devices. Simultaneously, it verifies whether the extended key usage extensions include client authentication and custom business OIDs. Upon successful verification, the server proactively retrieves the latest certificate revocation list from the pre-configured CRL distribution point, verifying that the device's terminal CA certificate has not been revoked. After successful verification, the server proactively queries the OCSP responder for the OCSP status of the device's terminal certificate and verifies the returned OCSP response to ultimately complete the device authentication.

[0062] 3) The server sends the server certificate chain to the device.

[0063] 4) The device verifies the server certificate chain by parsing the subject-distinguishable names from the server's intermediate CA certificate and the server terminal certificate to obtain the tenant client code and server network identifier. It then verifies whether this tenant client code and server network identifier match the device's pre-configured list of authorized KMS services. Simultaneously, it verifies whether the extended key usage extensions include server authentication and a custom business OID. Upon successful verification, the device proactively retrieves the latest certificate revocation list from the pre-configured CRL distribution point to verify that the server terminal CA certificate has not been revoked. After successful verification, the device proactively queries the OCSP responder for the OCSP status of the server terminal certificate and verifies the returned OCSP response to ultimately complete the authentication of the server.

[0064] To address private key breaches, this solution establishes a two-tiered emergency response mechanism based on risk level, initiating corresponding handling procedures according to the certificate level associated with the breached private key: Terminal certificate private key leakage incident response: When the private key of an endpoint certificate on a single device or server is leaked, proceed in the following order: Level 1 (Business operations are isolated): If a device's terminal certificate is leaked, the server will immediately remove the leaked device identifier from its device authorization list and block the device's access. If the server's terminal certificate is leaked, the server will immediately remove the leaked server network identifier (FQDN) from its global configuration and push an update to the server authorization list of all relevant devices to guide the devices to switch or stop connecting.

[0065] Level 2 (Cryptographic Permanent Revocation): The CA adds the leaked terminal certificate serial number to the latest Certificate Revocation List (CRL) and publishes it. The OCSP responder will, based on this latest CRL information, return a "revoked" response to subsequent status queries regarding the certificate. The dependent party (device or server) will then respond in the next... Emergency Response to Intermediate CA Certificate Private Key Leakage: When the private key of the intermediate CA on the device or the intermediate CA on the server is leaked, the highest level of emergency response must be initiated due to its wide-ranging impact: Level 1 (Emergency Business Blocking and Cryptographic Revocation: Immediate and Parallel Execution): Business blocking: Immediately remove all server network identifiers (FQDNs) or device identifiers issued by this leaked CA from all authorized lists in bulk.

[0066] Emergency CRL Release: The CA immediately generates and releases a special CRL revoking the leaked intermediate CA certificate itself. This CRL should be notified to all dependent parties through the emergency channel.

[0067] Level Two (Certificate System Reconstruction): Initiate the reissue process for all terminal certificates under the damaged CA, and update the pre-installed certificates and authorization lists for all relevant devices. Until this is completed, the entire business line relying on this CA is in a damaged or suspended state.

[0068] Step S2 completes two-way authentication and certificate status verification between the device and server, ensuring the legitimacy of both parties' identities and the validity of their certificates. Specifically, this includes: the device and server mutually verifying the signature of each other's certificate chain and the role in the extended key usage extension; both parties performing a pre-defined authorization list comparison based on the subject identifier to achieve two-way service binding; both the device and server actively obtaining the CRL to verify the status of the server's intermediate CA certificate and the device's intermediate CA certificate respectively; simultaneously, both the device and server actively querying the OCSP status of the terminal certificate to verify the status of the server's terminal certificate and the device's terminal certificate respectively. This process effectively prevents man-in-the-middle attacks and unauthorized access.

[0069] After completing two-way authentication and establishing a feasible secure channel, both parties enter the key transmission phase based on temporary key pairs.

[0070] S3. The communicating parties securely transmit the initial key using an asymmetric cryptographic mechanism based on a temporary key pair; specifically including: S31. The device generates a temporary asymmetric key pair and sends an initial key download request to the server. The request includes initial key metadata, the device's temporary asymmetric public key, and a digital signature generated using the device's long-term private key. The digital signature covers the initial key metadata and the device's temporary asymmetric public key. S32. The server receives the initial key download request, uses the device terminal long-term public key extracted from the verified device terminal certificate to verify the digital signature, and after successful verification, obtains the initial key metadata and the device terminal temporary asymmetric public key. S33. The server generates an initial key based on the initial key metadata, and selects one of the following two paths according to the scheme negotiated with the device to construct the ciphertext (i.e., key block) for transmitting the initial key: Scheme A, RSA-based key transmission: The server uses the device's temporary RSA public key corresponding to the device's temporary asymmetric public key to encrypt the initial key, and the resulting ciphertext is used as the "ciphertext key data" for subsequent key block construction; Scheme B, ECC-based key negotiation: The server generates a server-side temporary ECC key pair, and uses the server-side temporary ECC private key and the device-side temporary asymmetric public key corresponding to the device-side temporary ECC public key to generate a shared key through the ECDH key negotiation algorithm. The initial key is then encrypted using this shared key, and the resulting ciphertext is used as the "ciphertext key data" for subsequent key block construction. At the same time, the server-side temporary ECC public key is encoded for embedding in the key block. S34. The server sends the initial key ciphertext (i.e., key block) to the device. The key block, as an encapsulation structure, includes at least: a key data header, ciphertext key data, and a digital signature. In Scheme B, the server's temporary ECC public key is encoded in the key data header. The initial key ciphertext sent by the server to the device is data encapsulated using a key block structure, which includes at least: Key header: Contains metadata information of the initial key; Ciphertext key data: The initial ciphertext key generated by the server; Digital signature: generated by the server using its long-term private key to sign the concatenated data of the key data header and the ciphertext key data; If scheme B is selected, the server's temporary ECC public key is encoded and embedded in the key data header for transmission.

[0071] Step S3 uses an asymmetric cryptographic mechanism based on a temporary key pair to securely transmit the initial key, ensuring the confidentiality and forward security of key transmission. Two parallel schemes are supported (RSA temporary public key encryption / ECDH key negotiation to generate a shared key encryption), which are negotiated and selected by both parties to adapt to different security levels and scenario requirements. Using a temporary key pair (RSA or ECC) to transmit the key avoids long-term key leakage leading to the cracking of historical session keys. Scheme A uses RSA-OAEP padding encryption, while Scheme B uses AES encryption to ensure that the initial key transmission process is not stolen or tampered with.

[0072] Furthermore, to enable those skilled in the art to clearly and completely implement this invention, the cryptographic algorithms used in this embodiment and their specific parameters are now described in detail. Unless otherwise stated, the following specifications apply to all embodiments of this invention.

[0073] (1) Algorithm parameters used in Scheme A (RSA-based key transmission): Asymmetric encryption algorithm: The RSA-2048 algorithm is adopted. The temporary RSA key pair of the device and the operation of the server to encrypt the initial key are both 2048 bits in length. Asymmetric encryption padding scheme: adopts RSA-OAEP padding mode; Hash Algorithm: The hash function associated with the RSA-OAEP padding scheme, as well as other hash algorithms involved in this invention (such as certificate signature verification, data integrity verification, etc.), all adopt the SHA-256 algorithm.

[0074] (2) Algorithm parameters used in Scheme B (ECC-based key negotiation): Asymmetric key negotiation algorithm: Elliptic curve cryptography (ECC) key negotiation is employed. Both the device's temporary ECC key pair and the server's temporary ECC key pair are generated using the secp521r1 (also known as P-521) elliptic curve algorithm. Key negotiation algorithm: The shared key is generated using the Elliptic Curve Diffie-Hellman (ECDH) algorithm; Symmetric encryption algorithm: When encrypting the initial key using the negotiated shared key, the AES algorithm is used, with a key length of 256 bits; Hash Algorithm: The hash algorithm involved in ECC signature, key derivation function (KDF) and integrity verification uses SHA-256 or a stronger hash algorithm (such as SHA-384, SHA-512) to ensure that it matches the high security strength of the P-521 curve.

[0075] (3) General Algorithm In this invention, the signature algorithm for the issuance and verification of the certificate chain should match the above parameters, such as using SHA256withRSA or SHA256withECDSA.

[0076] It should be noted that the cryptographic algorithms and parameters listed above (such as RSA-2048, secp521r1, AES-256, etc.) are only one preferred embodiment of the present invention. Those skilled in the art should understand that, with the development of cryptographic technology, other algorithms and parameters with equivalent or higher security strength can be used to implement the present invention without departing from the core concept of the present invention, and these alternative solutions should all fall within the protection scope of the present invention.

[0077] S4. The device decrypts the initial key to obtain it and stores it securely, specifically including: S41. The device uses the long-term public key of the server extracted from the verified server terminal certificate to verify the server signature. S42. Decrypt the initial key data of the ciphertext: If Scheme A is used: The device uses the device's temporary RSA private key to decrypt the ciphertext initial key data to obtain the plaintext initial key; If Scheme B is used: The device uses the device's temporary ECC private key and the server's temporary ECC public key sent by the server to perform ECDH negotiation to obtain the same shared key, and then uses the shared key to decrypt the ciphertext initial key data to obtain the plaintext initial key. S43. After obtaining the plaintext initial key, the device securely stores the plaintext initial key in the hardware security module according to the device initial key data header, and returns a success response.

[0078] Step S4 enables the device to decrypt and obtain the initial key, which is then securely stored, completing the final step of remote key injection. The device verifies the signature using the server's long-term public key, and then decrypts the encrypted initial key data using a temporary RSA private key (Scheme A) or an ECDH shared key (Scheme B), ensuring the key's legitimate origin and lack of tampering. The device securely stores the plaintext initial key in a hardware security module to prevent unauthorized reading or leakage, thus completing the key injection process.

[0079] To further adapt to scenarios where the device's network environment is limited, this invention also provides an optimized verification path: when the device cannot directly access the designated certificate revocation list distribution point or online certificate status protocol responder due to network limitations, the server-side agent obtains the certificate status evidence and securely transmits it to the device through the initial key download process, specifically including: The initial key download request initiated by the device to the server includes a status evidence request identifier; After receiving and verifying the request, the server obtains the latest certificate revocation list and the peer's online certificate status protocol response from the specified certificate revocation list distribution point and online certificate status protocol responder. The server generates a composite response message containing the initial key ciphertext, the latest certificate revocation list, and the online certificate status protocol response. The server then digitally signs the composite response message using its long-term private key to generate a server response signature. The server then sends the composite response message and the server response signature to the device. The device receives the composite response message and the server response signature, and verifies the server response signature using the server long-term public key extracted from the verified server terminal certificate. After successful verification, the device obtains the initial key header, initial key ciphertext data, latest certificate revocation list, and online certificate status protocol response from the composite response message, and performs independent verification operations on the latter two, including: verifying the signature and validity period of the latest certificate revocation list, and verifying the digital signature and validity of the online certificate status protocol response.

[0080] This optimization method reduces the requirements for the network access capabilities of the device while ensuring that the verification is led by the device.

[0081] Example 2 Based on the same inventive concept, this application also provides an apparatus corresponding to the method in Embodiment 1, as detailed in Embodiment 2.

[0082] like Figure 1 As shown, this embodiment provides a remote key injection system based on asymmetric cryptography to implement the method described in Embodiment 1. The system includes a three-level Certificate Authority (CA) system, a device, a server, an OCSP responder, and a certificate revocation list distribution point. The three-tier CA system includes a device terminal certificate chain and a server certificate chain. The device terminal certificate chain consists of a device intermediate CA certificate and a device terminal certificate. The server certificate chain consists of a server intermediate CA certificate and a server terminal certificate. The offline root CA certificate or its public key serves as a pre-configured trust anchor for both communicating parties and is not included in the certificate chain transmitted during two-way authentication. Each of the device intermediate CA certificate, the device terminal certificate, the server intermediate CA certificate, and the server terminal certificate contains a strictly defined subject-distinguishable name and extended key usage extension. The device and the server are configured to perform peer-to-peer two-way authentication and mixed-state verification; and are configured to securely transmit the initial key based on a temporary key pair using an asymmetric cryptographic mechanism; and the device decrypts the initial key to obtain it and stores it securely. The OCSP responder is used to provide certificate status query services; The certificate revocation list distribution point is used to publish a certificate revocation list signed by the root CA; The two-way authentication and mixed-state verification include: The device initiates a connection to the server and sends the device's certificate chain; The server receives the device's certificate chain and verifies that the signature and extended key usage of the device's certificate chain conform to the client's authentication role. The server proactively obtains the latest certificate revocation list signed by the root CA from the preset address to verify the validity of the device's intermediate CA certificate. The server queries the OCSP status of the device's terminal certificate to complete the verification. The server binds to the specified device by comparing the identifier in the device's certificate subject distinguishable name with the server's preset device authorization list. The server sends its certificate chain to the device. The device receives the server's certificate chain and verifies that the signature and extended key usage of the server's certificate chain conform to the server's authentication role. The device actively obtains the latest certificate revocation list signed by the root CA from the preset address to verify the validity of the server's intermediate CA certificate. The device queries the OCSP status of the server's terminal certificate to complete the verification. The device binds to the specified server by comparing the identifier in the subject distinguishable name of the server's terminal certificate with the server's preset server authorization list.

[0083] Given that the system described in Embodiment 2 of the present invention is a corresponding device for implementing the method described in Embodiment 1 of the present invention, and that all technical solutions and means in the method embodiments are applicable to this system embodiment, please refer to the relevant description in Embodiment 1 for specific features, which will not be repeated here.

[0084] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A remote key injection method based on asymmetric cryptography, characterized in that: include: S1. Establish a three-tier CA system; The system includes a device terminal certificate chain and a server-side certificate chain; The device terminal certificate chain consists of an intermediate CA certificate on the device side and a device terminal certificate; The server certificate chain consists of a server intermediate CA certificate and a server terminal certificate; Offline root CA certificates or their public keys serve as a pre-defined trust anchor for both communicating parties and are not included in the certificate chain transmitted during two-way authentication. The device-side intermediate CA certificate, the device terminal certificate, the server-side intermediate CA certificate, and the server-side terminal certificate all contain strictly defined subject-distinguishable names and extended key usage extensions. S2, peer-to-peer two-way authentication and mixed-state verification, including: S21. The device initiates a connection to the server and sends the device's certificate chain. S22. The server receives the device's certificate chain and verifies that the signature and extended key usage of the device's certificate chain conform to the client's authentication role. The server actively obtains the latest certificate revocation list signed by the root CA from the preset address to verify the validity of the device's intermediate CA certificate. The server queries the OCSP status of the device's terminal certificate to complete the verification. The server binds to the specified device by comparing the identifier in the distinguishable name of the device's certificate subject with the server's preset device authorization list. S23. The server sends the server certificate chain to the device. S24. The device receives the server certificate chain and verifies that the signature and extended key usage of the server certificate chain conform to the server authentication role. The device actively obtains the latest certificate revocation list signed by the root CA from the preset address to verify the validity of the server intermediate CA certificate. The device queries the OCSP status of the server terminal certificate to complete the verification. The device binds to the specified server by comparing the identifier in the subject distinguishable name of the server terminal certificate with the server's preset server authorization list. S3. The two communicating parties securely transmit the initial key based on a temporary key pair using an asymmetric cryptographic mechanism; S4. The device decrypts the initial key and stores it securely.

2. The method according to claim 1, characterized in that: The extended key usage extension item of the device terminal certificate includes two key identifiers: client authentication and custom business OID. The extended key usage extension item of the server terminal certificate includes two key identifiers: server authentication and custom business OID.

3. The method according to claim 1, characterized in that: The public name field of the subject distinguishable name of the intermediate CA certificate of the device includes the client code and role identifier; The public name field of the subject distinguishable name of the server-side intermediate CA certificate includes the client code and role identifier; The public name field of the subject distinguishable name of the device terminal certificate contains a unique identifier for the device. The public name field of the subject distinguishable name of the server terminal certificate includes the server network identifier, which is a fully qualified domain name, and client code is structured and integrated on this basis.

4. The method according to claim 1, characterized in that: S3 specifically includes: S31. The device generates a temporary asymmetric key pair and sends an initial key download request to the server. The initial key download request includes initial key metadata, the device's temporary asymmetric public key, and a digital signature generated using the device's long-term private key. The digital signature covers the initial key metadata and the device's temporary asymmetric public key. S32. The server receives the initial key download request, uses the device terminal long-term public key extracted from the verified device terminal certificate to verify the digital signature, and after successful verification, obtains the initial key metadata and the device terminal temporary asymmetric public key. S33. The server generates an initial key based on the initial key metadata, and selects one of the following two paths, according to the scheme negotiated with the device, to construct the ciphertext for transmitting the initial key, i.e., the key block: Scheme A, RSA-based key transmission: The server uses the device's temporary RSA public key corresponding to the device's temporary asymmetric public key to encrypt the initial key, and the resulting ciphertext is used as the "ciphertext key data" for subsequent key block construction; Scheme B, ECC-based key negotiation: The server generates a server-side temporary ECC key pair, and uses the server-side temporary ECC private key and the device-side temporary asymmetric public key corresponding to the device-side temporary ECC public key to generate a shared key through the ECDH key negotiation algorithm. The initial key is then encrypted using this shared key, and the resulting ciphertext is used as the "ciphertext key data" for subsequent key block construction. At the same time, the server-side temporary ECC public key is encoded for embedding in the key block. S34. The server sends the key block to the device. The key block is an encapsulation structure that includes at least: a key data header, ciphertext key data, and a digital signature. In Scheme B, the server's temporary ECC public key is encoded in the key data header.

5. The method according to claim 4, characterized in that: In Scheme A, the server uses the RSA-OAEP padding scheme to encrypt the initial key using the device's temporary RSA public key; In Scheme B, the server uses the AES algorithm to encrypt the initial key using the shared key.

6. The method according to claim 4 or 5, characterized in that, The initial key ciphertext sent from the server to the device in S34 is data encapsulated using a key block structure, which includes at least: Key header: Contains metadata information of the initial key; Ciphertext key data: The initial ciphertext key generated by the server; Digital signature: generated by the server using its long-term private key to sign the concatenated data of the key data header and the ciphertext key data; If scheme B is selected, the server's temporary ECC public key is encoded and embedded in the key data header for transmission.

7. The method according to claim 4, characterized in that: S4 specifically includes: S41. The device uses the long-term public key of the server extracted from the verified server terminal certificate to verify the server signature. S42. Decrypt the initial key data of the ciphertext: If Scheme A is used: The device uses the device's temporary RSA private key to decrypt the ciphertext initial key data to obtain the plaintext initial key; If Scheme B is used: The device uses the device's temporary ECC private key and the server's temporary ECC public key sent by the server to perform ECDH negotiation to obtain the same shared key, and then uses the shared key to decrypt the ciphertext initial key data to obtain the plaintext initial key. S43. After obtaining the plaintext initial key, the device securely stores the plaintext initial key in the hardware security module according to the device initial key data header, and returns a success response.

8. The method according to claim 1, characterized in that, After the three-tier CA system is established, perform the following certificate and key pre-configuration and status verification configuration: (1) Pre-configure on the device side: device intermediate CA certificate, device terminal certificate and their corresponding long-term public-private pair, wherein the long-term private key of the device is securely generated and stored on the device side; Pre-configure the following on the server side: server-side intermediate CA certificate, server-side terminal certificate, and their corresponding long-term public-private key pairs on the server side; The offline root CA certificate or its public key serves as a pre-defined trust anchor shared by both communicating parties and is not included in the certificate chain transmitted during mutual authentication. (2) When the server and the device perform two-way authentication, the validity period of the OCSP response obtained from the other party is verified and the validity period does not exceed 5 minutes. (3) When verifying the status of the other party's intermediate CA certificate, both the device and the server obtain the latest certificate revocation list from the designated CRL distribution point of the corresponding intermediate CA certificate through the HTTPS protocol.

9. The method according to claim 1, characterized in that, When the device cannot directly access the designated certificate revocation list distribution point or online certificate status protocol responder due to network limitations, the server proxy obtains the certificate status evidence and securely transmits it to the device through the initial key download process, specifically including: S91. The initial key download request initiated by the device to the server includes a status evidence request identifier. S92. After receiving and verifying the request, the server obtains the latest certificate revocation list and the online certificate status protocol response of the peer certificate from the specified certificate revocation list distribution point and online certificate status protocol responder. S93. The server generates a composite response message containing the initial key ciphertext, the latest certificate revocation list, and the online certificate status protocol response, and digitally signs the composite response message using its server long-term private key to generate a server response signature; the server sends the composite response message and the server response signature together to the device. S94. The device receives the composite response message and the server response signature, and verifies the server response signature using the server long-term public key extracted from the verified server terminal certificate. After successful verification, the device obtains the initial key header, initial key ciphertext data, latest certificate revocation list, and online certificate status protocol response from the composite response message, and performs independent verification operations on the latter two, including: verifying the signature and validity period of the latest certificate revocation list, and verifying the digital signature and validity of the online certificate status protocol response.

10. A remote key injection system based on asymmetric cryptography, characterized in that: The method for implementing the method as described in any one of claims 1–9 includes a three-tier CA system, a device, a server, an OCSP responder, and a certificate revocation list distribution point; The three-tier CA system includes a device terminal certificate chain and a server-side certificate chain. The device terminal certificate chain consists of a device-side intermediate CA certificate and a device terminal certificate; the server-side certificate chain consists of a server-side intermediate CA certificate and a server-side terminal certificate; the offline root certificate or its public key serves as a pre-configured trust anchor for both communicating parties and is not included in the aforementioned transmitted certificate chain; wherein, the device-side intermediate CA certificate, the device terminal certificate, the server-side intermediate CA certificate, and the server-side terminal certificate all contain strictly defined subject-distinguishable names and extended key usage extensions; The device and the server are configured to perform peer-to-peer two-way authentication and mixed-state verification; and are configured to securely transmit the initial key based on a temporary key pair using an asymmetric cryptographic mechanism; and the device decrypts the initial key to obtain it and stores it securely. The OCSP responder is used to provide certificate status query services; The certificate revocation list distribution point is used to publish a certificate revocation list signed by the root CA; The two-way authentication and mixed-state verification include: The device initiates a connection to the server and sends the device's certificate chain; The server receives the device's certificate chain and verifies that the signature and extended key usage of the device's certificate chain conform to the client's authentication role. The server proactively obtains the latest certificate revocation list signed by the root CA from the preset address to verify the validity of the device's intermediate CA certificate. The server queries the OCSP status of the device's terminal certificate to complete the verification. The server binds to the specified device by comparing the identifier in the device's certificate subject distinguishable name with the server's preset device authorization list. The server sends its certificate chain to the device. The device receives the server's certificate chain and verifies that the signature and extended key usage of the server's certificate chain conform to the server's authentication role. The device actively obtains the latest certificate revocation list signed by the root CA from the preset address to verify the validity of the server's intermediate CA certificate. The device queries the OCSP status of the server's terminal certificate to complete the verification. The device binds to the specified server by comparing the identifier in the subject distinguishable name of the server's terminal certificate with the server's preset server authorization list.

Images