Algorithm management method and device of encryption library, computer device and vehicle

Abstract

This application relates to a method, apparatus, computer device, and vehicle for managing algorithms in an encryption library. The method includes: obtaining a default algorithm provider for the encryption library; obtaining a list of algorithms to be replaced corresponding to the default algorithm provider; determining a target algorithm from the list of algorithms to be replaced; replacing the target algorithm with a custom algorithm; and generating a list of replaced algorithms; wherein the list of replaced algorithms is used by the encryption library when it calls the default algorithm provider. This method improves the flexibility and accuracy of algorithm selection in the encryption library.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an algorithm management method, apparatus, computer equipment, and vehicle for an encryption library. Background Technology

[0002] With the development of computer technology, encryption library technology emerged. As the architecture of encryption libraries continues to evolve, a more modern and flexible provider architecture has gradually replaced the previous one. In a provider architecture, when a device is configured with an encryption library created by an independent developer or organization, or with a component that integrates that encryption library (a third-party component), the third-party component does not explicitly specify the library context and provider attributes during development. In traditional technologies, when a third-party component's encryption library makes an algorithm call, it will call the algorithm from the default algorithm provider or the algorithm from a loaded custom algorithm provider according to its built-in priority execution rules or strong correlation execution requirements. However, due to the limitations of the encryption library's built-in priority loading rules or strong correlation loading requirements, algorithms from custom providers may be overlooked, thus preventing the flexible implementation of a custom desired algorithm.

[0003] In one practical application scenario, this leads to the following situation: For highly encapsulated TLS (Transport Layer Security) or DTLS (Datagram Transport Layer Security) modules, the internal cryptographic libraries of third-party components have already completed the corresponding library context configuration and related default algorithms for TLS or DTLS operations. The feasibility of arbitrarily modifying their code is low. Therefore, during TLS or DTLS operations, the cryptographic libraries of third-party components cannot implement the interface with HSM (Hardware Security Module) according to a user-defined set of expected algorithms, thus transferring some operations to HSM. In other words, it is impossible to achieve flexible combination and use of cryptographic libraries and HSM under the architecture of cryptographic library providers. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer equipment, and vehicle for managing encryption library algorithms that can flexibly and accurately select encryption library algorithms, addressing the aforementioned technical problems.

[0005] Firstly, a method for managing the algorithm of an encryption library is provided, the method comprising: Obtain the default algorithm provider for the encryption library; Get the list of algorithms to be replaced for the default algorithm provider; The target algorithm is determined from the list of algorithms to be replaced, the target algorithm is replaced with a custom algorithm, and a list of replaced algorithms is generated. The list of replaced algorithms is used by the encryption library when the encryption library calls the default algorithm provider.

[0006] In a further technical solution, the default algorithm provider for the encryption library is obtained, including: Create a temporary library context in the cryptographic library, load the default algorithm provider in the temporary library context, and retrieve the default algorithm provider from the temporary library context; After generating the list of replaced algorithms, the method also includes: Release the default algorithm provider in the temporary library context.

[0007] In a further technical solution, a target algorithm is determined from the list of algorithms to be replaced, and a custom algorithm is used to replace the target algorithm, including: Iterate through the list of algorithms to be replaced; The target algorithm is determined from the list of algorithms to be replaced based on the preset algorithm name; Rewrite the storage address of the target algorithm to the storage address of the custom algorithm.

[0008] In a further technical solution, the storage address of the target algorithm is rewritten to the storage address of a custom algorithm, including: Obtain the function pointer table corresponding to the target algorithm; The target function is determined from the function pointer table based on the preset function identifier; Obtain the storage address of the target function and replace it with the storage address of the custom algorithm.

[0009] In a further technical solution, before rewriting the storage address of the target algorithm to the storage address of the custom algorithm, the method also includes: Determine whether the operating system has enabled access control rules; In response to the operating system not enabling access control rules, the access permission modification function is called to change the access attribute of the target algorithm's storage address to allow write operations.

[0010] In a further technical solution, the method also includes: In response to the operating system enabling access control rules, after adding additional access control rules to the operating system, the access permission modification function is called to modify the access attribute of the target algorithm's storage address to allow write operations; the additional access control rules are used to indicate that the access permission modification function can be called.

[0011] In a further technical solution, before replacing the target algorithm with a custom algorithm, the method also includes: Save the storage address of the target algorithm.

