Private key calling processing method, device and equipment and readable storage medium

Abstract

The invention provides a private key calling processing method, device and equipment and a readable storage medium, a second private key generated by an encryption library is stored in an HSM, and a first private key of the same type generated according to the second private key is stored in electronic equipment, so that the encryption library can normally identify and read the private key, and the private key calling processing efficiency is improved. Meanwhile, the private key calling request of the encryption library is monitored, the response of the encryption library to the calling request is intercepted when the first private key is used for carrying out cryptographic calculation, the private key mapping relation is inquired to obtain the corresponding correct private key identifier, the corresponding correct private key identifier is sent to the HSM interface to obtain the correct response result, and on the basis that a source code of the encryption library does not need to be modified, the user experience is improved. According to the invention, rapid adaptation of the HSM and the encryption library is realized, effective protection on the private key is provided, and the private key is effectively prevented from being leaked.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to a method, apparatus, device, and readable storage medium for private key invocation processing. Background Art

[0002] The communication encryption between a client device and a server device is a basic security requirement. In the scenario of identity authentication for a communication connection, the client device or the server device will pre-store a digital certificate and a private key to indicate the identity of each device, and the private key, as sensitive information, needs to be securely stored.

[0003] In related technologies, for a device configured with an HSM (Hardware Security Module), the private key is usually stored in the HSM, and the cryptographic interface based on the private key identifier provided by the HSM is used to implement secure key operations. The private key identifier is used to uniquely identify a specific private key stored in the HSM. When the device sends a message to the HSM to perform cryptographic calculations, the private key identifier is carried in the message to indicate the private key used by the HSM for encryption, decryption, or other cryptographic operations.

[0004] However, when the device is configured with an encryption library created by an independent developer or organization, or configured with a component integrated with the encryption library, the encryption library uses the private key stored locally on the device as a passing parameter to perform various cryptographic calculations and security operations. If the private key is stored in the HSM, since the encryption library cannot recognize the private key identifier provided by the HSM, it is necessary to modify the source code of the encryption library to read the way of using the private key, which requires a high level of ability for developers. And in the case where the encryption library does not provide the source code or does not support source code modification, the above method cannot be used for private key protection. Summary of the Invention

[0005] In view of this, to solve the above technical problems, this application provides a method, apparatus, device, and readable storage medium for private key invocation processing.

[0006] Specifically, this application is implemented through the following technical solutions:

[0007] According to a first aspect of an embodiment of this application, a method for private key invocation processing is provided. The method is applied to an electronic device that stores a first private key, where the first private key is determined based on a second private key generated according to a pre-set encryption library, and the second private key is stored in a hardware security module. The method includes:

[0008] In response to a call request for the first private key by the encryption library, determine the private key identifier of the second private key corresponding to the first private key according to a pre-stored private key mapping relationship;

[0009] Determine the response result of the call request according to the private key identifier of the second private key corresponding to the first private key.

[0010] Optionally, after the encryption library generates the second private key, the method further includes:

[0011] Obtain the key parameters of the second private key according to the key type of the second private key;

[0012] Obtain a first private key with a different key entity of the same key type according to the same key parameters;

[0013] Store the second private key in the hardware security module, and replace the second private key stored in the electronic device with the first private key.

[0014] Optionally, the storing the second private key in the hardware security module includes:

[0015] Send a key storage request to the hardware security module, where the key storage request is used to request storing the second private key in the hardware security module;

[0016] After storing the second private key in the hardware security module, the method further includes:

[0017] In the case of receiving a response result indicating successful key storage, obtain the private key identifier of the second private key from the response result;

[0018] Store the correspondence between the private key identifier of the second private key and the first private key in the private key mapping relationship.

[0019] Optionally, the method further includes:

[0020] When it is monitored that the encryption library requests to call the target private key, obtain the private key mapping relationship;

[0021] Determine that the target private key is the first private key based on the existence of the target private key in the private key mapping relationship.

[0022] Optionally, the electronic device further stores a third private key, which is generated by the encryption library; the method further includes:

[0023] Determine that the target private key is the third private key based on the non-existence of the target private key in the private key mapping relationship;

[0024] In response to the call request of the encryption library for the third private key, determine the return result generated by the encryption library according to the third private key as the response result of the call request.

[0025] Optionally, the encryption library generates a digital certificate corresponding to the second private key; in response to the call request for detecting whether the first private key matches the digital certificate, determining the response result of the call request includes:

[0026] Determining the result indicating that the first private key matches the digital certificate as the response result.

[0027] Optionally, in response to the call request for performing cryptographic calculation processing based on the first private key, determining the response result of the call request includes:

[0028] Sending the information of the call request and the private key identifier of the second private key corresponding to the first private key to the hardware security module;

[0029] Determining the execution result returned by the hardware security module as the response result of the call request.

[0030] According to the second aspect of the embodiments of the present application, there is provided a private key call processing device applied to an electronic device. The electronic device stores a first private key, and the first private key is determined according to a second private key generated by a preset encryption library. The second private key is stored in a hardware security module; the device includes:

[0031] A private key identifier determination module, configured to, in response to a call request of the encryption library for the first private key, determine the private key identifier of the second private key corresponding to the first private key according to a pre-stored private key mapping relationship;

[0032] A response result acquisition module, configured to determine the response result of the call request according to the private key identifier of the second private key corresponding to the first private key.

[0033] Optionally, after the encryption library generates the second private key, the device further includes:

[0034] A key parameter acquisition module, configured to acquire key parameters of the second private key according to the key type of the second private key;

[0035] A first private key generation module, configured to acquire a first private key with different key entities of the same key type according to the same key parameters;

[0036] A private key storage module, configured to store the second private key in the hardware security module, and replace the second private key stored in the electronic device with the first private key.

[0037] Optionally, the private key storage module is specifically configured to:

