Algorithm management method and device of encryption library, computer device and storage medium

Abstract

This application relates to a method, apparatus, computer device, and storage medium for algorithm management in an encryption library. The method includes: obtaining a list of algorithms to be replaced from the default algorithm provider of the encryption library; generating a custom shadow algorithm list based on the list of algorithms to be replaced; associating the list of algorithms to be retained with the default algorithm provider to form an associated list of algorithms to be retained; and constructing a custom algorithm provider based on the shadow algorithm list and the associated list of algorithms to be retained. Specifically, after the custom algorithm provider is loaded by the encryption library, it returns the shadow algorithm list to the encryption library or retrieves the associated list of algorithms to be retained for the encryption library. This method enables the flexible and efficient implementation of a set of custom desired algorithms without increasing the development burden of the custom algorithm provider.

Description

Technical Field

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

[0002] With the development of computer technology, encryption library technology emerged. As the architecture of encryption libraries is constantly updated, the more modern and flexible provider architecture has gradually replaced the previous architecture. Under the provider architecture, when a device is configured with an encryption library created by an independent developer or organization, or with a component that integrates the encryption library (third-party component), the third-party component does not explicitly specify the library context and provider attributes of the encryption library to be used during development.

[0003] In traditional technologies, when a third-party component's encryption library makes an algorithm call, it will call either the algorithm from the default algorithm provider or the algorithm from the loaded custom algorithm provider according to its own priority execution rules or strong correlation execution requirements. When both the default algorithm provider and the custom algorithm provider are loaded simultaneously, due to the limitations of the encryption library's own priority loading rules or strong correlation loading requirements, the algorithm from the custom provider will be missed. However, if only the custom algorithm provider is loaded, it needs to provide all the relevant algorithms, which increases the compilation and development burden of the custom algorithm provider. Therefore, it is impossible to implement a set of custom desired algorithms without increasing the development burden of the custom algorithm provider.

[0004] 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 flexibly implement some operations to be handled by themselves and some operations to be transferred to HSM. In other words, it is not possible to achieve flexible combination and use of cryptographic libraries and HSM without increasing the development burden of custom algorithm providers. Summary of the Invention

[0005] Therefore, it is necessary to provide an algorithm management method, apparatus, computer equipment, and storage medium that can implement a set of custom desired algorithm encryption libraries without increasing the development burden on custom algorithm providers, in order to address the above-mentioned technical problems.

[0006] Firstly, a method for managing the algorithm of an encryption library is provided, the method comprising: Get the list of alternative algorithms for the default algorithm provider of the encryption library; Generate a custom list of shadow algorithms based on the list of algorithms to be replaced; The list of algorithms to be retained associated with the default algorithm provider is used to form an associated list of algorithms to be retained. A custom algorithm provider is constructed based on the shadow algorithm list and the associated list of algorithms to be retained. After the custom algorithm provider is loaded by the cryptographic library, it returns the shadow algorithm list to the cryptographic library or retrieves the associated list of algorithms to be retained for the cryptographic library.

[0007] In a further technical solution, a list of alternative algorithms to be obtained from the default algorithm provider of the encryption library is included, including: Create a global proxy library context, load the default algorithm provider in the global proxy library context, and obtain the default proxy provider; Based on the proxy default provider, query the list of algorithms to be replaced by the default algorithm provider.

[0008] In a further technical solution, the list of algorithms to be retained from the default algorithm provider includes: By using algorithm reference pointers, the list of algorithms to be retained from the default algorithm provider queried based on the proxy default provider is associated with the custom algorithm provider to form an associated list of algorithms to be retained.

[0009] In a further technical solution, a custom shadow algorithm list is generated based on the list of algorithms to be replaced, including: Determine the target algorithm to be replaced from the list of algorithms to be replaced; Replace the target algorithm with a custom algorithm to generate a list of shadow algorithms.

[0010] In a further technical solution, the target algorithm is replaced with a custom algorithm, including: Copy the list of algorithms to be replaced to a custom memory region; where the custom memory region is a region where write operations are allowed. In the custom memory region, modify the storage address of the target algorithm to the storage address of the custom algorithm.

[0011] In a further technical solution, after generating a custom shadow algorithm list based on the list of algorithms to be replaced, the method also includes: Retrieve the type identifier of the algorithm type corresponding to the shadow algorithm list; Construct a mapping table between type identifiers and the list of shadow algorithms; Returns a list of shadow algorithms for the cryptographic library or retrieves an associated list of algorithms to be retained for the cryptographic library, including: The mapping table can be used to return a list of shadow algorithms for the encryption library or to retrieve a list of associated algorithms to be retained for the encryption library.