[0012] Secondly, an algorithm management device for an encryption library is provided, the device comprising: The provider acquisition module is used to obtain the default algorithm provider for the encryption library; The list retrieval module is used to retrieve the list of algorithms to be replaced corresponding to the default algorithm provider; The algorithm replacement module is used to determine the target algorithm from the list of algorithms to be replaced, replace the target algorithm with a custom algorithm, and generate a list of replaced algorithms. The list of replaced algorithms is used by the encryption library when it calls the default algorithm provider.

[0013] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method of any one of the first aspects.

[0014] Fourthly, a vehicle is provided, including an on-board terminal, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the method of any one of the first aspects.

[0015] The aforementioned algorithm management method, apparatus, computer equipment, and vehicle for the encryption library obtain the default algorithm provider of the encryption library and its corresponding list of algorithms to be replaced. Based on needs, a target algorithm is determined from the list of algorithms to be replaced, and then a custom algorithm is used to replace the target algorithm. This generates a list of replaced algorithms that includes both the default algorithms to be retained and the custom algorithms to be used. This list of replaced algorithms can serve as a new algorithm list for the default algorithm provider. When the default algorithm provider is invoked, the encryption library will invoke this list of replaced algorithms to implement the corresponding algorithm. Using this method, there is no need to repeatedly write a large amount of code. Focusing only on certain non-general algorithms that need to be changed, it is not restricted by the priority execution rules or strong correlation execution requirements inherent in the encryption library. It flexibly reuses certain general default algorithms that are to be retained, achieving a flexible combination of default and custom algorithms, thus improving the flexibility and accuracy of algorithm management in the encryption library. Attached Figure Description

[0016] Figure 1 This is a schematic diagram illustrating an example of algorithm loading in an encryption library when the algorithm management method of the encryption library involved in this application is not used in some application scenarios. Figure 2 This is a flowchart illustrating the algorithm management method of the encryption library in some embodiments; Figure 3 This is a sequence diagram illustrating the interaction between a software system and an HSM in some application examples. Figure 4 This is a schematic diagram illustrating the process of replacing the list of algorithms to be replaced to generate a list of replaced algorithms in some embodiments; Figure 5 This is a structural block diagram of the algorithm management device for the encryption library in some embodiments; Figure 6 These are internal structural diagrams of the computer device in some embodiments; Figure 7 This is an internal structural diagram of the computer device in some other embodiments; Figure 8 This is a schematic diagram of the vehicle structure in some embodiments. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0018] Before providing a detailed explanation of the algorithm management method for the encryption library involved in this application, let's first describe the practical application scenarios of the algorithm management method for the encryption library involved in this application.

[0019] Cryptographic libraries are software libraries created by independent developers or organizations to provide various encryption and decryption functions. They can run on various computing devices, including but not limited to servers, desktop computers, and mobile devices. Cryptographic libraries can provide software components that implement encryption algorithms, digital signatures, key management, and other functions. Developers can integrate them into applications to achieve secure data transmission and storage. Common cryptographic libraries include, but are not limited to, OpenSSL, Bouncy Castle, Libsodium, and Crypto++.

[0020] The shift from an engine architecture to a provider architecture represents a revolutionary change in cryptographic library architecture. The introduction of the provider architecture addresses the pain points of the engine architecture. For example, because all algorithms are tightly coupled in the engine architecture, it is difficult for developers to add their own proprietary algorithms without modifying the cryptographic library's source code. In other words, the implementation of the provider architecture transforms the cryptographic library from a static library into a dynamic and pluggable cryptographic framework.

[0021] Third-party components can be cryptographic libraries created by independent developers or organizations, or components configured with integrated cryptographic libraries. Because they are created by different independent developers or organizations, their source code is difficult to modify at will (no source code, violation of open source license, or being set to not be modified, etc.). Therefore, how to enable the cryptographic library to flexibly use our custom set of desired algorithms when certain cryptographic operation requests arrive without modifying their source code has become a problem to be solved.

[0022] In related technologies, while the current architecture of cryptographic library providers supports loading custom algorithm providers, the inherent limitations of ambiguous priority loading rules or strong correlation loading requirements lead to the following problems: refer to Figure 1 As shown, Figure 1 The diagram illustrates an example of algorithm loading for an encryption library in some application scenarios where the algorithm management method of the encryption library involved in this application is not used.

[0023] For example, in real-world applications that require interfacing with an HSM (Hardware Security Module), certain specific encryption operations need to be forwarded to the HSM for processing. In such cases, we expect the encryption library to load specific algorithms that we care about, such as digital signature algorithms and key management algorithms, so that encryption operations can be forwarded to the HSM at the relevant algorithm nodes. Otherwise, algorithms that we do not care about, such as decoder algorithms, can still use the corresponding decoder algorithms provided by the default algorithm provider of the encryption library.