[0038] Send a key storage request to the hardware security module, where the key storage request is used to request storing the second private key in the hardware security module;

[0039] After storing the second private key in the hardware security module, the device further includes:

[0040] In the case of receiving a response result indicating successful key storage, obtain the private key identifier of the second private key from the response result;

[0041] Store the correspondence between the private key identifier of the second private key and the first private key in the private key mapping relationship.

[0042] Optionally, the device further includes:

[0043] In the case of monitoring that the encryption library requests to call a target private key, obtain the private key mapping relationship; determine that the target private key is the first private key based on the existence of the target private key in the private key mapping relationship.

[0044] Optionally, the electronic device further stores a third private key, which is generated by the encryption library; the device further includes:

[0045] Determine that the target private key is the third private key based on the non - existence of the target private key in the private key mapping relationship; in response to the call request of the encryption library for the third private key, determine the return result generated by the encryption library based on the third private key as the response result of the call request.

[0046] Optionally, the encryption library generates a digital certificate corresponding to the second private key; in response to the call request for detecting whether the first private key matches the digital certificate, the response result acquisition module is specifically configured to: determine the result indicating that the first private key matches the digital certificate as the response result.

[0047] Optionally, the response result acquisition module is specifically configured to:

[0048] Send the information of the call request and the private key identifier of the second private key corresponding to the first private key to the hardware security module; determine the execution result returned by the hardware security module as the response result of the call request.

[0049] According to the third aspect of the embodiments of the present application, there is provided an electronic device, including: a memory and a processor; the memory is used to store a computer program; the processor is used to execute the above - mentioned private key call processing method by calling the computer program.

[0050] According to a fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the above-mentioned private key invocation processing method is implemented.

[0051] The technical solutions provided by the embodiments of the present application may include the following beneficial effects:

[0052] The technical solution provided by the embodiments of the present application stores the second private key generated by the encryption library in the HSM, providing effective protection for the private key and effectively preventing the leakage of the private key; the first private key of the same type generated according to the second private key is stored in the electronic device, enabling the encryption library to normally identify and read the private key. At the same time, by monitoring the private key invocation request of the encryption library, when using the first private key for cryptographic calculations, the response of the encryption library to the invocation request is intercepted, the corresponding correct private key identifier is obtained by querying the private key mapping relationship and sent to the HSM interface to obtain the correct response result. Without modifying the source code of the encryption library, the rapid adaptation of the HSM and the encryption library is achieved.

[0053] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. In addition, any one of the embodiments of the present application does not need to achieve all the above effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] The drawings herein are incorporated into the specification and constitute a part of this specification, showing embodiments consistent with the present application and used together with the specification to explain the principles of the present application.

[0055] Figure 1A is a schematic diagram of an authentication scenario based on TLS in the related art;

[0056] Figure 1B is a schematic diagram of a mutual authentication scenario based on mTLS in the related art;

[0057] Figure 2 is a flowchart of a private key invocation processing method shown in an exemplary embodiment of the present application;

[0058] Figure 3 is a flowchart of obtaining a first private key of the same type according to a second private key generated by an encryption library shown in an exemplary embodiment of the present application;

[0059] Figure 4 is a flowchart of determining whether an encryption library invokes a first private key shown in an exemplary embodiment of the present application;

[0060] Figure 5 is an interaction flowchart of a private key invocation processing method taking a client device in a mutual authentication scenario as an example shown in an exemplary embodiment of the present application;

[0061] Figure 6 It is a schematic structural diagram of a private key invocation processing device shown in an exemplary embodiment of the present application;

[0062] Figure 7 It is a hardware schematic diagram of an electronic device shown in an exemplary embodiment of the present application. Detailed implementation manners

[0063] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0064] The terms used in the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application. The singular forms "a", "said" and "the" used in the present application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0065] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present application, the first classification threshold may also be referred to as the second classification threshold, and similarly, the second classification threshold may also be referred to as the first classification threshold. Depending on the context, the word "if" as used herein may be interpreted as "when" or "while" or "in response to determining".

[0066] An encryption library is a software library created by independent developers or organizations for providing various encryption and decryption functions and can run on various computing devices, including servers, desktop computers, mobile devices, etc. The encryption library provides software components for implementing encryption algorithms, digital signatures, key management, etc. Developers can integrate them into application programs to achieve secure data transmission and storage. Common encryption libraries include OpenSSL, Bouncy Castle, Libsodium, Crypto++, etc.

[0067] Secure communication between a client device and a server device typically uses the TLS (Transport Layer Security) encryption protocol to ensure the security of the communication link. For communication scenarios with relatively high security requirements, mTLS (Mutual Transport Layer Security) is often used, that is, the client and server devices authenticate each other's identities.

[0068] In an authentication scenario based on TLS, as Figure 1A shown, the server device has a server certificate and a server private key. The server private key is paired with the server certificate and is used to encrypt and decrypt the transmitted data; the server certificate is issued by a trusted certificate authority (CA) and contains the public key of the server device, relevant information of the server device, and signatures, etc., and is used to be sent to the client device to enable the client device to verify the identity of the server device. As shown in the figure, the server device sends the server certificate to the client device; the client device verifies the server certificate, generates a random key after successful verification, encrypts it using the public key in the server certificate, and sends the encrypted key to the server; the server decrypts the encrypted key by calling the stored private key to complete the verification of the client device by the server device.

[0069] In a mutual authentication scenario, as shown in Figure 1B the figure, in addition to the server device, the client device also configures a client certificate and a client private key for the server to verify the identity of the client device. As shown in the figure, the server sends a digital certificate request to the client, asking the client to provide the client certificate, which can carry information such as the client public key and the digital signature generated based on the client private key; the client generates its own client certificate after receiving the certificate request and sends it to the server for the server to verify the client certificate.

