Key library generation method and device, equipment and storage medium
The policy-driven approach of generating keystores by dynamically setting attribute variables solves the problems of poor scalability and long downtime in keystore management in existing technologies, and achieves efficient and secure keystore management, supporting dynamic switching between commercial and non-commercial cryptographic algorithms and automatic routing by hardware and software providers.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANDONG CVICSE MIDDLEWARE CO LTD
- Filing Date
- 2026-03-13
- Publication Date
- 2026-04-21
AI Technical Summary
Existing technologies have poor scalability, long downtime windows, and a high probability of errors when managing keystores. They cannot efficiently and securely manage encrypted materials such as SSL certificates, symmetric keys, and asymmetric keys. In particular, when launching new services, changing encryption algorithms, or replacing hardware cryptographic machines, keystores and configuration files need to be manually regenerated.
By acquiring the initial policy file, dynamically setting the attribute values of attribute variables, generating instantiated policies, automatically creating keystores and generating triplet information, efficient management of sensitive data is achieved, supporting dynamic switching between commercial and non-commercial cryptographic algorithms and automatic routing by hardware and software providers.
It simplifies the keystore generation process, reduces downtime and error probability, achieves efficient and secure keystore management, and supports dynamic switching between commercial and non-commercial cryptographic algorithms and automatic routing by hardware and software providers.
Smart Images