[0024] In other words, the expectation is to enable the encryption library to load and execute a custom desired algorithm without modifying the source code of third-party callers such as the encryption library itself or components that integrate the encryption library; that is, without explicitly specifying the library context and provider attributes of the encryption library to be used. Figure 1 The example includes a series of algorithms from the list of decoder algorithms, the list of digital signature algorithms, and the list of key management algorithms.

[0025] However, when multiple providers exist within the same library context, and the third-party component does not explicitly specify the provider's attributes, the provider loaded first is usually invoked first according to the cryptographic library's built-in priority loading rules and strong dependency loading requirements. However, for certain algorithms, such as decoder algorithms, because their operation involves recursively selecting the decoder from the end to the beginning, the decoder algorithm from a later-loaded provider may be invoked first due to the different operating methods employed by different algorithms. Furthermore, cryptographic libraries also have strong dependency loading requirements, i.e., provider consistency constraints, requiring that multiple strongly related algorithm operations must be selected from the same provider.

[0026] This will lead to the following problems, see reference. Figure 1 As shown in (a) to (c): like Figure 1 (a) When a custom algorithm provider is loaded before the default algorithm provider in the same library context, the cryptographic library will call the decoder algorithm list in the default algorithm provider loaded later and the digital signature algorithm list in the custom algorithm provider loaded earlier, due to the priority loading rule. Due to the restriction of strong correlation loading requirements, the key management algorithm list in the default algorithm provider must also be called.

[0027] like Figure 1 (b) When a custom algorithm provider is loaded after the default algorithm provider in the same library context, if the cryptographic library does not provide a custom decoder algorithm list when calling the algorithm, the digital signature algorithm list and key management algorithm list in the custom algorithm provider loaded later will not be selected.

[0028] like Figure 1 (c) When a custom algorithm provider is loaded after the default algorithm provider in the same library context, even if the cryptographic library provides a custom decoder algorithm list when calling the algorithm, the digital signature algorithm list in the custom algorithm provider cannot be selected at the same time due to the priority loading rules and strong correlation loading requirements.

[0029] It is evident that regardless of the loading order, it is impossible to flexibly and accurately implement the desired set of custom content. That is, it is impossible to simultaneously select the decoder algorithm list in the default algorithm provider, the digital signature algorithm list in the defined algorithm provider, and the key management algorithm list.

[0030] Example 1 In some embodiments, to address the above-mentioned problems, such as Figure 2As shown, a method for managing the algorithm of an encryption library is provided. Taking the application of this method to a computer device as an example, the computer device may include, but is not limited to, terminal devices or server devices. The method for managing the algorithm of the encryption library includes the following steps: Step S202: Obtain the default algorithm provider for the encryption library.

[0031] The default algorithm provider of the encryption library is the core set of algorithms built into the encryption library. It provides basic encryption, decryption, signing, hashing and other algorithm implementation functions. It is the basis for other providers and is generally loaded in the global default context of the encryption library. When a third-party component initiates a call to a related algorithm, if the third-party component does not explicitly specify the library context and provider attributes of the encryption library to be used, the encryption library will call the loaded default algorithm provider (usually named "default provider") from the global default context to provide the corresponding algorithm.

[0032] Step S204: Obtain the list of algorithms to be replaced corresponding to the default algorithm provider.

[0033] The list of algorithms to be replaced refers to the list of algorithms maintained by the default algorithm provider that can cover the specified operation type. The list of algorithms to be replaced may include one or more algorithm functions or one or more sets of algorithm functions.

[0034] In this step, you can use methods such as calling a lookup function to search for a list of algorithms that can cover the specified operation type in the entire algorithm list maintained by the default algorithm provider, and use this list as the algorithm to be replaced.

[0035] Step S206: Determine the target algorithm from the list of algorithms to be replaced, replace the target algorithm with a custom algorithm, and generate a list of replaced algorithms. This list of replaced algorithms is used by the encryption library when it calls the default algorithm provider.

[0036] The target algorithm refers to the algorithm or list of algorithms that is to be replaced. The list of replaced algorithms refers to the list of algorithms after the target algorithm in the list of algorithms to be replaced has been completely or partially replaced. The list of replaced algorithms includes the default algorithm that is expected to be retained and the custom algorithm that is expected to be used.