[0070] In the above authentication scenarios, the client private key and the server private key are sensitive information that needs to be securely protected. In related technologies, the private key can be simply encrypted and stored locally on the device, but its security is relatively low and it cannot provide effective security protection for the private key; or, based on HSM, it can effectively provide the capabilities of secure key storage and secure operation, and most HSMs can also provide hardware acceleration capabilities. The above client private key or server private key can be securely stored in the HSM. When calling the private key, a cryptographic operation using the specified private key in the HSM is requested through the cryptographic interface provided by the HSM based on the private key identifier keyid.

[0071] For a device configured with the above encryption library or a component that has integrated the encryption library, in an authentication scenario, the encryption library is used to perform various cryptographic calculations based on the private key and paired certificate generated by the encryption library. When not using an HSM for secure storage of the private key, the private key generated by the encryption library is usually stored in a key store managed by the device's software. This software-managed key store can be a specified key management system, a secure database, an encrypted configuration file, or other secure storage media. The storage medium is set with corresponding access control and encryption protection to ensure the security of the private key, but it cannot provide the same level of physical security protection as an HSM.

[0072] After storing the private key that requires a higher level of security protection in the HSM, the device interacts with the HSM through the cryptographic interface based on the private key identifier keyid provided by the HSM. However, the encryption library cannot recognize the keyid provided by the HSM. Therefore, when using the HSM for private key protection and using the encryption library to implement cryptographic calculations, the source code for reading and using the private key in the encryption library needs to be modified. This operation requires a high level of ability from developers. If the encryption library does not provide the source code or modifying the source code violates the open source protocol regulations, it is impossible to implement using the HSM for private key protection and using the encryption library to implement cryptographic calculations.

[0073] To solve the above technical problems, the present application provides a private key call processing method, which can be executed by an electronic device having the private key, such as Figure 1A the server device shown, Figure 1B the client device or server device shown. The electronic device is configured with the above encryption library, which can be referred to as a third-party encryption library and supports storing the private key that requires security protection in the HSM. For the second private key generated by the encryption library, the present application pre-generates a corresponding first private key according to the second private key to be stored in the HSM, and then stores the second private key in the HSM, realizing the protection of the second private key by the HSM. The second private key is not stored in the electronic device, and the corresponding first private key is stored in the electronic device.

[0074] Based on the above storage method of the first private key and the second private key, as shown in Figure 2 when the encryption library in the electronic device performs cryptographic calculations or security operations based on the private key, the private key call processing method provided by the present application may include the following steps:

[0075] S201, in response to the call request of the encryption library for the first private key, determine the private key identifier of the second private key corresponding to the first private key according to the pre-stored private key mapping relationship;

[0076] Among them, the private key identifier refers to the identity identifier assigned by the hardware security module, i.e., HSM, to the second private key. HSM is a hardware device specifically designed for secure key management and cryptographic operations, with built-in security chips and security software to protect keys and sensitive data. When storing the second private key generated by the encryption library into the HSM, the HSM will automatically generate a unique private key identifier for this second private key using an internal secure random number generator. This private key identifier is used to reference and distinguish different private keys in the HSM. The process of generating the private key identifier is carried out inside the HSM, ensuring that the generated identifier has a high degree of uniqueness and security.

[0077] This private key identifier will be used for subsequent access and operations on this second private key in the HSM. Through the private key identifier, appropriate APIs or commands can be used to send requests to the HSM to perform cryptographic operations such as encryption, decryption, and signature using a specific private key.

[0078] The private key mapping relationship refers to the correspondence between the private key identifier of the second private key stored in the HSM and the first private key stored in the electronic device. The first private key generated based on the second private key corresponds one-to-one with the private key identifier of this second private key.

[0079] For the received request, when the process of the electronic device responding to the request involves operations that need to be processed by the encryption library, for example, cryptographic calculations based on the private key, the operation is sent to the encryption library for processing, and the electronic device can monitor the processing progress of the encryption library.

[0080] In the case where the electronic device monitors that the encryption library requests to call the private key stored locally in the electronic device, intercept the call request and determine whether the private key requested to be called by the encryption library is the aforementioned first private key. Function hooking can be implemented through methods such as hook or encryption library plugins to intercept the call request. For example, if the method function in the encryption library for generating a digital signature requests to call the private key, intercept the execution operation of this method function and determine whether the requested private key is the first private key.

[0081] The hook technology is a method of dynamically modifying the behavior of a function at runtime. It is usually achieved by modifying the function call instructions or jump tables in memory. This can insert custom code before or after the target function is executed without modifying the source code. When the target function is encrypted or obfuscated after compilation, the hook technology can still intercept and modify the behavior of the target function by operating on the function call instructions in memory without directly modifying the source code.

[0082] When the encryption library requests to call the first private key, the second private key generated by the encryption library corresponding to the first private key is actually stored in the HSM. Then the call request based on the first private key needs to be responded to using the second private key stored in the HSM to obtain the correct response result. Therefore, in the case where the encryption library requests to call the first private key, the pre-stored private key mapping relationship is obtained, and the private key identifier of the second private key corresponding to the first private key requested to be called by the encryption library in the private key mapping relationship is queried, so as to facilitate the subsequent cryptographic calculation in the HSM based on the private key identifier to generate the correct response result for the encryption library call.

[0083] S202: Determine a response result of the call request according to the private key identifier of the second private key corresponding to the first private key.

[0084] The encryption library includes method functions for implementing data decryption, digital signature, key management and other functions. Different method functions request to call the private key as an input parameter to obtain the corresponding results. The degree of use of the private key varies. Different methods can be used to determine the response result according to the different degrees of use of the private key in the method functions.

[0085] For the call request involving the private key to participate in the cryptographic calculation and obtain the result, since the private key calculation must be performed in a secure environment to prevent the private key from being leaked, a session message can be generated based on the private key identifier of the second private key corresponding to the first private key and sent to the HSM to request the HSM to perform the calculation based on the private key. For some scenarios where the private key is used for simple comparison and verification, the "spoofed" result can be directly returned without the need for processing by the HSM.