[0012] In a further technical solution, a list of shadow algorithms is returned to the encryption library based on the mapping table, or a list of associated algorithms to be retained is retrieved for the encryption library, including: In response to receiving an algorithm call request from the cryptographic library; wherein the algorithm call request carries a target type identifier of the target algorithm type to be used; Determine if a target type identifier exists in the mapping table as a corresponding target shadow algorithm list; If so, the encryption library returns a list of target shadow algorithms; If not, the corresponding list of target algorithms to be retained is retrieved from the default algorithm provider based on the target type identifier and returned to the encryption library.

[0013] Secondly, an algorithm management device for an encryption library is provided, the device comprising: The list retrieval module is used to retrieve a list of algorithms to be replaced by the default algorithm provider of the encryption library; The list replacement module is used to generate a custom list of shadow algorithms based on the list of algorithms to be replaced. The custom provider building module is used to associate the default algorithm provider's list of algorithms to be retained to form an associated list of algorithms to be retained, and to build a custom algorithm provider based on the shadow algorithm list and the associated list of algorithms to be retained. After the custom algorithm provider is loaded by the cryptographic library, it returns the shadow algorithm list to the cryptographic library or retrieves the associated list of algorithms to be retained for the cryptographic library.

[0014] 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 any of the methods in the first aspect.

[0015] 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 any of the methods in the first aspect.

[0016] The aforementioned algorithm management method, apparatus, computer equipment, and storage medium for the encryption library replace the list of algorithms to be replaced in the default algorithm provider of the encryption library to be modified with a custom shadow algorithm list, and associate the list of algorithms to be retained in the default algorithm provider to be retained with the custom algorithm provider. This custom algorithm provider, constructed by including the shadow algorithm list and referencing the associated list of algorithms to be retained, can, after being loaded by the encryption library, either return a custom shadow algorithm list containing the desired algorithm to the encryption library, or retrieve the associated list of algorithms to be retained from the default algorithm provider. In this way, the encryption library only needs to load this custom algorithm provider to achieve the reuse of the desired default algorithm and flexible compatibility with custom algorithms, thereby enabling the flexible and efficient implementation of a custom desired algorithm without increasing the development burden of the custom algorithm provider. Attached Figure Description

[0017] 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 how a complete list of algorithms corresponding to a custom algorithm provider is constructed 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 These are internal structural diagrams of the computer device in some embodiments; Figure 8 This is a schematic diagram of the vehicle structure in some embodiments. Detailed Implementation

[0018] 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.

[0019] 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.

[0020] 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++.

[0021] 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.

[0022] Third-party components can be cryptographic libraries created by independent developers or organizations, or component implementations configured with integrated cryptographic libraries. Since 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.

[0023] 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.

[0024] 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.

[0025] In other words, the goal is to enable the encryption library to load and execute a custom desired algorithm without modifying the source code of the encryption library or components that integrate the encryption library. For example, 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.

[0026] However, if multiple providers exist within the same library context, and the third-party caller 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 back, meaning that different algorithms employ different working methods, the decoder algorithm from the later-loaded provider may be invoked first. 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] It is evident that as long as both the custom algorithm provider and the default algorithm provider are not explicitly loaded in the global default library context of the cryptographic library, the desired set of custom content cannot be flexibly and accurately implemented regardless of the loading order. 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.

[0031] Faced with this situation, developers can only improve their custom algorithm provider by configuring and compiling it to include all the desired relevant algorithms. Then, they can ensure that this custom provider is the only one loaded in the global default library context, thus abandoning the use of the system's built-in default algorithm provider. However, the desired combination of all relevant algorithms varies depending on business requirements. Therefore, developing a custom algorithm provider requires a significant amount of work and time, while the algorithms in the default algorithm provider provided by third-party libraries (cryptography libraries) cannot be utilized, leading to increased development burden and low resource reuse.

[0032] Example 1 The encryption library algorithm management method provided in this application is intended to solve the above-mentioned problems, such as... Figure 2 As 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 list of algorithms to be replaced for the default algorithm provider of the encryption library; The default algorithm provider of the cryptographic library is the core set of algorithms built into the library, providing basic encryption / decryption, signing, hashing, and other algorithm functions. It is the foundation upon which other providers depend and is generally loaded into the global default library context. When a third-party caller initiates a call to a related algorithm, if the caller does not explicitly specify the required library context and provider attributes, the cryptographic library will call the loaded default algorithm provider (usually named "default provider") from the global default library context to provide the corresponding algorithm. However, if a custom algorithm provider is explicitly loaded into the global default library context without specifying a fallback attribute, then the system-built-in default algorithm provider will not be automatically loaded into the global default library context subsequently; instead, all algorithms from the loaded custom algorithm provider will be used directly.