[0037] In this step, the list of algorithms to be replaced can be traversed, and algorithms carrying the preset algorithm name can be selected as target algorithms. Then, a custom algorithm can be used to replace the target algorithm selected in the list of algorithms to be replaced, generating a list of replaced algorithms. The newly generated list of replaced algorithms includes both the default algorithm to be retained and the custom algorithm to be used. This newly generated list of replaced algorithms can then be used as the algorithm list of the default algorithm provider. When the cryptographic library loads the default algorithm provider in the global default context, it will load the newly generated list of replaced algorithms accordingly. When responding to calls from third-party components for relevant algorithms, the cryptographic library calls the default algorithm provider, and the newly generated list of replaced algorithms is invoked by the cryptographic library. Consequently, the cryptographic library performs algorithm implementation, function callbacks, and other operations based on the newly generated list of replaced algorithms.

[0038] The algorithm management method for the aforementioned encryption library obtains the default algorithm provider and its corresponding list of algorithms to be replaced. The target algorithm is then determined from the list as needed, and a custom algorithm is used to replace the target algorithm. This generates a list of replaced algorithms that includes both the default algorithms to be retained and the custom algorithms to be used. This replaced algorithm list can serve as a new algorithm list for the default algorithm provider. When the default algorithm provider is invoked, the encryption library will call this replaced algorithm list to implement the corresponding algorithm. This method eliminates the need for extensive rewriting; it allows focus on specific non-general algorithms that need to be changed. It is not restricted by the encryption library's built-in priority execution rules or strong correlation execution requirements, allowing for flexible reuse of certain general default algorithms to be retained. This enables flexible combinations of default and custom algorithms, improving the flexibility and accuracy of algorithm management in the encryption library.

[0039] Example 2 In some embodiments, obtaining the default algorithm provider of the cryptographic library includes: creating a temporary library context in the cryptographic library, loading the default algorithm provider in the temporary library context, and obtaining the default algorithm provider from the temporary library context; after generating the list of replaced algorithms, the method further includes: releasing the default algorithm provider in the temporary library context.

[0040] The default algorithm provider is usually passively loaded into the global default context of the cryptographic library when it is invoked. Although the process of replacing the algorithm in the algorithm list of the default algorithm provider can be performed in the global default context, in this embodiment, the default algorithm provider is obtained by creating a temporary library context in the cryptographic library and loading the default algorithm provider in the temporary library context. Then, subsequent operations such as searching for the algorithm to be replaced and replacing the target algorithm are performed on it. After generating the list of replaced algorithms, all the loaded resources in the temporary library context can be released.

[0041] Since the global default context is a shared resource, direct operations within it can pollute its state and potentially cause unpredictable side effects. Actively loading the default provider within the global default context may disrupt the cryptographic library's fallback mechanism, potentially preventing the system from automatically managing algorithm dependencies and hindering secure unloading due to global state constraints. Secondly, algorithm functions may be internally cached, and replacement operations in the global environment cannot guarantee the complete removal of all cached references, posing a risk of incomplete replacement. This embodiment avoids these problems. The temporary library context creates an independent sandbox environment, ensuring that algorithm lookup and replacement operations are completed within an isolated space. This avoids global state pollution, eliminates cache interference, and ultimately allows for the secure release of all resources after replacement, guaranteeing system stability and maintainability.

[0042] Example 3 In some embodiments, determining a target algorithm from a list of algorithms to be replaced and replacing the target algorithm with a custom algorithm includes: traversing the list of algorithms to be replaced; determining a target algorithm from the list of algorithms to be replaced according to a preset algorithm name; and rewriting the storage address of the target algorithm to the storage address of the custom algorithm.

[0043] In this embodiment, the list of algorithms to be replaced can be traversed, and each algorithm in the list can be checked to see if its name corresponds to a preset algorithm name. If it does, the checked algorithm can be used as the target algorithm; otherwise, the next algorithm in the list can be checked until all algorithms in the list have been checked. Then, after one or more target algorithms are determined, the storage address corresponding to each target algorithm can be queried from the list of algorithms to be replaced, and the storage address of the target algorithm can be rewritten to the storage address of the custom algorithm to be replaced. After this rewriting, when the target algorithm needs to be called based on its storage address, it actually points to the storage address of the custom algorithm. Thus, the custom algorithm can be called based on its storage address, thereby realizing the business logic specified in the custom algorithm.

[0044] Example 4 In some embodiments, rewriting the storage address of the target algorithm to the storage address of the custom algorithm includes: obtaining a function pointer table corresponding to the target algorithm; determining the target function from the function pointer table according to a preset function identifier; obtaining the storage address of the target function and replacing the storage address of the target function with the storage address of the custom algorithm.