[0086] In the disclosed embodiment, the second private key generated by the encryption library is stored in the HSM, which provides effective protection for the private key and effectively prevents the leakage of the private key; the first private key of the same type generated according to the second private key is stored in the electronic device, so that the encryption library can normally identify and read the private key, and at the same time, by monitoring the private key call request of the encryption library, the response of the encryption library to the call request is temporarily interrupted when the first private key is used for cryptographic calculation, and the private key mapping relationship is queried to obtain the corresponding correct private key identifier and send it to the HSM interface to obtain the correct response result. Without modifying the source code of the encryption library, the rapid adaptation of the HSM and the encryption library is achieved, and the encryption library is allowed to use other private keys not protected by the HSM to perform correct cryptographic calculations.

[0087] In some embodiments, the first private key stored in the electronic device has the same key type and key parameters as the corresponding second private key, but different key entities. After the encryption library configured in the electronic device generates the second private key, Figure 3 As shown, the following steps can be used to generate the first key according to the second key generated by the encryption library, and the steps may include:

[0088] S301, obtain the key parameters of the second private key according to the key type of the second private key;

[0089] Key types can be divided into two types: symmetric keys and asymmetric keys. For symmetric keys, the same key is used for both encryption and decryption, and its encryption speed is relatively fast, which is suitable for encrypting a large amount of data; common symmetric encryption algorithms include AES, DES, etc. Asymmetric keys include public keys and private keys. The public key is used to encrypt data, and the private key is used to decrypt data; at the same time, the private key is also used to generate digital signatures, and the public key is used to verify digital signatures; common asymmetric encryption algorithms include RSA, DSA, ECC, etc. TLS or mTLS authentication usually uses asymmetric keys.

[0090] The key parameters of the second private key refer to the input parameters used to generate the second private key in the encryption algorithm. These parameters can include, but are not limited to, key length, random number seed, algorithm parameters, key usage, etc. The specific key parameter type depends on the key type of the second private key.

[0091] Different types of keys have different characteristics and uses. Therefore, to obtain the corresponding key parameters according to the key type, you can directly call the encryption library configured in the electronic device to identify the key type, and use the key parameter extraction method corresponding to the key type in the encryption library to obtain the key parameters of the second private key.

[0092] For example, assuming that the encryption library is the OpenSSL library, taking the second private key as an RSA type key as an example, the key parameters can include the key bit length and the number of additional prime numbers used when generating the RSA key. The key parameters can be obtained in the following way:

[0093] (1) Call the PEM_read_bio_PrivateKey method to read the pem format private key and store it in pkey;

[0094] (2) Call the EVP_PKEY_id method to obtain the key type value key_type of pkey;

[0095] (3) When the key_type value is EVP_PKEY_RSA, call the EVP_PKEY_get0_RSA method to obtain the RSA key inside pkey;

[0096] (4) Call the RSA_bits method to obtain the RSA key bit length and store it in bits_num;

[0097] (5) Call the RSA_get_multi_prime_extra_count method to obtain the number of extra prime numbers primes and store it in ex_primes, and set primes_num to 2 plus ex_primes.

[0098] S302, according to the same key parameters, obtain a first private key of the same key type with different key entities;

[0099] That is, generate a first private key of the same type using the same key parameters as the second private key, and the obtained first private key has a different key entity from the second private key.

[0100] After obtaining the key bit number bits_num and the number of extra prime numbers primes_num using the OpenSSL library as described above, the RSA_generate_multi_prime_key method can be called, and bits_num and primes_num can be passed as method input parameters to generate a first private key of the RSA type with the same key bit number and different key entities. Moreover, the PEM_write_bio_RSAPrivateKey method can also be called to convert the first private key into the pem string format.

[0101] S303, store the second private key in the hardware security module, and replace the second private key stored in the electronic device with the first private key.

[0102] After obtaining the key parameters of the second private key, the second private key can be stored in the HSM. If the second private key is stored in the electronic device, the second private key in the electronic device is replaced with the first private key of the same type.

[0103] Among them, a key storage request can be sent to the HSM, and the key storage request is used to request to store the second private key in the HSM. When receiving a response from the HSM to the key storage request, it indicates that the second private key is successfully stored.

[0104] In some embodiments, in the case of receiving a response result indicating successful key storage from the HSM, the following steps may further be included:

[0105] Obtain the private key identifier of the second private key from the response result;

[0106] Store the correspondence between the private key identifier of the second private key and the first private key in the private key mapping relationship.

[0107] That is, the electronic device sends a key storage request to the HSM. When the HSM stores the second private key locally, the random number generator inside the HSM will automatically assign a unique private key identifier to the second private key, encapsulate the private key identifier into the response result of the key storage request, and return the response result to the electronic device. The electronic device can obtain the private key identifier according to the response result. To ensure that the encryption library of the electronic device can accurately obtain the private key identifier when requesting to call the first private key of the same type, a correspondence between the private key identifier and the first private key of the same type is established, and the correspondence is updated to the private key mapping relationship.

[0108] In the embodiments of the present disclosure, by storing the second private key in the HSM and generating the first private key with the same key parameters and different key entities of the same type according to the second private key, and storing the first private key in the electronic device, the encryption library can normally identify and read the private key, and by storing the private key mapping relationship, it is realized that when the first private key is called, the second private key stored in the HSM can be accurately found to obtain the correct call response result.

[0109] In some embodiments, the electronic device stores the first private key and may also store a third private key. The third private key is a private key directly stored locally in the electronic device generated by the encryption library, and the third private key does not need to be protected by the HSM. As Figure 4 shown, before the foregoing step S201, the foregoing method may further include the following steps to determine whether the encryption library requests to call the first private key:

[0110] S401, when it is monitored that the encryption library requests to call the target private key, obtain the private key mapping relationship;

[0111] In an authentication scenario, when the electronic device includes multiple private keys, the peer device can inform the electronic device which private key should be used for identity authentication in a preset manner. The preset manner may include, but is not limited to, methods such as certificate exchange, agreed protocol, configuration information, or dynamic negotiation.

[0112] Among them, certificate exchange means that digital certificates containing public key information can be exchanged with each other when establishing a connection, obtain the identification information of the other party from the digital certificate provided by the other party, and then select a private key for identity authentication according to the representation information.

[0113] The agreed protocol means that the selection rules of the private key can be agreed in the communication protocol. For example, it can be agreed to find the private key used for authentication at a specific position in the certificate chain, or it can be agreed to specify a specific extension field in the certificate to select the private key.

[0114] Configuration information refers to the private key information that can be specified in a configuration file, environment variables, or other storage, so that when receiving an authentication request from the other party, the private key can be selected for authentication according to the configuration information.

[0115] Dynamic negotiation means that the private key to be used can be dynamically negotiated during the communication process. For example, the private key information to be used can be exchanged through a secure negotiation protocol, and the private key is selected for authentication according to the negotiation result.

[0116] When the electronic device detects a private key call request in the encryption library, it intercepts and interrupts the processing operation of the encryption library for the private key call request, and executes the operation of obtaining the pre-stored private key mapping relationship.

[0117] S402. Determine that the target private key is the first private key based on the existence of the target private key in the private key mapping relationship.

[0118] After obtaining the private key mapping relationship, match the target private key with each first private key in the private key mapping relationship; when there is a first private key that matches the target private key successfully, it is determined that the encryption library requests to call the first private key.

[0119] For the case where the target private key does not exist in the private key mapping relationship, it means that the target private key requested by the encryption library is a private key that does not require HSM protection, that is, the requested target private key is the third private key stored in the electronic device. Then, the above method may further include the following steps:

[0120] S403. Determine that the target private key is the third private key based on the non-existence of the target private key in the private key mapping relationship.

[0121] S404. In response to the call request of the encryption library for the third private key, determine the return result generated by the encryption library according to the third private key as the response result of the call request.

[0122] For the case where the encryption library requests to call the third private key that is not protected by HSM and is stored locally in the electronic device, the processing operation of the relevant cryptographic functions in the encryption library is restored. The encryption library can directly read the locally stored encryption library as an input parameter to obtain the corresponding function processing result as the response result of the call request.

[0123] In the embodiments of the present disclosure, by storing a private key mapping table, the correct calculation results of the cryptographic operations related to only the private keys protected by HSM are obtained through the private key mapping relationship, so that other private keys not protected by HSM in the program can be normally processed using the encryption library, thereby realizing the protection of the key private keys by HSM while not responding to the cryptographic operations of other private keys that do not require HSM protection.

[0124] In some embodiments, a hook point may be set in advance at the start call position of the cryptographic operation function in the encryption library that uses the private key as an input parameter. Function hooking is implemented through hook technology or a plugin of the encryption library, so as to intercept and pause the processing of the operation function after the hook point when the encryption library runs the cryptographic operation function, call and run the additional code inserted in the memory, that is, execute the private key call processing method described in the foregoing embodiments.

[0125] A plugin of the encryption library refers to a plugin that can replace the built-in default cryptographic operation functions of the encryption library. Its main function is to expand the functions of the encryption library and allow the use of custom cryptographic operation functions and hardware devices (such as encryption cards or security modules) to perform operations such as encryption, decryption, signature, and verification. For example, if the encryption library is OpenSSL, the OpenSSLEngine plugin can be used to implement function hooking within the encryption library.

[0126] In the embodiments of the present disclosure, by setting a hook point in advance at the start call position of the cryptographic operation function based on the private key in the encryption library, the behavior of the target function is modified using hook technology or an encryption library plugin, so as to correctly respond to the first private key call without modifying the source code of the encryption library, and achieve a fast adaptation of using the HSM to protect the private key and perform cryptographic operations in the encryption library.

[0127] In some embodiments, the encryption library generates a digital certificate corresponding to the second private key; the second private key is stored in the HSM. When a matching function in the encryption library requests to call the first private key to detect whether the first private key matches the digital certificate, the determination of the response result of the call request described in the foregoing step S202 can be achieved in the following manner:

[0128] Determine the result indicating that the first private key matches the digital certificate as the response result.

[0129] That is, in the embodiments of the present application, for the request to detect whether the first private key matches the digital certificate, intercept and pause the processing operation of the matching function in the encryption library. Without using the second private key in the HSM to verify with the digital certificate, based on the generated digital certificate being paired with the second private key, directly return a "spoofing" result, that is, determine the response result of the call request as "the first private key matches the digital certificate".

[0130] For example, if the encryption library is the OpenSSL library, which includes the function X509_check_private_key for determining whether the client certificate and the client private key match. When monitoring that this function requests to call the first private key, suspend using X509_check_private_key to detect the match, and directly return the response result of "the first private key matches the digital certificate".

[0131] In some embodiments, in response to the call request for performing cryptographic calculation processing according to the first private key, that is, the first private key requested to be called participates in a specific operation process, such as generating a digital signature, data encryption, etc., then determining the response result of the call request in step S202 described above may include the following steps:

[0132] Send the information of the call request and the private key identifier of the second private key corresponding to the first private key to the hardware security module;

[0133] Determine the execution result returned by the hardware security module as the response result of the call request.

[0134] That is, for a call request for performing cryptographic calculation using the first private key, encapsulate the private key identifier of the second private key corresponding to the first private key into a session message and send it to the HSM. The session request may also include information such as the type of the request and other relevant input parameters required for the request implementation, so as to facilitate the HSM to clarify the operation to be performed.