[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, by calling a lookup function or other means, the algorithm to be replaced can be found in the list of all algorithms maintained by the default algorithm provider based on the type identifier of the algorithm type that the user expects to replace.

[0035] Step S204: Generate a custom shadow algorithm list based on the list of algorithms to be replaced; The shadow algorithm list refers to a list of algorithms that contain user-defined algorithms. The type identifier of the corresponding algorithm type can be the same as that of the algorithm list to be replaced. However, the content, such as the algorithm function or its storage address, has been replaced with the user-defined one.

[0036] In this step, all or part of the algorithm functions in the algorithm list to be replaced can be replaced to obtain the shadow algorithm list.

[0037] Step S206: Associate the list of algorithms to be retained with the default algorithm provider to form an associated list of algorithms to be retained, and construct a custom algorithm provider based on the shadow algorithm list and the associated list of algorithms to be retained; wherein, after the custom algorithm provider is loaded by the encryption library, it returns the shadow algorithm list to the encryption library or retrieves the associated list of algorithms to be retained for the encryption library.

[0038] The list of algorithms to be retained refers to the list of reusable algorithms that are expected to be retained from the algorithm list maintained by the default algorithm provider. For example, the list of decoding algorithms. The list of algorithms to be retained may include one or more algorithm functions or one or more sets of algorithm functions.

[0039] In this step, the list of algorithms suitable for reuse and expected to be retained from the default algorithm provider can be associated with the custom algorithm provider by reference. In this way, when the custom algorithm provider is loaded by the encryption library and requested to be called, the encryption library can be triggered to call the algorithm based on the business request of the third-party caller. Then, the shadow algorithm list can be directly returned to the encryption library according to the content of the algorithm call request, or the list of algorithms to be retained from the associated default algorithm provider can be called and the list of algorithms to be retained can be returned to the encryption library.

[0040] In the aforementioned algorithm management method for the encryption library, the list of algorithms to be replaced in the default algorithm provider of the encryption library to be modified is replaced with a custom shadow algorithm list. The list of algorithms to be retained in the default algorithm provider to be retained is associated with the custom algorithm provider. This custom algorithm provider, constructed by including the shadow algorithm list and referencing the associated list of algorithms to be retained, can, after being loaded by the encryption library, either return a custom shadow algorithm list containing the desired algorithm to the encryption library, or retrieve the associated list of algorithms to be retained from the default algorithm provider. In this way, the encryption library only needs to load this custom algorithm provider to achieve the reuse of the desired default algorithm and flexible compatibility with custom algorithms. This allows for the flexible and efficient implementation of a custom desired algorithm without increasing the development burden of the custom algorithm provider.

[0041] Example 2 In some embodiments, obtaining the list of algorithms to be replaced by the default algorithm provider of the encryption library includes: creating a global proxy library context, loading the default algorithm provider in the global proxy library context to obtain the proxy default provider; and querying the list of algorithms to be replaced by the default algorithm provider based on the proxy default provider.

[0042] The default algorithm provider is usually passively loaded into the global default library context of the cryptographic library when it is invoked. However, in this embodiment, in order to ensure that only the custom algorithm provider is loaded in the global default library context, instead of loading both at the same time, a global proxy library context independent of the global default library context can be created in the cryptographic library, and the default algorithm provider can be actively loaded into the global proxy library context to obtain the proxy default provider. Then, based on the proxy default provider, the query and retrieval of the list of algorithms to be replaced by the default algorithm provider can be implemented.

[0043] In this embodiment, by creating a global proxy library context independent of the global default library context and actively loading the default algorithm provider into the global proxy library context, the isolation and independent querying and invocation of the default algorithm provider are achieved. This avoids the conflicts and interference caused by the coexistence of custom algorithm providers and default algorithm providers in the same context, thereby ensuring the controllability of the replacement process.

[0044] Example 3 Furthermore, by utilizing the proxy default provider created in Example 2, it is also possible to associate the list of algorithms to be retained by the default algorithm provider and to subsequently invoke them.

[0045] In this embodiment, associating the list of algorithms to be retained by the default algorithm provider includes: associating the list of algorithms to be retained by the default algorithm provider queried based on the proxy default provider with the custom algorithm provider in the form of algorithm reference pointers.

[0046] In this embodiment, a query operation can be performed in the global proxy library context through a proxy default provider to obtain the list of algorithms to be retained from the default algorithm provider. This list can then be associated with a custom algorithm provider as a reference pointer. This allows the custom algorithm provider, when loaded by the encryption library and invoked, to reference the list of algorithms to be retained corresponding to the default algorithm provider through the proxy default provider, and forward this referenced list to the encryption library. This enables the invocation of the proxy-based list of algorithms to be retained and the implementation of the algorithms within that list.

[0047] In this embodiment, a clear indirect reference path is constructed by querying and retrieving the list of algorithms to be retained based on the default proxy provider, and then associating it with the custom algorithm provider as a reference pointer. This allows the custom algorithm provider to securely and accurately call the algorithm functions in the list of algorithms to be retained from the default algorithm provider it intends to use through the proxy mechanism, and directly obtain the results of the calls from the default proxy provider through the public interface, and then forward them to the cryptographic library, thereby realizing the reference to the list of algorithms to be retained. The proxy mechanism effectively avoids loading conflicts and dependency coupling between the default algorithm provider and the custom algorithm provider, improving the stability of algorithm management.

[0048] Example 4 In some embodiments, generating a custom shadow algorithm list based on the list of algorithms to be replaced includes: determining the target algorithm to be replaced from the list of algorithms to be replaced; replacing the target algorithm with a custom algorithm to generate the shadow algorithm list.

[0049] This process involves iterating through the list of algorithms to be replaced, checking each algorithm's name against a preset algorithm name. If a match is found, the matched algorithm is selected as the target algorithm; otherwise, the process continues until all algorithms in the list have been checked. Then, after identifying one or more target algorithms, they are replaced with custom algorithms, while the remaining algorithms retain their original default values ​​from the list. This creates a shadow algorithm list containing both custom and default algorithms.

[0050] In this embodiment, by further filtering the target algorithms to be replaced from the list of algorithms to be replaced, it is possible to combine custom algorithms with default algorithms more flexibly, thereby further improving the reusability of default algorithms in the default algorithm provider, further reducing the development burden of custom algorithm providers, and improving the refinement and flexibility of encryption library algorithm management.

[0051] Example 5 In some embodiments, replacing the target algorithm with a custom algorithm may specifically include: copying the list of algorithms to be replaced to a custom memory region; wherein the custom memory region is a region that allows write operations; and modifying the storage address of the target algorithm to the storage address of the custom algorithm in the custom memory region.

[0052] In this embodiment, the list of algorithms to be replaced can be copied to a custom memory region. For example, a deep copy can be used, that is, all objects and their hierarchical data in the list of algorithms to be replaced can be recursively copied to a custom memory region that allows write operations (e.g., dynamically allocated read-write heap space). In this custom memory region, the pointers indicating the storage addresses of the target algorithms in the list of algorithms to be replaced can be written according to custom requirements. Therefore, without being restricted by the default algorithm provider's permission to modify attribute parameters, the storage address of the target algorithm in the list of algorithms to be replaced can be successfully modified to the storage address of the custom algorithm to be implemented.

[0053] Example 6 In some embodiments, after generating a custom shadow algorithm list based on the list of algorithms to be replaced, the method further includes: obtaining a type identifier for the algorithm type corresponding to the shadow algorithm list; constructing a mapping table between the type identifier and the shadow algorithm list; returning the shadow algorithm list to the encryption library or retrieving the associated list of algorithms to be retained for the encryption library, including: returning the shadow algorithm list to the encryption library or retrieving the associated list of algorithms to be retained for the encryption library based on the mapping table.

[0054] In this embodiment, the type identifier of the algorithm type corresponding to the shadow algorithm list is, that is, the type identifier of the algorithm type represented by the algorithm list to be replaced corresponding to the shadow algorithm list. For example, it can be identified as Operation ID, etc.

[0055] In this embodiment, an algorithm query standard is constructed by establishing a mapping relationship between algorithm type identifiers and shadow algorithm lists. This enables the cryptographic library to quickly and accurately determine the shadow algorithm list corresponding to the requested type identifier based on the pre-constructed mapping relationship table when requesting algorithms of a specific algorithm type from a custom algorithm provider. This achieves precise and efficient distribution and management of algorithms.

[0056] Example 7 In a further embodiment based on Embodiment Six, returning a list of shadow algorithms to the encryption library or retrieving an associated list of algorithms to be retained for the encryption library according to the mapping relationship table includes: responding to receiving an algorithm call request from the encryption library; wherein the algorithm call request carries a target type identifier of the target algorithm type to be used; determining whether there is a corresponding target shadow algorithm list mapped in the mapping relationship table for the target type identifier; if yes, returning the target shadow algorithm list to the encryption library; if no, retrieving the corresponding target list of algorithms to be retained from the default algorithm provider according to the target type identifier and returning the target list of algorithms to be retained to the encryption library.

[0057] For example, a custom algorithm provider can be loaded in the global default library context of the cryptographic library by explicit loading, and the fallback property can be omitted during loading. As a result, the default algorithm provider, which is built into the system, will not be automatically loaded in the global default library context. Instead, when a third-party caller (cryptographic library) initiates an algorithm call request, the algorithm distribution logic configured by the loaded custom algorithm provider will be used directly, making our custom algorithm provider the only choice for third-party callers.

[0058] The algorithm distribution logic configured by the custom algorithm provider may include: The custom algorithm provider responds to receiving an algorithm call request from the encryption library; the algorithm call request carries a target type identifier of the target algorithm type to be used; it determines whether the target type identifier has a corresponding target shadow algorithm list in the mapping table; if the target type identifier has a corresponding target shadow algorithm list in the mapping table, the custom algorithm provider can directly return the corresponding target shadow algorithm list to the encryption library; if the target type identifier does not have a corresponding target shadow algorithm list in the mapping table, the custom algorithm provider can retrieve the corresponding target to be retained algorithm list from the default algorithm provider according to the target type identifier and return the target to be retained algorithm list to the encryption library.

[0059] One feasible implementation of a custom algorithm provider retrieving the corresponding list of target algorithms to be retained from the default algorithm provider based on the target type identifier and returning it to the encryption library is as follows: The custom algorithm provider can query and retrieve the corresponding list of target algorithms to be retained from the default algorithm provider based on the target type identifier by proxying the default provider, reference the result retrieved by the proxy default provider, and then forward the referenced result to the encryption library. Here, the list of target algorithms to be retained refers to the list of algorithms to be retained corresponding to the target type identifier.

[0060] In this embodiment, automatic judgment and algorithm list distribution are performed based on algorithm type identifiers. For algorithm types that are expected to be replaced, the shadow algorithm list of its mapping is directly returned. For algorithm types that are expected to be retained but not replaced, the retained algorithm list of the default algorithm provider can be referenced and forwarded, for example, through a proxy mechanism. This achieves seamless integration and automatic distribution of custom algorithms and the system's original default algorithms according to custom requirements.

[0061] 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.

[0062] The encryption library algorithm management method involved in this application can be applied to the following scenarios: when a computer device's software system 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 it 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, and also wants to use the default algorithm of the encryption library to realize intermediate data processing, etc.

[0063] You can refer to this. Figure 3 As shown, Figure 3The diagram illustrates the interaction sequence of software systems interfacing with HSM in several application examples. For instance, using OpenSSL (Open Secure Sockets Layer Software Library) as an example, the software system of a computer device can be configured with an encryption management unit, a custom algorithm provider (e.g., implemented based on HSM adapter components or plugins), third-party components, and an encryption library integrated into the third-party components. Specifically, this may include the following steps: S0: The encryption management unit calls the HSM adapter component to load the mapping relationship between the form key and keyid; S1: Call OSSL_LIB_CTX_new to create a new global proxy library context g_proxy_libctx; S2: Call OSSL_PROVIDER_load (g_proxy_libctx, "default") to load the system's built-in default algorithm provider in the global proxy library context, denoted as g_proxy_default_prov (proxy default provider); S3: Call OSSL_PROVIDER_query_operation (g_proxy_default_prov,operation_id) to obtain the list of algorithm types to be replaced based on g_proxy_default_prov, ossl_algorithm (list of algorithms to be replaced); S4: Deep copy ossl_algorithm to a custom readable and writable memory area, which can be denoted as shadow_hsm_ossl_algorithm (shadow algorithm list), and replace the storage address of the relevant custom algorithm function in shadow_hsm_ossl_algorithm as needed, and establish a mapping table between the algorithm identifier of the algorithm type and the shadow algorithm list; S5: Call OSSL_PROVIDER_add_builtin (NULL, "hsm_provider", hsm_provider_init) to register hsm_provider (custom algorithm provider) based on g_proxy_default_prov in the global default library context; S6: Call OSSL_PROVIDER_load (NULL, "hsm_provider") to preload the hsm_provider based on g_proxy_default_prov in the global default library context, and specify that the entry function hsm_provider_init of hsm_provider is the only entry function required under the provider framework. That is to say, the hsm_provider based on g_proxy_default_prov is explicitly preloaded in the global default library context. Specifically, this may include: 1) Call = OSSL_PROVIDER_get0_provider_ctx (g_proxy_default_prov), that is, to obtain the runtime context of the default algorithm provider based on g_proxy_default_prov as the output runtime context.

[0064] 2) Settings = hsm_dispatch_table is an array of dispatch function pointers. Using the array of dispatch function pointers, the corresponding list of shadow algorithms or list of algorithms to be retained is returned to the core of the upper layer of the cryptographic library according to the configured dispatch logic. This allows hsm_provider, when invoked, to return a list of algorithms to the cryptographic library according to the following algorithm list distribution logic: S8: A third-party component uses a formal key to request an algorithm call from the cryptographic library; S9: The list of algorithms that the provider framework's cryptographic library calls hsm_provider to; wherein, the cryptographic library call request carries a target type identifier for the target algorithm type to be used; S10: hsm_provider checks whether the target type identifier has a corresponding target shadow algorithm list in the mapping table; if yes, proceed to S11; otherwise, proceed to S12. S11: Returns a list of target shadow algorithms for the cryptographic library; S12: Invoke the proxy default provider to obtain the corresponding target algorithm list from the default algorithm provider based on the target type identifier, and forward the target algorithm list to the cryptographic library.