[0045] In this embodiment, a function pointer table corresponding to the target algorithm can be further obtained. This function pointer table is essentially an array of function pointers, and its core content can include the function identifier (function ID) of each function and the specific storage address it points to. The target algorithm can be a set of algorithms, which may contain multiple function functions with different functions. By comparing the function IDs of each function in the function pointer table with preset function identifiers, the target function to be replaced can be further determined from the multiple function functions in the function pointer table. The target function is the function whose function ID is the same as or corresponds to the preset function identifier. Then, the storage address of the target function can be replaced with the storage address of the custom algorithm. In this embodiment, the custom algorithm can be a custom function algorithm.

[0046] This embodiment allows for the management of algorithms in smaller, more flexible units, based on functional functions. In other words, it not only supports the replacement of the entire target algorithm but also the flexible replacement of one or more functional functions contained in the target algorithm. This further improves the flexibility of encryption library algorithm management, allowing for the preservation of the desired content in existing default algorithms to a greater extent. It also reduces the amount of custom algorithm writing while flexibly implementing custom content.

[0047] Example 5 In some embodiments, before rewriting the storage address of the target algorithm to the storage address of the custom algorithm, the method further includes: determining whether the operating system has enabled access control rules; and in response to the operating system not enabling access control rules, calling an access permission modification function to modify the access attribute of the storage address of the target algorithm to allow write operations.

[0048] In this embodiment, since the algorithm functions of the built-in provider (default algorithm provider) of the encryption library may be set in the initialized constant static array during compilation, that is, they will be compiled into the read-only data segment, in order to modify the storage address of the target algorithm more accurately and smoothly, its access attribute can be modified first, changing it from read-only to write-allowed. Before modifying its access attribute, it can be determined whether the operating system has enabled access control rules. If the operating system has not enabled access control rules, the access attribute of the storage address of the target algorithm can be modified by calling the access permission modification function.

[0049] Example 6 In a further embodiment, the method further includes: in response to the operating system enabling access control rules, adding additional access control rules to the operating system, and then calling an access permission modification function to modify the access attribute of the target algorithm's storage address to allow write operations; wherein, the additional access control rules are used to indicate that the access permission modification function can be called.

[0050] In this embodiment, if the operating system has enabled access control rules, it means that the current operating system has set access restrictions. Therefore, it may have enabled a policy that prohibits calling access permission modification functions. In this case, in order to achieve a smooth replacement of the custom algorithm, additional access control rules can be added to the operating system first. These additional access control rules are used to indicate that calling access permission modification functions is allowed. After adding the additional access control rules, the operating system will allow the call to the access permission modification function, thereby enabling the call to the access permission modification function and thus enabling the modification of the access attributes of the target algorithm's storage address.

[0051] Example 7 In some embodiments, before replacing the target algorithm with a custom algorithm, the method further includes: saving the storage address of the target algorithm.

[0052] In this embodiment, users are also allowed to save the storage address of the target algorithm to be replaced in the default algorithm provider as needed. This embodiment enables the original default algorithm to be quickly restored when it is needed later, thereby enhancing the security and maintainability of the algorithm replacement process.

[0053] Example 8 The following section provides a detailed explanation of the algorithm management method of the encryption library involved in this application, using a practical application example.

[0054] The encryption library algorithm management method involved in this application can be applied to the following scenarios: when a computer device is configured with an encryption library created by an independent developer or organization, or is configured with a component (third-party component) that integrates the encryption library, and wants to interface with the HSM (Hardware Security Module) at certain specific stages of encryption algorithm execution to transfer some encryption operations to the HSM for processing.

[0055] You can refer to this. Figure 3 As shown, Figure 3The diagram illustrates the interaction sequence of a software system and an HSM in several application examples. For instance, using OpenSSL (Open Secure Sockets Layer Software Library) as an example, the software system can be configured with an encryption management unit, a memory management unit, an HSM adapter component, third-party components, and an encryption library integrated within those third-party components. Specifically, this may include the following steps: S0: Indicates the mapping relationship between the loading form key and keyid of the HSM adapter component; S1: Call OSSL_LIB_CTX_new to create a new temporary library context tmp_libctx; S2: Call OSSL_PROVIDER_load(tmp_libctx, "default") to load the default algorithm provider in the temporary library context; S3: The returned object of the default algorithm provider, tmp_default_prov; S4: Call OSSL_PROVIDER_query_operation to get the list of algorithms for the specified operation type to be covered, ossl_algorithm (list of algorithms to be replaced); S5: Traverse the algorithm list oss_algorithm and find the address of the target algorithm to be replaced based on the algorithm_names. S6: Call the mprotect function (VirtualProtect in Windows system) from the memory management unit to modify the access attribute of the memory address storing the target algorithm, changing it to read-write access, that is, allowing write operations; where mprotect and VirtualProtect are access permission modification functions corresponding to different operating systems; the memory management unit is used to manage memory access permissions and is the core module for implementing memory protection and memory resource scheduling.