[0135] For example, for a digital signature request, it is necessary to send the data to be signed to the HSM so that the HSM can use the private key to perform a signature operation on it. At the same time, it is necessary to specify the signature algorithm to be used, such as RSA, DSA, ECDSA, etc., so that the HSM can perform the corresponding signature operation according to the specified algorithm. If it is a decryption processing request, it is necessary to send the data to be decrypted to the HSM and specify the decryption algorithm to be used, such as RSA, AES, etc., so that the HSM can use the private key to perform a decryption operation on it.

[0136] After receiving the session message, the HSM can perform the corresponding operation using the private key stored therein according to the private key identifier and the attached relevant information, and return the corresponding result to the electronic device. Thus, the electronic device determines the result returned by the HSM as the response result of the call request.

[0137] In the embodiments of the present application, by indicating the HSM to perform corresponding cryptographic calculations through a message carrying the private key identifier, the private key is operated in a secure environment, reducing the risk of private key leakage. Based on the advantage of the HSM having hardware optimization, performing cryptographic calculations in the HSM can improve the calculation performance. Based on the above method, the correct result of responding to the call of the first private key is obtained, realizing the adaptation between the HSM and the encryption library.

[0138] Next, to enable those skilled in the art to more clearly understand the private key call processing method provided by the present application, the method provided by the present application will be described by taking a client device configured with a third-party encryption library in a two-way authentication scenario as the execution subject.

[0139] Such asFigure 5 As shown in Figure 5 , the private key invocation processing method provided by this application includes a preprocessing stage and a private key invocation processing stage. Among them, the preprocessing stage is used to generate an alternative private key of the same type based on the critical private key that needs to be protected by the HSM generated by the encryption library, and store the alternative private key and the critical private key. This preprocessing stage can be executed once during deployment.

[0140] See Figure 5 As shown in Figure 5 , a private key preprocessing module and a private key forwarding engine are predefined. The private key preprocessing module is used to generate a first private key of the same type based on the second private key generated by the third-party encryption library. The private key forwarding engine is used to store the private key mapping relationship and intercept the call request to forward the result private key identifier. The private key processing module and the private key forwarding engine can be integrated into the client device or can be used as an interface API for the client device to call.

[0141] This embodiment involves the interaction between the client device, the server device and the HSM. The client device, as the execution entity, requests to establish an encrypted communication connection with the server device and stores the critical private key that needs to be protected by the HSM generated by the third-party encryption library in the HSM.

[0142] The preprocessing stage may include the following steps:

[0143] S501, input the critical private key key and the paired certificate cert of the client that can perform two-way authentication with the server into the private key preprocessing module in the client;

[0144] S502, the private key preprocessing module identifies the key type of the critical private key, and obtains the corresponding key parameters according to the key type, including but not limited to the type of asymmetric encryption algorithm used, the key bit length or the elliptic curve parameters, and then generates an alternative private key of the same type but with a different key entity using the same key parameters.

[0145] In the case where the third-party encryption library is OpenSSL, the functions of the third-party encryption library can be called to implement the acquisition of key parameters and the generation of alternative private keys. If the key_type value obtained by calling EVP_PKEY_id to get the key type of pkey is EVP_PKEY_EC, then the key type of the critical private key is the EC private key type, and the key parameters can be obtained in the following way:

[0146] ① Call the EVP_PKEY_get0_EC_KEY method to obtain the ec_key key inside pkey;

[0147] ② Call the EC_KEY_dup method to copy the ec_key key to the fake_ec_key key, so that fake_ec_key and ec_key have the same elliptic curve parameters;

[0148] ③ Call the EC_KEY_generate_key method to regenerate the key entity inside the fake_ec_key key.

[0149] ④ Call the PEM_write_bio_ECPKParameters method to convert the fake_ec_key key into a pem string format for output. This fake_ec_key key is the alternative private key corresponding to the critical private key.

[0150] S503, The private key preprocessing module requests the HSM to store the critical private key and obtains the private key identifier keyid required to access the critical private key.

[0151] S504, The private key preprocessing module sends the corresponding relationship between the alternative private key, the certificate paired with the critical private key, and the private key identifier keyid of the critical private key to the private key forwarding engine, so that the private key forwarding engine stores the private key mapping relationship.

[0152] S505, The private key preprocessing module returns the generated alternative private key to the client device, so that the client device replaces the critical private key already stored in the device with the alternative private key.

[0153] After the preprocessing stage is completed, based on the alternative private key and the private key mapping relationship stored in the client device, the private key call processing stage may include the following steps:

[0154] S506, Initialize the private key forwarding engine: The private key forwarding engine reads the stored private key mapping relationship and sets function hooks for the cryptographic operation functions in the third-party encryption library that use the critical private key as an input parameter in accordance with the pre-set function hooking method to change the execution behavior of the target function.

[0155] If the third-party encryption library configured in the client device is the OpenSSL library, the private key forwarding engine will hook the matching function in the third-party encryption library for judging the matching of the private key and the certificate, and the signature generation function for generating digital signatures using the private key.

[0156] The OpenSSL library provides upper-layer abstract interfaces to implement cryptographic operations. Inside the interfaces, specific cryptographic objects are set to complete the actual operation. For convenient and flexible expansion, the operation functions of all cryptographic objects in the OpenSSL library are provided in the form of function pointers, that is, callbacks.

[0157] The OpenSSL library allows developers to replace specific cryptographic object callback functions by writing OpenSSL Engine plugins to provide custom cryptographic operations. The OpenSSL library will call the cryptographic operation functions implemented in the custom OpenSSL Engine plugin to replace the default cryptographic operation functions in the third-party encryption library. Therefore, function hooking can be achieved by finding and replacing the callback functions of the cryptographic objects in the OpenSSL library, or by writing an OpenSSL Engine plugin according to the OpenSSL Engine specification. Neither method requires the introduction of a hook framework.