[0065] S13: Use the decoder algorithm from the target list of algorithms to be retained provided by hsm_provider to decode the formal key; S14: Transmit the decoded formal key and related data and use a custom algorithm with the target shadow list provided by hsm_provider; S15: Based on a custom algorithm, find the keyid corresponding to the formal key; S16: 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; S17: Release the memory associated with the algorithm array of shadow_hsm_ossl_algorithm (shadow algorithm list); S18: Release the global proxy library context g_proxy_libctx via OSSL_LIB_CTX_free(proxy_libctx).

[0066] Example 9 In addition, more specifically, you can refer to Figure 4 As shown, Figure 4 The diagram illustrates how a complete list of algorithms corresponding to a custom algorithm provider is constructed in some embodiments.

[0067] Figure 4 The examples shown are merely illustrative and are derived from... Figure 4 As can be seen, for example, the default algorithm provider includes three types of algorithm lists: decoder algorithm lists (PEM decoding function set, DER decoding function set, etc.), digital signature algorithm lists (RSA signature function set, HSM_ECDSA decoding function set, etc.), and key management algorithm lists (RSA key management function set, HSM_EC key management function set, etc.). When constructing the algorithm list of a custom algorithm provider, its decoder algorithm list is expected to be reused, so reuse can be achieved through "direct reference"; however, the digital signature algorithm list and key management algorithm list are expected to be modified, which can be achieved by "deep copying" them to a memory area that allows write operations, thereby achieving custom replacement. For example, by using custom algorithm adaptation components (HSM_EC key management function set, HSM_ECDSA signature function set, etc.) to replace the corresponding algorithm function sets, the corresponding shadow algorithm lists (shadow digital signature algorithm list, shadow key management algorithm list) are obtained, and finally, the algorithm list of the custom algorithm provider is obtained.