[0056] S7: Save the implementation address of the original algorithm as needed; S8: Modify the memory address to point to the implementation address of the custom algorithm in the HSM adapter component; S9: Calling OSSL_PROVIDER_unload(tmp_default_prov) unloads the loaded default algorithm provider tmp_default_prov from the temporary library context tmp_libctx; S10: Call OSSL_LIB_CTX_free(tmp_libctx) to release the temporary library context tmp_libctx; S11: Initiate a cryptographic operation request; S12: Load the default algorithm provider with a list of replaced algorithms in the global default upper and lower libraries; S13: Call a custom algorithm from the HSM adapter component based on the list of replaced algorithms; S14: Based on a custom algorithm, find the corresponding keyid according to the formal key; S15: Pass the keyid and related data to the HSM to obtain the calculation result obtained by the HSM based on the keyid and related data.

[0057] In addition, more specifically, you can refer to Figure 4 As shown, Figure 4 The illustration shows some embodiments of replacing the list of algorithms to be replaced to generate a list of replaced algorithms. Figure 4 The example shown here demonstrates that by setting up an HSM adapter component (or plugin), the ECDSA signature function set in the default algorithm provider's digital signature algorithm list can be replaced with the HSM_ECDSA signature function set in the HSM adapter component, and the EC key management function set in the default algorithm provider's key management algorithm list can be replaced with the HSM_EC key management function set in the HSM adapter component.

[0058] More specifically, taking client private key protection based on EC (Elliptic Curve) type in mTLS as an example, during the mTLS handshake process, the client needs to use its private key to calculate a signature on the handshake data to prove its identity. At this point, we need to intercept the ECDSA (Elliptic Curve Digital Signature Algorithm) signature operation. Additionally, the mTLS two-way authentication process sets the client certificate and client key. The OpenSSL library uses the function X509_check_private_key to check if the client certificate and client key match. However, if the real key is replaced with the formal key, but the default EC key management function set is still used, a mismatch will occur. Therefore, a custom HSM_EC key management function set can be used to check if the client certificate and client formal key match, thus returning a "successful match" result to the upper layer, effectively "deceiving" the upper layer and facilitating subsequent procedures. In addition, when a signature needs to be calculated, the keyid can be found based on the formal key through a custom HSM_ECDSA signature function set. Finally, the HSM interface can be called based on the keyid to achieve the connection with HSM and obtain the calculation result based on HSM.

[0059] It can be seen that, through the algorithm management method of the encryption library involved in this application, some or all of the custom algorithms in the custom algorithm adaptation component can be integrated with the algorithms that are expected to be retained in the default algorithm provider, so as to realize the custom replacement and flexible combination of local algorithms in the default algorithm provider.

[0060] It should be understood that, although Figure 2 Flowchart and Figure 3 The steps in the sequence diagram are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order constraint on the execution of these steps, and they can be executed in other orders. Furthermore, Figure 2 and Figure 3 At least some of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0061] Example 9 In some embodiments, such as Figure 5As shown, an algorithm management device for an encryption library is provided, comprising: a provider acquisition module 510, a list acquisition module 520, and an algorithm replacement module 530, wherein: Provider acquisition module 510 is used to acquire the default algorithm provider of the encryption library; The list retrieval module 520 is used to retrieve the list of algorithms to be replaced corresponding to the default algorithm provider; The algorithm replacement module 530 is used to determine the target algorithm from the list of algorithms to be replaced, replace the target algorithm with a custom algorithm, and generate a list of replaced algorithms; wherein, the list of replaced algorithms is used by the encryption library when the encryption library calls the default algorithm provider.

[0062] In a further embodiment, the provider acquisition module 510 is also configured to create a temporary library context in the cryptographic library, load the default algorithm provider in the temporary library context, and obtain the default algorithm provider from the temporary library context; correspondingly, the provider acquisition module 510 is also configured to release the default algorithm provider in the temporary library context after generating the list of replaced algorithms.