[0158] In the two-way authentication scenario, the client has a client certificate and a client private key. The X509_check_private_key function in the OpenSSL library is used to perform self-verification on whether the certificate and the private key match during the authentication process. Since the alternative private key is stored on the client device and the critical private key is stored in the HSM, if the matching fails based on the alternative private key stored on the client device, the corresponding callback function needs to be changed to return a "spoofed" result. Based on this, the X509_check_private_key function will ultimately call the pub_cmp callback function of the EVP_PKEY_ASN1_METHOD structure for matching judgment. The EVP_PKEY_ASN1_METHOD structure is mainly an abstraction of the ASN1 method, and different key types will have different implementations. Therefore, it is only necessary to replace the pub_cmp callback function of the specific key type, such as replacing the callback functions under the two key types of RSA and EC.

[0159] Moreover, according to the mTLS protocol specification, in the Certificate Verify message phase of two-way authentication, the client device needs to generate a digital signature of all the previous handshake data and send it to the server device to represent itself as the holder of the client certificate. Based on the alternative private key stored in the electronic device, a function hook is set for the callback function corresponding to the digital signature generation function in the third-party encryption library, so as to use the critical private key in the HSM for correct signature calculation. For the OpenSSL library, the sign callback function of the EVP_PKEY_METHOD structure will be called for signature calculation, and different key types will have different implementations. It is only necessary to replace the sign callback function of the specific key type.

[0160] S507, the client TLS component reads the client certificate corresponding to the critical private key and the alternative private key, and sets them into the TLS context environment;

[0161] S508. Before authentication, the hook function pre-registered by the private key forwarding engine intercepts the request for matching the client digital certificate and the client private key, queries the private key mapping table, and determines whether the requested client private key exists in the mapping table. If it exists, it returns a "spoofing" result, that is, directly returns the result indicating that "the client digital certificate and the client private key match". If it does not exist, it resumes the processing operation of the original matching function in the third-party encryption library and returns the function processing result.

[0162] S509. The TLS component of the client device starts the mTLS mutual authentication process and sends a ClientHello message to the server device.

[0163] S510. The server side replies with messages such as Server Hello, Certifacate, Server Key Exchange, Certficate Request, Server Done, etc.

[0164] S511. After the client reads the Certficate Request message, it enables the third-party encryption library to use the client private key to calculate the signature of the previous handshake data.

[0165] S512. The hook function pre-registered by the private key forwarding engine intercepts the signature calculation request, and then queries whether the called client private key exists in the mapping table. If it exists, it retrieves the keyid of the corresponding key key, and requests the HSM to perform the signature calculation using the key private key corresponding to the keyid, and obtains the calculation result returned by the HSM as the response result of the request. If it does not exist, it returns the processing result of the signature calculation function in the third-party encryption library as the response result of the request.

[0166] S513. Perform the subsequent handshake process. After the handshake is successful, perform secure encrypted communication between the client device and the server device.

[0167] In the embodiment of the present disclosure, by generating an alternative private key of the same type and storing it in the client device, and storing the key private key in the HSM, the third-party encryption library can normally identify and read the private key. At the same time, by defining the function of the private key forwarding engine to implement hooking all functions that use the private key in the third-party encryption library, when it is necessary to use the alternative private key for cryptographic calculations, query the private key mapping table to obtain the private key identifier of the corresponding key private key, and obtain the correct calculation result through the HSM interface based on the private key identifier. Without modifying the source code of the third-party encryption library, the rapid adaptation of the HSM and the third-party encryption library is achieved, and the purpose of protecting the private key and hardware deceleration is achieved.

[0168] Corresponding to the embodiment of the foregoing private key call processing method, see Figure 6As shown in the figure, the present application also provides an embodiment of a private key invocation processing device, which is applied to an electronic device preconfigured with the aforementioned encryption library; a first private key is stored on the electronic device, and the first private key is determined according to a second private key generated based on the encryption library, and the second private key is stored in a hardware security module; the device includes:

[0169] A private key identifier determination module 601, configured to, in response to a call request for the first private key by the encryption library, determine the private key identifier of the second private key corresponding to the first private key according to a pre-stored private key mapping relationship;

[0170] A response result acquisition module 602, configured to determine the response result of the call request according to the private key identifier of the second private key corresponding to the first private key.

[0171] In some embodiments, after the encryption library generates the second private key, the device further includes:

[0172] A key parameter acquisition module, configured to acquire the key parameters of the second private key according to the key type of the second private key;

[0173] A first private key generation module, configured to acquire first private keys with different key entities of the same key type according to the same key parameters;

[0174] A private key storage module, configured to store the second private key in the hardware security module, and replace the second private key stored in the electronic device with the first private key.

[0175] In some embodiments, the private key storage module is specifically configured to:

[0176] Send a key storage request to the hardware security module, where the key storage request is used to request storing the second private key in the hardware security module;

[0177] After storing the second private key in the hardware security module, the device further includes:

[0178] In the case of receiving a response result indicating successful key storage, acquire the private key identifier of the second private key from the response result;

[0179] Store the correspondence between the private key identifier of the second private key and the first private key in the private key mapping relationship.

[0180] In some embodiments, the device further includes:

[0181] When it is detected that the encryption library requests to call the target private key, obtain the private key mapping relationship; determine that the target private key is the first private key based on the existence of the target private key in the private key mapping relationship.

[0182] In some embodiments, the electronic device further stores a third private key, which is generated by the encryption library; the apparatus further includes:

[0183] Determine that the target private key is the third private key based on the non-existence of the target private key in the private key mapping relationship; in response to the call request of the encryption library for the third private key, determine the return result generated by the encryption library based on the third private key as the response result of the call request.

[0184] In some embodiments, the encryption library generates a digital certificate corresponding to the second private key; in response to the call request for detecting whether the first private key matches the digital certificate, the response result acquisition module is specifically configured to: determine the result indicating that the first private key matches the digital certificate as the response result.