[0068] 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 the key pair to calculate a signature on the handshake data to prove its identity. At this time, it is necessary to intercept the ECDSA (Elliptic Curve Digital Signature Algorithm) signature operation. Additionally, during the mTLS two-way authentication process, client certificates and client keys are set. 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. Furthermore, when signature calculation is required, a custom HSM_ECDSA signature function set can be used to find the keyid based on the formal key. Finally, the HSM interface can be called based on the keyid to achieve interfacing with HSM and obtain the HSM-based computation result. For other related cryptographic operations, such as decoding of the formal key, the relevant algorithms in the decoder algorithm list provided by the default algorithm provider can be directly reused.

[0069] 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 in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed 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.

[0070] Example 10 In some embodiments, such as Figure 5 As shown, an algorithm management device for an encryption library is provided, comprising: a list acquisition module 510, a list replacement module 520, and a custom provider construction module 530, wherein: The list retrieval module 510 is used to retrieve the list of algorithms to be replaced by the default algorithm provider of the encryption library; List replacement module 520 is used to generate a custom shadow algorithm list based on the list of algorithms to be replaced; The custom provider construction module 530 is used to associate the list of algorithms to be retained with the default algorithm provider to form an associated list of algorithms to be retained, and to construct a custom algorithm provider based on the shadow algorithm list and the associated list of algorithms to be retained; wherein, after the custom algorithm provider is loaded by the encryption library, it returns the shadow algorithm list to the encryption library or retrieves the associated list of algorithms to be retained for the encryption library.