Figure CN121907461A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of key library generation technology, and in particular to a method, apparatus, device and storage medium for generating a key library. Background Technology
[0002] As middleware application servers handle an increasing number of business types, the complexity of managing encrypted materials such as SSL (Secure Socket Layer) certificates, symmetric keys, and asymmetric keys has risen sharply.
[0003] Current technologies generally employ a pre-built keystore and static configuration model. This means that operations personnel pre-create keystores such as JKS (Java Keystore) / PKCS12 (Public-Key Cryptography Standards) on the server or in the HSM (Hardware Security Module), and then hardcode the keystore path, password, and algorithm type in the configuration file. However, when a new service is launched and the encryption algorithm or hardware cryptographic device needs to be changed, a new keystore must be manually generated, and then a new configuration file must be hardcoded based on the new keystore. Therefore, the keystore management model provided by existing technologies suffers from poor scalability, long downtime, and a high probability of errors.
[0004] Therefore, how to manage the keystore efficiently and securely is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention
[0005] This application provides a method, apparatus, device, and storage medium for generating a key store, enabling efficient and secure management of the key store.
[0006] Firstly, this application provides a method for generating a keystore, the method comprising:
[0007] Obtain the initial policy file; wherein, the initial policy file includes various attribute variables and sensitive data processing sections of various types, and each sensitive data processing section declares the business sensitive data processing category, algorithm type and key alias;
[0008] Determine the attribute values of each attribute variable within the initial strategy file;
[0009] Based on the initial strategy file and the attribute values of each attribute variable, an instantiated strategy is generated;
[0010] A first key store is created using the instantiation strategy, and triplet information of the first key store is generated; the first key store includes keys corresponding to each sensitive data processing segment, and the triplet information of each key includes: algorithm type, key alias and key store information;
[0011] The triplet information of each key is stored so that the corresponding key can be obtained from the first key library based on the triplet information to process sensitive data.
[0012] Optionally, determining the attribute values of each attribute variable within the initial strategy file includes:
[0013] Check if there are user-inputted custom attribute values;
[0014] If it exists, the custom attribute value will be used as the attribute value of each attribute variable in the initial strategy file; if it does not exist, the default attribute value will be used as the attribute value of each attribute variable.
[0015] Optionally, based on the initial strategy file and the attribute values of each attribute variable, an instantiation strategy is generated, including:
[0016] Replace the placeholders corresponding to each attribute variable in the initial policy file with the corresponding attribute values; wherein, the attribute values include basic keystore information and algorithm type selection information for sensitive data processing sections; the basic keystore information includes: keystore provider, keystore type, and keystore name;
[0017] Based on the algorithm type selection information, the algorithm type of each sensitive data processing segment is determined, thereby generating an instantiation strategy.
[0018] Optionally, determining the algorithm type for each sensitive data processing segment based on the algorithm type selection information includes:
[0019] If the algorithm type selection information is commercial cryptographic algorithm, then the algorithm type of the sensitive data processing segment is set to commercial cryptographic algorithm so that when the first key store is created, the key of the sensitive data processing segment is created according to the commercial cryptographic algorithm;
[0020] If the algorithm type selection information is a non-commercial cryptographic algorithm, then the algorithm type of the sensitive data processing segment is set to a non-commercial cryptographic algorithm so that when creating the first key library, the key for the sensitive data processing segment is created according to the non-commercial cryptographic algorithm.
[0021] Optionally, based on the triplet information, processing the sensitive data by obtaining the corresponding key pair from the first key store includes:
[0022] Determine the processing category of the sensitive data to be processed;
[0023] The processing category is matched with the algorithm type of each triplet information to find target triplet information with the same processing category;
[0024] The first key library is determined based on the key library information of the target triplet information, and the corresponding key is found using the key alias of the target triplet information so that the sensitive data to be processed can be processed according to the found key.
[0025] Optionally, determining the processing category of the sensitive data to be processed includes:
[0026] Determine the processing category based on the processing scenario of the sensitive data to be processed;
[0027] The processing category is at least one of the following: data transmission category, data storage category, and data integrity verification category.
[0028] Optionally, the generation method further includes:
[0029] Receive attribute value modification instructions;
[0030] According to the attribute value modification instruction, the attribute value of the corresponding attribute variable in the instantiation strategy is modified to obtain the modified instantiation strategy;
[0031] Create a target working domain, and within the target working domain, create a second keystore using the modified instantiation strategy;
[0032] Generate triplet information for each key in the second key library and store the triplet information for each key in a memory mapping table.
[0033] Secondly, this application provides a keystore generation apparatus, the generation apparatus comprising:
[0034] The acquisition module is used to acquire the initial policy file; wherein, the initial policy file includes various attribute variables and sensitive data processing sections of various types, and each sensitive data processing section declares the business sensitive data processing category, algorithm type and key alias;
[0035] The attribute value determination module is used to determine the attribute values of each attribute variable in the initial strategy file;
[0036] The first generation module is used to generate an instantiated strategy based on the initial strategy file and the attribute values of each attribute variable.
[0037] The first creation module is used to create a first keystore using the instantiation strategy;
[0038] The second generation module is used to generate triplet information of the first key library; the first key library includes keys corresponding to each sensitive data processing segment, and the triplet information of each key includes: algorithm type, key alias and key library information;
[0039] The storage module is used to store the triplet information of each key, so that the corresponding key can be obtained from the first key library based on the triplet information to process sensitive data.
[0040] Thirdly, this application provides an electronic device, comprising:
[0041] Memory, used to store computer programs;
[0042] A processor is configured to implement the steps of the keystore generation method described above when executing the computer program.
[0043] Fourthly, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described keystore generation method.
[0044] Compared with the prior art, the technical solutions provided in this application have the following advantages: This application provides a method, apparatus, device, and storage medium for generating a key library; in this solution, instead of using a pre-set key library and static configuration, the key library is automatically created through an initial policy file and the attribute values of each attribute variable, and the triplet information of each key in the key library is automatically generated. When processing sensitive data, the business thread can directly obtain the corresponding key based on the triplet information for processing; if it is necessary to change the encryption algorithm or the hardware cryptographic machine, there is no need to manually regenerate a new key library and configuration file. Only the attribute values of the attribute variables need to be changed to automatically create a new key library and triplet information. This key library management method greatly simplifies the key library generation process, reduces downtime, and lowers the probability of errors, thereby achieving efficient and secure key library management. Attached Figure Description
[0045] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.
[0046] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0047] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.
[0048] Figure 1 A schematic flowchart illustrating a method for generating a key library, as provided in an embodiment of this application;
[0049] Figure 2 This application provides a schematic diagram of the overall process of key store management.
[0050] Figure 3 A schematic diagram of a key library generation device provided in an embodiment of this application;
[0051] Figure 4 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. Detailed Implementation
[0052] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of this application.
[0053] It should be noted that, in the optional embodiments of this application, the data related to object information, when applied to specific products or technologies, requires the permission or consent of the object. Furthermore, the collection, use, and processing of this data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if the embodiments of this application involve data related to an object, it must be obtained with the object's authorization and consent, the authorization and consent of relevant departments, and in accordance with the relevant laws, regulations, and standards of the country and region. If the embodiments involve personal information, the acquisition of all personal information requires the individual's consent. If sensitive information is involved, the separate consent of the information subject is required. The embodiments also need to be implemented with the object's authorization and consent.
[0054] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0055] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.
[0056] Traditional solutions primarily employ a "pre-built keystore + static configuration" model, which consists of only one keystore and configuration file. The generated keys are written in the code. When new business is added, compliance requirements are upgraded, or algorithms are switched, the keystore must be manually shut down and rebuilt, resulting in extremely poor scalability. Furthermore, after key rotation, code modifications or container restarts are required, leading to a heavy operational burden.
[0057] Furthermore, traditional solutions only provide non-commercial cryptographic algorithms and decouple the "algorithm type—key—keystore" into separate modules, lacking a unified policy hub. In scenarios where both commercial and non-commercial cryptographic algorithms coexist, they cannot achieve on-demand matching and switching of algorithms, resulting in high compliance costs. Secondly, traditional solutions cannot dynamically select the keystore storage medium based on the differences between software and hardware cryptographic providers. Moreover, when software and hardware cryptographic providers coexist, upper-layer business code needs to be aware of different interfaces and paths, making transparent migration and elastic scaling difficult.
[0058] As discussed above regarding traditional solutions, when business operations require upgrades in compliance requirements, algorithm changes, or the addition of sensitive fields, repeated manual adjustments to the keystore and configuration files are necessary. This results in high maintenance costs and is prone to security risks such as key reuse, redundant keystore files, or non-compliant algorithms. Therefore, there is an urgent need for a middleware key management solution that is driven by "configuration policy files," can dynamically create keystores on demand, and can automatically bind policies, keys, and keystores.
[0059] Therefore, this application discloses a method, apparatus, device, and storage medium for generating a key store, so as to manage the key store efficiently and securely.
[0060] See Figure 1 This is a schematic flowchart of a keystore generation method provided in an embodiment of this application. The generation method includes:
[0061] S101. Obtain the initial policy file; wherein, the initial policy file includes various attribute variables and sensitive data processing sections of various types, and each sensitive data processing section declares the business sensitive data processing category, algorithm type and key alias;
[0062] This application implements keystore management for sensitive data through a strategy-driven, dynamically pre-configured, and triplet-indexed approach. Strategy-driven management refers to the pre-deployment of an initial strategy file, which includes various attribute variables such as basic keystore information and algorithm type selection information, without specific limitations. Dynamic pre-configuration refers to pre-setting attribute values for these variables based on actual needs. This allows for the generation of instantiated strategies based on the initial strategy file and attribute values, and the automatic creation of keystores that meet the instantiated strategy requirements. Triplet indexing refers to the automatic generation of triplet information after keystore creation, including algorithm type, key alias, and keystore information. When processing sensitive data, the business side can directly use the triplet information to find the corresponding key for processing.
[0063] Specifically, the initial policy file in this application is a lightweight policy template deployed on the application server side. The content of the policy template can be in formats such as XML (eXtensible Markup Language), JSON (JavaScript Object Notation), or YAML (YAML Ain't MarkupLanguage). In subsequent embodiments, only XML will be used as an example for illustration.
[0064] The initial policy file includes at least: various attribute variables and various types of sensitive data processing segments. The attribute variables are user-configurable variables, including basic keystore information and algorithm type selection information for sensitive data processing segments. The basic keystore information includes, but is not limited to: keystore provider, keystore type, and keystore name. The algorithm type selection information for sensitive data processing segments is used to set the algorithm type for the sensitive data processing segments, which includes, but is not limited to, commercial cryptographic algorithms and non-commercial cryptographic algorithms.
[0065] Furthermore, the sensitive data processing segments of various types in this application can be customized according to the processing category. In this embodiment, the sensitive data processing segment may include the following types: sensitive data transmission segment, sensitive data storage segment, and integrity verification segment. Moreover, the sensitive data transmission segment, sensitive data storage segment, and integrity verification segment all declare the business sensitive data processing category, algorithm type, and key alias. That is to say, in different types of sensitive data processing segments, the algorithm type and key alias of sensitive data under different processing categories are recorded. Among them, the key alias can be stored as an index in the key library file so that when the business thread uses it, it can directly look up the corresponding key from the key library through the key alias in the matching triplet information.
[0066] For ease of understanding, this explanation will focus on the user password as an example to illustrate the processing of the three types of sensitive data mentioned above:
[0067] First, after the user enters their password on the client, the client sends the password to the server for verification or storage. Since passwords are such secure data, they need to be encrypted during transmission to prevent leakage. Therefore, the password needs to be encrypted based on the content declared in the sensitive data transmission segment. Upon receiving the encrypted password, the server decrypts it. If storage is required, it uses a symmetric key to encrypt the password based on the content declared in the sensitive data storage segment. If integrity verification is needed, it uses a hash algorithm to calculate the integrity verification value based on the content declared in the integrity verification segment and stores it for subsequent password integrity verification.
[0068] In other words, the sensitive data processing sections for each type include the following:
[0069] 1) Business-sensitive data processing category: sensitive data transmission segment; algorithm type: asymmetric cryptographic algorithm, such as RSA or SM2; key alias: transport;
[0070] 2) Business-sensitive data processing category: sensitive data storage segment, algorithm type: symmetric cryptographic algorithm, such as AES or SM4, key alias: storage;
[0071] 3) Business-sensitive data processing category: integrity verification segment, algorithm type: hash algorithm, such as SM3 or SHA256, etc.
[0072] It should be noted that the key aliases in this scheme can be customized according to requirements. Here, only transport and storage are used as examples for explanation.
[0073] S102. Determine the attribute values of each attribute variable in the initial strategy file;
[0074] In this embodiment, when automatically creating a keystore, it is necessary to pre-configure based on who needs it. That is, users can fill in the attribute values of each attribute variable in the initial policy file according to the actual environment and personal needs, thereby realizing the one-time dynamic generation of the keystore or the reuse of the keystore. It should be noted that the keystore in this application is a file that stores keys. This application can determine whether the keystore file is stored locally or in the HSM internal library by setting attribute values. This storage location can be determined by setting the attribute value of the keystore provider attribute variable. Furthermore, within the same policy, software JCE (Java Cryptography Extension Provider), hardware PKCS11 (PKCS#11 standard-based hardware provider), and commercial cryptographic software implementation (software implementation of commercial cryptographic algorithms) can be declared together, and the engine will automatically route them. Moreover, the attribute names of the attribute variables in the initial policy file cannot be changed. If changes are needed, the attribute variables in the initial policy file can be dynamically adjusted.
[0075] In another embodiment of this application, determining the attribute values of each attribute variable in the initial strategy file includes: detecting whether there are user-inputted custom attribute values; if so, using the custom attribute values as the attribute values of each attribute variable in the initial strategy file; if not, using the default attribute values as the attribute values of each attribute variable.
[0076] Specifically, users can pre-define the attribute values of each attribute variable so that an instantiation strategy can be generated based on the user-inputted custom attribute values. Furthermore, this application can also pre-set default attribute values. If no user-inputted custom attribute value is detected, the pre-set default attribute value can be directly obtained to generate an instantiation strategy. This application may refer to the instantiation strategy generated using the default attribute values as a default strategy file.
[0077] S103. Generate an instantiated strategy based on the initial strategy file and the attribute values of each attribute variable;
[0078] In this application, during the application server initialization phase, the policy parsing engine generates an instantiated policy based on the initial policy file and the attribute values of each attribute variable; wherein, the instantiated policy refers to the policy file generated after modifying the initial policy file based on the attribute values.
[0079] In another embodiment of this application, an instantiation strategy is generated based on the initial strategy file and the attribute values of each attribute variable, including:
[0080] Replace the placeholders corresponding to each attribute variable in the initial policy file with the corresponding attribute values; wherein, the attribute values include basic keystore information and algorithm type selection information for sensitive data processing segments; the basic keystore information includes: keystore provider, keystore type, and keystore name; based on the algorithm type selection information, determine the algorithm type for each sensitive data processing segment, thereby generating an instantiated policy.
[0081] Specifically, in the initial policy file, the values of each attribute variable are represented by placeholders. When the policy parsing engine generates an instantiated policy, it can replace the placeholders of each attribute variable with the attribute values of the actual environment to form an instantiated policy.
[0082] For example, if the initial policy file includes placeholders for keystore provider, keystore type, keystore name, and algorithm type selection information, then the placeholder for keystore provider (%%%provider%%%) should be changed to the specific keystore provider. Similarly, the placeholder for keystore type should be changed to the specific keystore type, the placeholder for keystore name should be changed to the specific keystore name, and the placeholder for algorithm type selection information should be changed to the specific algorithm type selection information.
[0083] In another embodiment of this application, determining the algorithm type of each sensitive data processing segment based on the algorithm type selection information includes:
[0084] If the algorithm type selection information is a commercial cryptographic algorithm, then the algorithm type of the sensitive data processing segment is set to a commercial cryptographic algorithm so that when creating the first key library, the key of the sensitive data processing segment is created according to the commercial cryptographic algorithm; if the algorithm type selection information is a non-commercial cryptographic algorithm, then the algorithm type of the sensitive data processing segment is set to a non-commercial cryptographic algorithm so that when creating the first key library, the key of the sensitive data processing segment is created according to the non-commercial cryptographic algorithm.
[0085] Specifically, the algorithm type selection information in this application is used to determine the algorithm type of the sensitive data processing segment. Users can determine whether to use a commercially encrypted algorithm or a non-commercially encrypted algorithm by setting the algorithm type selection information. For example, the default algorithm is a non-commercially encrypted algorithm. If the user sets the algorithm type selection information to a non-commercially encrypted algorithm or sets the algorithm type selection information to yes, it means that the algorithm type used in the sensitive data processing segment is a non-commercially encrypted algorithm. If the user sets the algorithm type selection information to a commercially encrypted algorithm or sets the algorithm type selection information to no, it means that the algorithm type required by the sensitive data processing segment is a commercially encrypted algorithm, and the algorithm type of the sensitive data processing segment is set to a commercially encrypted algorithm.
[0086] For ease of understanding, we will use the specific content of the instantiated policy securityPolicy.yml as an example for illustration:
[0087] security:
[0088] #------Transport Phase------
[0089] #Asymmetric algorithm, responsible for encrypted transmission between the front-end and back-end. Supports commercially available SM2 or non-commercially available RSA;
[0090] sensitive-transport-algorithm:RSA# can also be written as SM2;
[0091] #The key corresponding to the above algorithm is an "alias" in the key store. The runtime will use this alias to look up the corresponding public / private key.
[0092] sensitive-transport-alias:transport;
[0093] #------Storage Stage------
[0094] #Symmetric algorithms are used to encrypt sensitive data that is actually written to disk, such as the secure storage of database passwords. Supports commercial cryptographic SM4 or non-commercial cryptographic AES;
[0095] sensitive-storage-algorithm:AES# can also be written as SM4;
[0096] #This is the alias of the symmetric key in the keystore. The runtime will use this alias to look up the corresponding key.
[0097] sensitive-storage-alias:storage;
[0098] #------Integrity Verification------
[0099] #Digest algorithm for tamper-proofing. Supports commercial cryptographic SM3 or non-commercial cryptographic SHA-256, etc.;
[0100] integrity-check-algorithm:SM3;
[0101] #------Keystore Candidate Pool (Interactive selection of effective policy when creating a domain)------
[0102] strategies:
[0103] # Strategy 1: Standard PKCS#12 file library; 1:
[0105] provider:com.tencent.kona.KonaProvider;
[0106] store-type:PKCS12;
[0107] keystore-file:keystore.p12.
[0108] In the above content, the transmission phase corresponds to the sensitive data transmission segment. `sensitive-transport-algorithm` represents the sensitive transmission algorithm, which is the attribute name of the algorithm type; specifically, the algorithm type is RSA. `sensitive-transport-alias` represents the sensitive transmission alias, which is the attribute name of the key alias; specifically, the key alias is `transport`. From the attribute names of the algorithm type and key alias, it can be seen that the business sensitive data processing category of the sensitive data transmission segment is the data transmission category. The algorithm type selection information for the sensitive data transmission segment is a non-commercial encrypted algorithm. If switching to a commercial encrypted algorithm, the algorithm type can be changed to SM2.
[0109] The storage stage corresponds to a sensitive data storage segment. `sensitive-storage-algorithm` specifies the sensitive storage algorithm, i.e., the attribute name of the algorithm type; specifically, the algorithm type is AES. `sensitive-storage-alias` specifies the sensitive transmission alias, i.e., the attribute name of the key alias; specifically, the key alias is `storage`. From the attribute names of the algorithm type and key alias, it can be seen that the business sensitive data processing category of the sensitive data storage segment is the data storage category. The algorithm type selection information for the sensitive data storage segment is a non-commercial encrypted algorithm. If switching to a commercial encrypted algorithm, the algorithm type can be changed to SM4.
[0110] The integrity check corresponds to an integrity check segment. `integrity-check-algorithm` is the integrity check algorithm, which is the attribute name of the algorithm type. Specifically, the algorithm type is SM3. The attribute name of the algorithm type indicates that the business-sensitive data processing category of the integrity check segment is the data integrity check category. The algorithm type selection information for the integrity check segment is a commercially encrypted algorithm. If switching to a non-commercially encrypted algorithm, the algorithm type can be changed to SHA-256.
[0111] Furthermore, provider is the attribute name of the keystore provider, store-type is the attribute name of the keystore type, and keystore-file is the attribute name of the keystore name. According to the content recorded in the instantiation policy, the user-set attribute value of the keystore provider is com.tencent.kona.KonaProvider, the attribute value of the keystore type is PKCS12, and the attribute value of the keystore name is keystore.p12.
[0112] S104. Create a first key store using the instantiation strategy and generate triplet information for the first key store; the first key store includes keys corresponding to each sensitive data processing segment, and the triplet information for each key includes: algorithm type, key alias and key store information;
[0113] After generating the instantiation policy, this application can create the first keystore based on the instantiation policy without requiring real-time creation at runtime. Taking the instantiation policy described above as an example, the system will generate a keystore file named keystore.p12, provided by com.tencent.kona.KonaProvider, of type PKCS12, based on the instantiation policy file. This keystore file stores two keys: a sensitive data transmission key (of type RSA, aliased as transport) and a sensitive data encryption key (of type AES, aliased as storage). It should be noted that in the above instantiation policy, only the type name of the integrity verification algorithm, such as SM3 or SHA-256, needs to be specified; there is no need to store the key. Therefore, the keystore file only stores the sensitive data transmission key and the sensitive data encryption key.
[0114] S105. Store the triplet information of each key so that, based on the triplet information, the corresponding key is obtained from the first key library to process the sensitive data.
[0115] In this application, after creating the keystore, it is also necessary to generate triplet information for the keystore according to the instantiation strategy. This triplet information specifically includes the algorithm type, key alias, and keystore information, which can be the keystore path, keystore handle, etc. Taking the instantiation strategy above as an example, the triplet information for sensitive data transmission segments is composed of `sensitive-transport-algorithm`, `sensitive-transport-alias`, and `keystore-file`, and the generated triplet information is specifically (RSA, transport, keystore.p12). Furthermore, a runtime immutable memory mapping table needs to be pre-established. After generating the triplet information, this triplet information can be used as a composite key and registered in the memory mapping table for storage, so that business threads can retrieve the corresponding key from the keystore based on the triplet information to process sensitive data.
[0116] In another embodiment of this application, processing sensitive data by obtaining the corresponding key pair from the first key library based on the triplet information includes:
[0117] Determine the processing category of the sensitive data to be processed; match the processing category with the algorithm type of each triplet information to find target triplet information with the same processing category; determine the first key library according to the key library path of the target triplet information, and use the key alias of the target triplet information to find the corresponding key so as to process the sensitive data to be processed according to the found key.
[0118] Specifically, after the business thread identifies the sensitive data to be processed, it first needs to determine the processing category of the sensitive data. In another embodiment of this application, determining the processing category of the sensitive data includes: determining the processing category based on the processing scenario of the sensitive data; wherein, the processing category is at least one of: data transmission category, data storage category, and data integrity verification category. For example, if the processing scenario of the sensitive data to be processed is data transmission, then the determined processing category is the data transmission category.
[0119] This application determines the processing category of the sensitive data to be processed, and then matches the processing category with the algorithm type of each triplet information to find target triplet information with the same processing category. Specifically, different processing categories have different algorithm types. Therefore, this application can search for the algorithm type that matches the processing category from each triplet information, and the triplet information containing the matching algorithm type is called the target triplet information. Then, the corresponding keystore is found based on the keystore information in the target triplet information, and the corresponding key in the keystore is found based on the key alias in the target triplet information.
[0120] For example, if the sensitive data to be processed is a user password, and its processing category is data transmission, then the algorithm type RSA belonging to the data transmission category is found from each triplet information. The corresponding keystore information and key alias are then determined. Based on the keystore information and key alias, the asymmetric RSA key aliased as "transport" in the keystore.p12 keystore file can be used to encrypt and transmit the user password. If encryption is required during storage, then the algorithm type AES belonging to the data storage category is found from each triplet information. The corresponding keystore information and key alias for AES are then determined. Based on the keystore information and key alias, the AES key aliased as "storage" in the keystore.p12 keystore file can be used to encrypt and store the user password.
[0121] Furthermore, during system runtime, business threads can pass in key aliases via standard JCE (Java Cryptography Extension) / CSP (Cryptographic Service Provider) interfaces. The system locates the existing keystore file based on the triple index, loads the keystore, and returns the corresponding key, without needing to be aware of the differences in underlying algorithms and carriers. With this approach, this application can pre-configure the keystore once based on a policy template in a single-node or cluster environment, and read it only through the index at runtime, thus avoiding the expansion bottleneck of static pre-configuration while ensuring runtime performance and stability.
[0122] In another embodiment of this application, the solution further includes:
[0123] Receive an attribute value modification instruction; modify the attribute value of the corresponding attribute variable in the instantiation strategy according to the attribute value modification instruction to obtain the modified instantiation strategy; create a target working domain, and create a second key library in the target working domain using the modified instantiation strategy; generate triplet information of each key in the second key library, and store the triplet information of each key in a memory mapping table.
[0124] In this application, if there are changes to the algorithm type, key store provider, etc., the user can trigger an attribute value modification command. The system modifies the attribute values in the instantiation policy based on the attribute value modification command, thereby generating another modified instantiation policy so as to recreate a new second key store.
[0125] To avoid the second keystore affecting the processing of the original data, this application can create a new target working domain and create a second keystore within the target working domain using a modified instantiation strategy. That is, the first keystore is created in the original working domain, and the second keystore is created in the target working domain, with the data processing processes of the two working domains being independent of each other.
[0126] In summary, this application demonstrates that when the encryption algorithm or hardware cryptographic machine needs to be changed, there is no need to manually regenerate a new keystore and configuration file. Only the attribute values of the attribute variables need to be changed to automatically create a new keystore and triplet information. This keystore management method greatly simplifies the keystore generation process, reduces downtime, and lowers the probability of errors, thereby achieving efficient and secure keystore management.
[0127] See Figure 2 The figure shows a schematic diagram of the overall process of key store management provided in an embodiment of this application. The process includes the following:
[0128] 1. Startup / Policy Change:
[0129] In this embodiment, when the system starts up for the first time, or when the administrator modifies the policy, the subsequent initialization or reload process will be triggered.
[0130] 2. XML parsing strategy:
[0131] After the system obtains the initial strategy file, it replaces the placeholders in the initial strategy file with specific attribute values. In this way, the same initial strategy file can be used in development / testing / production, and only the attribute values of the attribute variables need to be modified. This process does not require manual intervention and the difference time is less than 50ms.
[0132] 3. Dynamically generate keystore:
[0133] In this embodiment, after parsing the XML policy to generate an instantiation policy through the above process, a keystore can be dynamically generated based on the instantiation policy. If the instantiation policy changes, a target working domain is created, and a new keystore is recreated based on the target working domain. In this way, the keystore already exists before the system runs, and it is not created during peak business periods. Moreover, commercial / non-commercial encryption algorithms, software / hardware providers can customize and modify them according to actual needs.
[0134] 4. Register the triplet memory index table:
[0135] After creating the keystore in this embodiment, the "key algorithm#key alias#store path" needs to be written into the memory index table, such as ConcurrentHashMap. In this way, the business thread can get the key simply by saying "I want alias X", achieving zero code modification and less than 1ms during rotation.
[0136] 5. The business thread obtains the key through a standard interface:
[0137] In this embodiment, the business thread can obtain the key through a standard interface, such as the standard JCE call: Cipher.getInstance(“SM4”,“GMLS”), which means obtaining a Cipher instance using the SM4 algorithm (default working mode and padding method) through a cryptographic service provider named "GMLS". This application achieves 100% compatibility with existing code and requires no API learning cost.
[0138] In summary, this scheme adopts a policy-driven, dynamically generated, and triplet-bound keystore management model, which differs from traditional schemes in the following ways:
[0139] 1. Lightweight XML strategy files serve as the unified configuration hub:
[0140] In this application, the three security requirements of transmission, storage, and integrity are abstracted into hot-swappable XML segments that support placeholder replacement. This allows a single template to describe both commercially and non-commercially secure algorithms, as well as software and hardware providers. When scaling up or down operations or switching to compliance requirements, only the policy file needs to be modified, without changing the code.
[0141] 2. A dynamic keystore factory where whoever needs it creates it and whoever rotates it:
[0142] In this application, during the initialization phase, the parsing engine generates or reuses heterogeneous keystores in real time according to policy segments. The keystore type is matched to JKS / PKCS12 or a custom keystore type based on the configuration. This approach eliminates the need for pre-built keystores, allowing new services to immediately obtain independent key spaces and avoiding the risk of leakage caused by key reuse.
[0143] 3. Triple index and memory-mapped table:
[0144] This application establishes a runtime memory mapping table using a composite key consisting of key type, key alias, and keystore name. Business threads can retrieve the key by alias through a standard JCE / CSP interface. In this way, business code is completely unaware of the differences in the underlying algorithm and carrier; only the mapping table needs to be updated when keys are rotated.
[0145] Through the aforementioned differences, this solution achieves a leapfrog improvement in four dimensions: scalability, compliance and agility, operational efficiency and security, which is significantly better than traditional static pre-built solutions.
[0146] It should be noted that traditional solutions typically employ a single encryption algorithm for all sensitive data, failing to achieve an optimal balance between security and system performance. For example, the encryption strength of the algorithm may be insufficient for extremely sensitive data such as ID cards and bank cards; while for generally sensitive data such as names, over-encryption may lead to unnecessary performance degradation. Therefore, in another embodiment of this application, an adaptive encryption strategy based on data sensitivity grading is proposed. This scheme specifically includes the following steps:
[0147] Step 1: Pre-add sensitivity level labels to each data field to be encrypted;
[0148] Specifically, when determining the sensitivity level label, the system can automatically or manually assign a sensitivity level label to each data field to be encrypted based on multiple dimensions such as the data type, compliance requirements (such as the Personal Information Protection Law), and the scope of impact of leakage. For example, L1-low, L2-medium, L3-high, and L4-extremely high. Through this step, different data to be encrypted can be classified, and the higher the level, the stronger the encryption algorithm used.
[0149] Step 2: Establish an algorithm strategy library in advance, which records the mapping relationship between different encryption algorithms and different sensitivity levels; when establishing triple information, establish triple information for different encryption algorithms corresponding to different sensitivity levels.
[0150] Specifically, the different encryption algorithms include: AES-128, AES-256-GCM, SM4, and the Chinese national cryptographic algorithm suite, etc. Then, they are classified according to the security strength and computational cost of different encryption algorithms, and a mapping relationship is established with the corresponding sensitivity level. For example, the higher the level of the encryption algorithm, the higher the security strength and the greater the computational cost. At this time, a mapping relationship is established between the high-level encryption algorithm and the high-level sensitivity level.
[0151] Furthermore, when establishing triplet information, this application needs to establish triplet information corresponding to different encryption algorithms for different sensitivity levels. For example, triplet information corresponding to data transmission categories, including triplet information corresponding to L1, triplet information corresponding to L2, and triplet information corresponding to L3, etc. Since the encryption algorithms for different levels are different, the key aliases corresponding to different triplet information are also different.
[0152] Step 3: When encrypting sensitive data to be processed, find matching target triple information according to the processing category and sensitivity level of the sensitive data to be processed, determine the first key library according to the key library information of the target triple information, and use the key alias of the target triple information to find the corresponding key so as to process the sensitive data to be processed according to the found key.
[0153] Specifically, since the triplet information generated in this application corresponds to different sensitivity levels, when encrypting sensitive data, the system can automatically select the corresponding level of encryption algorithm and key from the policy library based on the sensitivity label of the data field. Because this application allows for custom key lookup using triplet information, it only needs to find the matching target triplet information by specifying the processing category and sensitivity level of the sensitive data. Then, by finding the key alias using the target triplet information, the sensitive data is encrypted. For example, if the sensitivity level of a name is L1, the matching triplet information contains a key alias for a lightweight algorithm, allowing encryption using the lightweight algorithm. Conversely, if the sensitivity level of a bank card number is L4, the matching triplet information contains a key alias for a national cryptographic algorithm, thus forcing the use of the strongest national cryptographic algorithm to encrypt the bank card number.
[0154] In summary, by introducing a dynamic data sensitivity assessment and algorithm adaptive matching mechanism, this application can achieve the following beneficial effects:
[0155] Security is refined: it enables data classification and precise protection, providing the highest level of protection for core assets.
[0156] Performance optimization: It avoids the waste of system resources caused by one-size-fits-all high-strength encryption and improves overall processing efficiency.
[0157] Compliance friendly: The rules are configurable, making it easy for companies to quickly adjust their strategies to meet the compliance requirements of different regions and industries.
[0158] Furthermore, this application considers that systems typically assume third-party cryptographic modules or algorithm libraries are secure and reliable. However, if the key library provider (software library or hardware module) itself has implementation vulnerabilities, has been tampered with, or suffers hardware failure, it will directly cause all encryption operations relying on it to fail or be leaked, creating a systemic risk. Therefore, in another embodiment of this application, a security self-checking function for the key library provider can be implemented. This function specifically includes the following steps:
[0159] Before a keystore provider is used, it undergoes a multi-dimensional self-check. If the self-check results are secure, the keystore provider is allowed to be used.
[0160] The use of a keystore provider can be understood as the keystore provider being used, invoked, or run, such as generating keys through a keystore provider or encrypting sensitive data through a keystore provider. This multi-dimensional self-checking method includes at least one of the following: algorithm correctness testing, random number quality detection, and integrity verification. Each method is explained in detail below:
[0161] (1) Algorithm correctness test: Use known answer self-test, pair consistency test and other schemes to test the correctness of its core operation results such as encryption / decryption, signature / verification.
[0162] (2) Random number quality test: Statistical tests are performed on the generated random numbers to ensure that their randomness meets cryptographic requirements.
[0163] (3) Integrity verification: Verify the integrity of the provider's (especially hardware modules) firmware / software to prevent code tampering.
[0164] In summary, this application achieves the following beneficial effects by implementing a continuous trusted verification and fault isolation mechanism for cryptographic service providers:
[0165] Proactive defense: Shifts from passive trust to proactive verification, enabling immediate detection and response when the provider itself encounters problems.
[0166] Enhanced root of trust: It is particularly suitable for ensuring the reliability of key basic components such as national cryptographic algorithms and security chips, and conforms to the design principles of high-level security systems.
[0167] As can be seen from the above, this application, based on the aforementioned key library generation scheme, has made in-depth extensions to two key aspects: differentiated application of encryption algorithms and trusted verification of cryptographic providers, thus enabling the construction of a more intelligent and proactive security protection system.
[0168] The generation apparatus provided in the embodiments of this application is described below. The generation apparatus described below can be referred to in correspondence with the generation method described above.
[0169] See Figure 3 , Figure 3 This application provides a schematic diagram of a keystore generation device, which specifically includes:
[0170] The acquisition module 11 is used to acquire the initial strategy file; wherein, the initial strategy file includes various attribute variables and sensitive data processing sections of various types, and each sensitive data processing section declares the business sensitive data processing category, algorithm type and key alias;
[0171] The attribute value determination module 12 is used to determine the attribute values of each attribute variable in the initial strategy file;
[0172] The first generation module 13 is used to generate an instantiated strategy based on the initial strategy file and the attribute values of each attribute variable.
[0173] The first creation module 14 is used to create a first keystore using the instantiation strategy;
[0174] The second generation module 15 is used to generate triplet information of the first key library; the first key library includes keys corresponding to each sensitive data processing segment, and the triplet information of each key includes: algorithm type, key alias and key library information;
[0175] The storage module 16 is used to store the triplet information of each key so that the corresponding key can be obtained from the first key library based on the triplet information to process sensitive data.
[0176] As an optional embodiment, the attribute value determination module is specifically used for:
[0177] Check if there are user-inputted custom attribute values;
[0178] If it exists, the custom attribute value will be used as the attribute value of each attribute variable in the initial strategy file; if it does not exist, the default attribute value will be used as the attribute value of each attribute variable.
[0179] As an optional embodiment, the first generation module includes:
[0180] The replacement unit is used to replace the placeholders corresponding to each attribute variable in the initial policy file with the corresponding attribute values; wherein, the attribute values include basic keystore information and algorithm type selection information for sensitive data processing segments; the basic keystore information includes: keystore provider, keystore type, and keystore name;
[0181] The determining unit is used to select information based on the algorithm type to determine the algorithm type of each sensitive data processing segment, thereby generating an instantiation strategy.
[0182] As an optional embodiment, the determining unit is specifically used for:
[0183] If the algorithm type selection information is commercial cryptographic algorithm, then the algorithm type of the sensitive data processing segment is set to commercial cryptographic algorithm so that when the first key store is created, the key of the sensitive data processing segment is created according to the commercial cryptographic algorithm;
[0184] If the algorithm type selection information is a non-commercial cryptographic algorithm, then the algorithm type of the sensitive data processing segment is set to a non-commercial cryptographic algorithm so that when creating the first key library, the key for the sensitive data processing segment is created according to the non-commercial cryptographic algorithm.
[0185] As an optional embodiment, the device further includes:
[0186] The category determination module is used to determine the processing category of the sensitive data to be processed;
[0187] The matching module is used to match the processing category with the algorithm type of each triplet information to find target triplet information with the same processing category;
[0188] The lookup module is used to determine the first key library based on the key library information of the target triplet information, and to look up the corresponding key using the key alias of the target triplet information, so as to process the sensitive data to be processed according to the found key.
[0189] As an optional embodiment, the category determination module is specifically used to: determine the processing category based on the processing scenario of the sensitive data to be processed; wherein the processing category is at least one of the following: data transmission category, data storage category, and data integrity verification category.
[0190] As an optional embodiment, the device further includes:
[0191] The receiving module is used to receive attribute value modification instructions;
[0192] The modification module is used to modify the attribute value of the corresponding attribute variable in the instantiation strategy according to the attribute value modification instruction, so as to obtain the modified instantiation strategy.
[0193] The second creation module is used to create a target working domain, and within the target working domain, a second keystore is created using the modified instantiation strategy.
[0194] The third generation module is used to generate triplet information for each key in the second key library and store the triplet information for each key in a memory mapping table.
[0195] Figure 4 A structural diagram of an electronic device provided in an embodiment of the present invention, such as... Figure 4 As shown, it includes:
[0196] Memory 20 is used to store computer programs;
[0197] The processor 21 is configured to execute a computer program to implement the steps of the key library generation method as described in the above embodiments.
[0198] The electronic devices provided in this embodiment may include, but are not limited to, smartphones, tablets, laptops, or desktop computers.
[0199] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.
[0200] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of the keystore generation method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc.
[0201] In some embodiments, the electronic device may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.
[0202] Those skilled in the art will understand that Figure 4 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.
[0203] In another exemplary embodiment, a computer storage medium is also provided, wherein the program instructions, when executed by a processor, implement the steps of the data deduplication method described in any of the above method embodiments.
[0204] It is understood that if the keystore generation method in the above embodiments is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drive, mobile hard drive, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, magnetic disk, or optical disk, and other media capable of storing program code.
[0205] The various embodiments described in this specification are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” used herein may also mean the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a specific order described or illustrated, unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.
[0206] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures 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, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.
[0207] The above are only some embodiments of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.
Claims
1. A method for generating a keystore, characterized in that, The generation method includes: Obtain the initial policy file; wherein, the initial policy file includes various attribute variables and sensitive data processing sections of various types, and each sensitive data processing section declares the business sensitive data processing category, algorithm type and key alias; Determine the attribute values of each attribute variable within the initial strategy file; Based on the initial strategy file and the attribute values of each attribute variable, an instantiated strategy is generated; A first key store is created using the instantiation strategy, and triplet information of the first key store is generated; the first key store includes keys corresponding to each sensitive data processing segment, and the triplet information of each key includes: algorithm type, key alias and key store information; The triplet information of each key is stored so that the corresponding key can be obtained from the first key library based on the triplet information to process sensitive data.
2. The generation method as described in claim 1, characterized in that, Determine the attribute values of each attribute variable within the initial strategy file, including: Check if there are user-inputted custom attribute values; If it exists, the custom attribute value will be used as the attribute value of each attribute variable in the initial strategy file; if it does not exist, the default attribute value will be used as the attribute value of each attribute variable.
3. The generation method as described in claim 1, characterized in that, Based on the initial strategy file and the attribute values of each attribute variable, an instantiation strategy is generated, including: Replace the placeholders corresponding to each attribute variable in the initial policy file with the corresponding attribute values; wherein, the attribute values include basic keystore information and algorithm type selection information for sensitive data processing sections; the basic keystore information includes: keystore provider, keystore type, and keystore name; Based on the algorithm type selection information, the algorithm type of each sensitive data processing segment is determined, thereby generating an instantiation strategy.
4. The generation method as described in claim 3, characterized in that, Based on the algorithm type selection information, the algorithm type for each sensitive data processing segment is determined as follows: If the algorithm type selection information is commercial cryptographic algorithm, then the algorithm type of the sensitive data processing segment is set to commercial cryptographic algorithm so that when the first key store is created, the key of the sensitive data processing segment is created according to the commercial cryptographic algorithm; If the algorithm type selection information is a non-commercial cryptographic algorithm, then the algorithm type of the sensitive data processing segment is set to a non-commercial cryptographic algorithm so that when creating the first key library, the key for the sensitive data processing segment is created according to the non-commercial cryptographic algorithm.
5. The generation method as described in claim 1, characterized in that, Based on the triplet information, the processing of sensitive data by obtaining the corresponding key pair from the first key library includes: Determine the processing category of the sensitive data to be processed; The processing category is matched with the algorithm type of each triplet information to find target triplet information with the same processing category; The first key library is determined based on the key library information of the target triplet information, and the corresponding key is found using the key alias of the target triplet information so that the sensitive data to be processed can be processed according to the found key.
6. The generation method as described in claim 5, characterized in that, The processing categories for sensitive data to be processed include: Determine the processing category based on the processing scenario of the sensitive data to be processed; The processing category is at least one of the following: data transmission category, data storage category, and data integrity verification category.
7. The generation method according to any one of claims 1 to 6, characterized in that, The generation method further includes: Receive attribute value modification instructions; According to the attribute value modification instruction, the attribute value of the corresponding attribute variable in the instantiation strategy is modified to obtain the modified instantiation strategy; Create a target working domain, and within the target working domain, create a second keystore using the modified instantiation strategy; Generate triplet information for each key in the second key library and store the triplet information for each key in a memory mapping table.
8. A keystore generation apparatus, characterized in that, The generating apparatus includes: The acquisition module is used to acquire the initial policy file; wherein, the initial policy file includes various attribute variables and sensitive data processing sections of various types, and each sensitive data processing section declares the business sensitive data processing category, algorithm type and key alias; The attribute value determination module is used to determine the attribute values of each attribute variable in the initial strategy file; The first generation module is used to generate an instantiated strategy based on the initial strategy file and the attribute values of each attribute variable. The first creation module is used to create a first keystore using the instantiation strategy; The second generation module is used to generate triplet information of the first key library; the first key library includes keys corresponding to each sensitive data processing segment, and the triplet information of each key includes: algorithm type, key alias and key library information; The storage module is used to store the triplet information of each key, so that the corresponding key can be obtained from the first key library based on the triplet information to process sensitive data.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the keystore generation method as described in any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the keystore generation method as described in any one of claims 1 to 7.