[0185] In some embodiments, the response result acquisition module is specifically configured to:

[0186] Send the information of the call request and the private key identifier of the second private key corresponding to the first private key to the hardware security module; determine the execution result returned by the hardware security module as the response result of the call request.

[0187] The implementation processes of the functions and roles of each unit in the above apparatus are specifically described in detail in the implementation processes of the corresponding steps in the above method, and will not be repeated here.

[0188] For the apparatus embodiments, since they basically correspond to the method embodiments, the relevant parts can refer to the partial descriptions of the method embodiments. The apparatus embodiments described above are only illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of the present application. Those of ordinary skill in the art can understand and implement it without creative efforts.

[0189] The embodiments of the present application further provide an electronic device, and the structural schematic diagram of the electronic device is as Figure 7As shown, the electronic device 700 includes at least one processor 701, a memory 702, and a bus 703. At least one processor 701 is electrically connected to the memory 702. The memory 702 is configured to store at least one computer-executable instruction, and the processor 701 is configured to execute the at least one computer-executable instruction, thereby performing the steps of any private key invocation processing method provided in any one embodiment or any optional implementation manner of the present application.

[0190] Furthermore, the processor 701 can be an FPGA (Field-Programmable Gate Array), or other devices with logical processing capabilities, such as an MCU (Microcontroller Unit) or a CPU (Central Process Unit).

[0191] An embodiment of the present application also provides another readable storage medium storing a computer program, which is used to implement the steps of any private key invocation processing method provided in any one embodiment or any optional implementation manner of the present application when executed by a processor.

[0192] The readable storage medium provided by the embodiment of the present application includes, but is not limited to, any type of disk (including floppy disks, hard disks, optical disks, CD-ROMs, and magneto-optical disks), ROM (Read-Only Memory), RAM (Random Access Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory, magnetic cards, or optical cards. That is, the readable storage medium includes any medium that stores or transmits information in a form readable by a device (e.g., a computer).

[0193] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the acts recited in the claims can be performed in a different order and still achieve the desired result. Additionally, the processes depicted in the figures are not necessarily the specific order or sequential order shown to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0194] Although this specification contains many specific implementation details, these should not be construed as limiting the scope of any invention or the scope of what is claimed, but rather are primarily used to describe the features of specific embodiments of a particular invention. Certain features described in multiple embodiments within this specification may also be implemented in combination within a single embodiment. On the other hand, the various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. Additionally, although features may operate in certain combinations as described above and even be initially claimed as such, one or more features from a claimed combination may in some cases be removed from that combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination.

[0195] The above are only the preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this application shall be included within the scope of protection of this application.

Claims

1. A method for processing private key invocation, characterized in that Applied to an electronic device, the electronic device stores a first private key, the first private key is determined according to a second private key generated by a preset encryption library, and the second private key is stored in a hardware security module; the method includes: In response to a call request of the encryption library for the first private key, determine a private key identifier of the second private key corresponding to the first private key according to a pre-stored private key mapping relationship; Determine a response result of the call request according to the private key identifier of the second private key corresponding to the first private key.

2. The method according to claim 1, wherein After the encryption library generates the second private key, the method further includes: Obtain key parameters of the second private key according to the key type of the second private key; Obtain a first private key with different key entities of the same key type according to the same key parameters; Store the second private key into the hardware security module, and replace the second private key stored in the electronic device with the first private key.

3. The method according to claim 2, wherein The storing the second private key into the hardware security module includes: Send a key storage request to the hardware security module, where the key storage request is used to request storing the second private key into the hardware security module; After storing the second private key into the hardware security module, the method further includes: In the case of receiving a response result indicating successful key storage, obtain the private key identifier of the second private key from the response result; Store the correspondence between the private key identifier of the second private key and the first private key into the private key mapping relationship.

4. The method according to claim 1, wherein The method further includes: When it is monitored that the encryption library requests to call a target private key, obtain the private key mapping relationship; Determine that the target private key is the first private key based on the existence of the target private key in the private key mapping relationship.

5. The method according to claim 4, wherein The electronic device further stores a third private key, and the third private key is generated by the encryption library; the method further includes: Determine that the target private key is the third private key based on the non-existence of the target private key in the private key mapping relationship; In response to a call request of the encryption library for the third private key, determine the return result generated by the encryption library according to the third private key as the response result of the call request.

6. The method according to claim 1, wherein The encryption library generates a digital certificate corresponding to the second private key; In response to the call request being used to detect whether the first private key matches the digital certificate, the determining the response result of the call request includes: Determine a result indicating that the first private key matches the digital certificate as the response result.

7. The method according to claim 1, characterized in that, In response to the call request being used to perform cryptographic calculation processing according to the first private key, the determining the response result of the call request includes: Send the information of the call request and the private key identifier of the second private key corresponding to the first private key to the hardware security module; Determine the execution result returned by the hardware security module as the response result of the call request.

8. A private key invocation processing device, characterized in that, Applied to an electronic device, the electronic device stores a first private key, the first private key is determined according to a second private key generated by a preset encryption library, and the second private key is stored in a hardware security module; the apparatus includes: A private key identifier determination module, configured to, in response to a call request of the encryption library for the first private key, determine the private key identifier of the second private key corresponding to the first private key according to a pre-stored private key mapping relationship; A response result acquisition module, configured to determine the response result of the call request according to the private key identifier of the second private key corresponding to the first private key.

9. An electronic device, characterized in that, Comprising: A processor and a memory; The memory is configured to store a computer program; The processor is configured to execute the private key call processing method according to any one of claims 1-7 by calling the computer program.

10. A readable storage medium, on which a computer program is stored, characterized in that, When the program is executed by the processor, it implements the private key call processing method according to any one of claims 1-7.

Images