[0071] In a further embodiment, the list acquisition module 510 is specifically used to create a global proxy library context, load the default algorithm provider in the global proxy library context to obtain the proxy default provider, and query the list of algorithms to be replaced by the default algorithm provider based on the proxy default provider.

[0072] In a further embodiment, the custom provider building module 530 is specifically used to associate the list of algorithms to be retained of the default algorithm provider queried based on the proxy default provider with the custom algorithm provider in the form of an algorithm reference pointer, so as to form an associated list of algorithms to be retained.

[0073] In a further embodiment, the list replacement module 520 is specifically used to determine the target algorithm to be replaced from the list of algorithms to be replaced; replace the target algorithm with a custom algorithm, and generate a shadow algorithm list.

[0074] In a further embodiment, the list replacement module 520 is specifically used to copy the list of algorithms to be replaced to a custom memory region; wherein, the custom memory region is a region that allows write operations; and in the custom memory region, the storage address of the target algorithm is modified to the storage address of the custom algorithm.

[0075] In a further embodiment, the list replacement module 520 is specifically used to obtain the type identifier of the algorithm type corresponding to the shadow algorithm list; construct a mapping relationship table between the type identifier and the shadow algorithm list; and the custom provider construction module 530 is specifically used to configure the custom algorithm provider to return the shadow algorithm list to the encryption library or retrieve the associated list of algorithms to be retained for the encryption library according to the mapping relationship table.