[0063] In a further embodiment, the algorithm replacement module 530 is also used to traverse the list of algorithms to be replaced; determine the target algorithm from the list of algorithms to be replaced according to the preset algorithm name; and rewrite the storage address of the target algorithm to the storage address of the custom algorithm.

[0064] In a further embodiment, the algorithm replacement module 530 is also used to obtain the function pointer table corresponding to the target algorithm; determine the target function from the function pointer table according to the preset function identifier; obtain the storage address of the target function; and replace the storage address of the target function with the storage address of the custom algorithm.

[0065] In a further embodiment, the algorithm replacement module 530 is also used to determine whether the operating system has enabled access control rules; in response to the operating system not enabling access control rules, it calls the access permission modification function to modify the access attribute of the target algorithm's storage address to allow write operations.

[0066] In a further embodiment, the algorithm replacement module 530 is also configured to, in response to the operating system enabling access control rules, add additional access control rules to the operating system, and then call the access permission modification function to modify the access attribute of the target algorithm's storage address to allow write operations; wherein, the additional access control rules are used to indicate that the access permission modification function can be called.

[0067] In a further embodiment, the algorithm replacement module 530 is also used to save the storage address of the target algorithm.

[0068] Specific limitations regarding the algorithm management device for the encryption library can be found in the limitations on the algorithm management method for the encryption library above, and will not be repeated here. Each module in the aforementioned algorithm management device for the encryption library can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0069] Example 10 In some embodiments, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements an algorithm management method for an encryption library.

[0070] Example 11 In some embodiments, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements an algorithm management method for an encryption library. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0071] Those skilled in the art will understand that Figure 6 and Figure 7The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0072] Example 12 In some embodiments, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs the following steps: obtaining a default algorithm provider of an encryption library; obtaining a list of algorithms to be replaced corresponding to the default algorithm provider; determining a target algorithm from the list of algorithms to be replaced; replacing the target algorithm with a custom algorithm; and generating a list of replaced algorithms; wherein the list of replaced algorithms is used by the encryption library to call the default algorithm provider.

[0073] In a further embodiment, when the processor executes the computer program, it also performs the following steps: creating a temporary library context in the cryptographic library, loading a default algorithm provider in the temporary library context, and obtaining a default algorithm provider from the temporary library context; after generating a list of replaced algorithms, it also performs the following: releasing the default algorithm provider in the temporary library context.

[0074] In a further embodiment, the list of algorithms to be replaced is traversed; the target algorithm is determined from the list of algorithms to be replaced according to the preset algorithm name; and the storage address of the target algorithm is rewritten to the storage address of the custom algorithm.

[0075] In a further embodiment, a function pointer table corresponding to the target algorithm is obtained; a target function is determined from the function pointer table according to a preset function identifier; the storage address of the target function is obtained, and the storage address of the target function is replaced with the storage address of the custom algorithm.

[0076] In a further embodiment, it is determined whether the operating system has enabled access control rules; in response that the operating system has not enabled access control rules, the access permission modification function is called to modify the access attribute of the target algorithm's storage address to allow write operations.

[0077] In a further embodiment, in response to the operating system enabling access control rules, after adding additional access control rules to the operating system, the access permission modification function is called to modify the access attribute of the target algorithm's storage address to allow write operations; wherein, the additional access control rules are used to indicate that the access permission modification function is allowed to be called.

[0078] In a further embodiment, the storage address of the target algorithm is saved.

[0079] Example 13 In some embodiments, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program performs the following steps: obtaining a default algorithm provider of an encryption library; obtaining a list of algorithms to be replaced corresponding to the default algorithm provider; determining a target algorithm from the list of algorithms to be replaced, replacing the target algorithm with a custom algorithm, and generating a list of replaced algorithms; wherein the list of replaced algorithms is used by the encryption library when the default algorithm provider is invoked. A temporary library context is created in the encryption library, the default algorithm provider is loaded in the temporary library context, and the default algorithm provider is obtained from the temporary library context; after generating the list of replaced algorithms, the program further implements: releasing the default algorithm provider in the temporary library context.

[0080] In a further embodiment, when the computer program is executed by the processor, it also performs the following steps: traversing the list of algorithms to be replaced; determining the target algorithm from the list of algorithms to be replaced according to a preset algorithm name; and rewriting the storage address of the target algorithm to the storage address of the custom algorithm.

[0081] In a further embodiment, when the computer program is executed by the processor, it also performs the following steps: obtaining the function pointer table corresponding to the target algorithm; determining the target function from the function pointer table according to the preset function identifier; obtaining the storage address of the target function, and replacing the storage address of the target function with the storage address of the custom algorithm.

[0082] In a further embodiment, when the computer program is executed by the processor, it also performs the following steps: determining whether the operating system has enabled access control rules; in response to the operating system not enabling access control rules, calling the access permission modification function to modify the access attribute of the target algorithm's storage address to allow write operations.

[0083] In a further embodiment, when the computer program is executed by the processor, it also performs the following steps: in response to the operating system enabling access control rules, after adding additional access control rules to the operating system, it calls the access permission modification function to modify the access attribute of the target algorithm's storage address to allow write operations; wherein, the additional access control rules are used to indicate that the access permission modification function can be called.

[0084] In a further embodiment, when the computer program is executed by the processor, it also performs the following step: saving the storage address of the target algorithm.

[0085] Example 14 In some embodiments, reference Figure 8As shown, a vehicle can also be provided, which may include an on-board terminal. The on-board terminal stores a computer program, which, when executed by a processor, implements the encryption library algorithm management method in any of the above-described method embodiments. The vehicle may also include an HSM hardware device, and the on-board terminal can connect to the HSM hardware device via a hardware interface to interact with the HSM hardware device as needed, according to the encryption library algorithm management method in any of the above-described method embodiments. Those skilled in the art will understand that... Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the vehicle to which the present application is applied. Those skilled in the art will understand that a specific vehicle may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0086] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0087] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0088] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

[0089] It should be noted that, in the embodiments of this application, data related to user information or user data must be obtained and processed only after the user's authorization and consent. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

Claims

1. A method for managing the algorithm of an encryption library, characterized in that, The method includes: Obtain the default algorithm provider for the encryption library; Obtain the list of algorithms to be replaced corresponding to the default algorithm provider; A target algorithm is determined from the list of algorithms to be replaced, the target algorithm is replaced by a custom algorithm, and a list of replaced algorithms is generated; wherein, the list of replaced algorithms is used by the encryption library when the encryption library calls the default algorithm provider.

2. The method according to claim 1, characterized in that, The default algorithm provider for obtaining the encryption library includes: Create a temporary library context in the cryptographic library, load the default algorithm provider in the temporary library context, and obtain the default algorithm provider from the temporary library context; After generating the list of replaced algorithms, the method further includes: Release the default algorithm provider in the temporary library context.

3. The method according to claim 1, characterized in that, The step of determining the target algorithm from the list of algorithms to be replaced and replacing the target algorithm with a custom algorithm includes: Iterate through the list of algorithms to be replaced; The target algorithm is determined from the list of algorithms to be replaced based on the preset algorithm name; The storage address of the target algorithm is rewritten to the storage address of the custom algorithm.

4. The method according to claim 3, characterized in that, The step of rewriting the storage address of the target algorithm to the storage address of the custom algorithm includes: Obtain the function pointer table corresponding to the target algorithm; The target function is determined from the function pointer table according to the preset function identifier; Obtain the storage address of the target function and replace the storage address of the target function with the storage address of the custom algorithm.

5. The method according to claim 3, characterized in that, Before rewriting the storage address of the target algorithm to the storage address of the custom algorithm, the method further includes: Determine whether the operating system has enabled access control rules; In response to the operating system not enabling the access control rule, an access permission modification function is invoked to modify the access attribute of the target algorithm's storage address to allow write operations.

6. The method according to claim 5, characterized in that, The method further includes: In response to the operating system enabling the access control rule, after adding additional access control rules to the operating system, the access permission modification function is called to modify the access attribute of the target algorithm's storage address to allow write operations; wherein, the additional access control rule is used to indicate that the access permission modification function is allowed to be called.

7. The method according to claim 1, characterized in that, Before replacing the target algorithm with a custom algorithm, the method further includes: Save the storage address of the target algorithm.

8. An algorithm management device for an encryption library, characterized in that, The device includes: The provider acquisition module is used to obtain the default algorithm provider for the encryption library; The list retrieval module is used to retrieve the list of algorithms to be replaced corresponding to the default algorithm provider; An algorithm replacement module is used to determine a target algorithm from the list of algorithms to be replaced, replace the target algorithm with a custom algorithm, and generate a list of replaced algorithms; wherein, the list of replaced algorithms is used by the encryption library when the encryption library calls the default algorithm provider.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A vehicle, characterized in that, The method includes an in-vehicle terminal, on which a computer program is stored, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

Images