[0076] In a further embodiment, the custom provider construction module 530 is specifically configured to enable the custom algorithm provider to respond to receiving an algorithm call request from the encryption library; wherein the algorithm call request carries a target type identifier of the target algorithm type to be used; determine whether there is a corresponding target shadow algorithm list in the mapping table for the target type identifier; if yes, return the target shadow algorithm list to the encryption library; if no, retrieve the corresponding target to be retained algorithm list from the default algorithm provider according to the target type identifier and return the target to be retained algorithm list to the encryption library.

[0077] 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.

[0078] Example 11 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 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 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.

[0079] Example 12 In some embodiments, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7As 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.

[0080] Those skilled in the art will understand that Figure 6 and 7 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 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.

[0081] Example 13 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 list of algorithms to be replaced by the default algorithm provider of an encryption library; generating a custom shadow algorithm list based on the list of algorithms to be replaced; associating the list of algorithms to be retained by the default algorithm provider to form an associated list of algorithms to be retained; and constructing a custom algorithm provider based on the shadow algorithm list and the associated list of algorithms to be retained. The custom algorithm provider, after being loaded by the encryption library, returns the shadow algorithm list to the encryption library or retrieves the associated list of algorithms to be retained for the encryption library.

[0082] In a further embodiment, when the processor executes the computer program, it also performs the following steps: creating a global proxy library context, loading a default algorithm provider in the global proxy library context to obtain a proxy default provider; and querying a list of algorithms to be replaced by the default algorithm provider based on the proxy default provider.

[0083] In a further embodiment, when the processor executes the computer program, it also performs the following steps: associating the list of algorithms to be retained of the default algorithm provider queried based on the proxy default provider with a custom algorithm provider in the form of an algorithm reference pointer, so as to form an associated list of algorithms to be retained.

[0084] In a further embodiment, when the processor executes the computer program, it also performs the following steps: determining the target algorithm to be replaced from the list of algorithms to be replaced; replacing the target algorithm with a custom algorithm to generate a list of shadow algorithms.

[0085] In a further embodiment, when the processor executes the computer program, it also performs the following steps: copying the list of algorithms to be replaced to a custom memory region; wherein the custom memory region is a region that allows write operations; and modifying the storage address of the target algorithm to the storage address of the custom algorithm in the custom memory region.

[0086] In a further embodiment, when the processor executes the computer program, it also performs the following steps: obtaining the type identifier of the algorithm type corresponding to the shadow algorithm list; constructing a mapping table between the type identifier and the shadow algorithm list; and returning the shadow algorithm list to the encryption library or retrieving the associated list of algorithms to be retained for the encryption library according to the mapping table.

[0087] In a further embodiment, when the processor executes the computer program, it also performs the following steps: in response to receiving an algorithm call request from an encryption library; wherein the algorithm call request carries a target type identifier of the target algorithm type to be used; determining whether there is a corresponding target shadow algorithm list in the mapping table for the target type identifier; if yes, returning the target shadow algorithm list to the encryption library; if no, retrieving the corresponding target to be retained algorithm list from the default algorithm provider according to the target type identifier and returning the target to be retained algorithm list to the encryption library.

[0088] Example 14 In some embodiments, a computer-readable storage medium is provided having a computer program stored thereon. When the computer program is executed by a processor, it performs the following steps: obtaining a list of algorithms to be replaced by the default algorithm provider of an encryption library; generating a custom shadow algorithm list based on the list of algorithms to be replaced; associating the list of algorithms to be retained by the default algorithm provider to form an associated list of algorithms to be retained; and constructing a custom algorithm provider based on the shadow algorithm list and the associated list of algorithms to be retained. The custom algorithm provider, after being loaded by the encryption library, returns the shadow algorithm list to the encryption library or retrieves the associated list of algorithms to be retained for the encryption library.

[0089] In a further embodiment, when the computer program is executed by the processor, it also performs the following steps: creating a global proxy library context, loading a default algorithm provider in the global proxy library context to obtain a proxy default provider; and querying a list of algorithms to be replaced by the default algorithm provider based on the proxy default provider.

[0090] In a further embodiment, when the computer program is executed by the processor, it also performs the following steps: associating the list of algorithms to be retained of the default algorithm provider queried based on the proxy default provider with a custom algorithm provider in the form of an algorithm reference pointer, so as to form an associated list of algorithms to be retained.

[0091] In a further embodiment, when the computer program is executed by the processor, it also performs the following steps: determining the target algorithm to be replaced from the list of algorithms to be replaced; replacing the target algorithm with a custom algorithm to generate a list of shadow algorithms.

[0092] In a further embodiment, when the computer program is executed by the processor, it also performs the following steps: copying the list of algorithms to be replaced to a custom memory region; wherein the custom memory region is a region that allows write operations; and modifying the storage address of the target algorithm to the storage address of the custom algorithm in the custom memory region.

[0093] In a further embodiment, when the computer program is executed by the processor, it also performs the following steps: obtaining the type identifier of the algorithm type corresponding to the shadow algorithm list; constructing a mapping table between the type identifier and the shadow algorithm list; and returning the shadow algorithm list to the encryption library or retrieving the associated list of algorithms to be retained for the encryption library according to the mapping table.

[0094] In a further embodiment, when the computer program is executed by the processor, it further implements the following steps: in response to receiving an algorithm call request from the encryption library; wherein the algorithm call request carries a target type identifier of the target algorithm type to be used; determining whether there is a corresponding target shadow algorithm list in the mapping table for the target type identifier; if yes, returning the target shadow algorithm list to the encryption library; if no, retrieving the corresponding target to be retained algorithm list from the default algorithm provider according to the target type identifier and returning the target to be retained algorithm list to the encryption library.

[0095] Example 15 In some embodiments, reference Figure 8 As shown, a vehicle can also be provided, which may include an in-vehicle terminal. The in-vehicle 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 in-vehicle 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.

[0096] Those skilled in the art will understand that Figure 8The 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.

[0097] 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.

[0098] 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.

[0099] 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.

[0100] 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: Get the list of alternative algorithms for the default algorithm provider of the encryption library; Generate a custom shadow algorithm list based on the list of algorithms to be replaced; The list of algorithms to be retained is associated with the default algorithm provider to form an associated list of algorithms to be retained, and a custom algorithm provider is constructed based on the shadow algorithm list and the associated list of algorithms to be retained; wherein, after the custom algorithm provider is loaded by the encryption library, it returns the shadow algorithm list to the encryption library or retrieves the associated list of algorithms to be retained for the encryption library.

2. The method according to claim 1, characterized in that, The list of algorithms to be replaced by the default algorithm provider of the encryption library includes: Create a global proxy library context, load the default algorithm provider in the global proxy library context, and obtain the default proxy provider; Based on the proxy default provider, query the list of algorithms to be replaced by the default algorithm provider.

3. The method according to claim 2, characterized in that, The list of algorithms to be retained associated with the default algorithm provider forms the associated list of algorithms to be retained, including: The list of algorithms to be retained, which is queried based on the default algorithm provider of the agent, is associated with the custom algorithm provider in the form of an algorithm reference pointer, so as to form an associated list of algorithms to be retained.

4. The method according to claim 1, characterized in that, The step of generating a custom shadow algorithm list based on the list of algorithms to be replaced includes: Determine the target algorithm to be replaced from the list of algorithms to be replaced; Replace the target algorithm with a custom algorithm to generate the shadow algorithm list.

5. The method according to claim 4, characterized in that, The step of replacing the target algorithm with a custom algorithm includes: Copy the list of algorithms to be replaced to a custom memory region; wherein, the custom memory region is a region that allows write operations; In the custom memory region, the storage address of the target algorithm is modified to the storage address of the custom algorithm.

6. The method according to claim 1, characterized in that, After generating a custom shadow algorithm list based on the list of algorithms to be replaced, the method further includes: Obtain the type identifier of the algorithm type corresponding to the shadow algorithm list; Construct a mapping table between the type identifiers and the list of shadow algorithms; The step of returning the shadow algorithm list to the encryption library or retrieving the associated list of algorithms to be retained for the encryption library includes: The mapping table is used to return the list of shadow algorithms to the encryption library or to retrieve the associated list of algorithms to be retained for the encryption library.

7. The method according to claim 6, characterized in that, The step of returning the shadow algorithm list to the encryption library or retrieving the associated list of algorithms to be retained for the encryption library based on the mapping table includes: In response to receiving an algorithm call request from the encryption library; wherein the algorithm call request carries a target type identifier of the target algorithm type to be used; Determine whether the target type identifier exists in the mapping table in the target shadow algorithm list that corresponds to the mapping; If so, then return the target shadow algorithm list to the encryption library; If not, then based on the target type identifier, retrieve the corresponding target algorithm list from the default algorithm provider and return the target algorithm list to the encryption library.

8. An algorithm management device for an encryption library, characterized in that, The device includes: The list retrieval module is used to retrieve a list of algorithms to be replaced by the default algorithm provider of the encryption library; The list replacement module is used to generate a custom shadow algorithm list based on the list of algorithms to be replaced; A custom provider construction module is used to associate the default algorithm provider with the list of algorithms to be retained, and to construct a custom algorithm provider based on the shadow algorithm list and the associated list of algorithms to be retained; wherein, after the custom algorithm provider is loaded by the cryptographic library, it returns the shadow algorithm list to the cryptographic library or retrieves the associated list of algorithms to be retained for the cryptographic library.

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