Secret key generation and secret key processing method, system and device based on front end

Abstract

The invention discloses a method, a system and a device for key generation and key processing based on a front end, which are used for improving data security and system flexibility. The method comprises the steps that an encryption algorithm library is initialized, and the encryption algorithm library is integrated in a front-end environment and comprises encryption algorithms of at least two different key types; after a first user instruction is received, calling a corresponding encryption algorithm in an encryption algorithm library according to the first user instruction to generate a key; and after a second user instruction is received, performing a signature adding and verification operation, a format conversion operation or a key management operation on the key according to the second user instruction.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data security, and particularly relates to a method, system and device for key generation and key processing based on a front end. BACKGROUND

[0002] In the digital era, data as a core production factor, its security is directly related to personal privacy protection, enterprise business interests and even national information security, and key generation and signature verification as the core link of data security protection is a key technical means to protect data integrity, confidentiality and non-repudiation.

[0003] The current key processing and signature verification system usually adopts the traditional architecture of client and server interaction. Among them, the key generation, signature operation, signature verification and other core operations mostly rely on the server of the back end to complete, which makes the data need to be transmitted between the client of the front end and the server of the back end through the network, and the data is easy to be attacked or stolen in the transmission process, resulting in the decline of data security. SUMMARY

[0004] In order to solve the above technical problems, the present application provides a method, system and device for key generation and key processing based on a front end, which is used to improve data security and system flexibility.

[0005] The technical solutions provided in the present application are described as follows: The first aspect of the present application provides a method for key generation and key processing based on a front end, which comprises: Initializing an encryption algorithm library, the encryption algorithm library is integrated in a front end environment and contains at least two different encryption algorithms of different key types; After receiving a first user instruction, calling a corresponding encryption algorithm in the encryption algorithm library according to the first user instruction to generate a key; After receiving a second user instruction, performing a signature verification operation, a format conversion operation or a key management operation on the key according to the second user instruction.

[0006] Optionally, the step of calling a corresponding encryption algorithm in the encryption algorithm library according to the first user instruction to generate a key comprises: Determining a key type and a key parameter according to the first user instruction, the key parameter including a key format and a key length; Based on the key type and the key parameter, calling a corresponding encryption algorithm in the encryption algorithm library to generate a key.

[0007] Optionally, after the corresponding encryption algorithm in the encryption algorithm library is invoked according to the first user instruction to generate a key, before the key is subjected to a signature verification operation, a format conversion operation or a key management operation according to the second user instruction, the method further comprises: checking whether a key parameter of the key meets a parameter requirement of the corresponding encryption algorithm; if yes, temporarily storing the key in the memory.

[0008] Optionally, the signature verification operation performed on the key according to the second user instruction comprises: when the second user instruction is a signature request, matching a signature version according to the signature request; matching the key to a corresponding signature process according to the signature version; after the signature process ends, matching the key to a corresponding verification process according to the signature version.

[0009] Optionally, after the key is matched to the corresponding verification process according to the signature version, the method further comprises: when a third user instruction is received, performing the format conversion operation or the key management operation on the key according to the third user instruction.

[0010] Optionally, the format conversion operation performed on the key according to the second user instruction comprises: when the second user instruction is a format conversion request, determining a format conversion type of the key according to the format conversion request; performing format checking on the key according to the format conversion type; identifying a key type of the key that passes the format checking; performing the format conversion operation according to the format conversion type and the key type.

[0011] Optionally, the key management operation comprises saving the key, querying the key and clearing the key.

[0012] The second aspect of the application provides a system for key generation and key processing based on a front end, the system comprising: an initialization unit configured to initialize an encryption algorithm library, the encryption algorithm library being integrated in a front end environment and comprising at least two encryption algorithms of different key types; a first execution unit configured to, after receiving a first user instruction, invoke a corresponding encryption algorithm in the encryption algorithm library according to the first user instruction to generate a key; The second execution unit is configured to perform a signing and verifying operation, a format conversion operation or a key management operation on the key according to a second user instruction after receiving the second user instruction.

[0013] Optionally, the first execution unit is specifically configured to: determine a key type and a key parameter according to the first user instruction, the key parameter including a key format and a key length; invoke a corresponding encryption algorithm in the encryption algorithm library based on the key type and the key parameter to generate a key.

[0014] Optionally, the device further includes a verification unit, which is specifically configured to: verify whether the key parameter of the key meets a parameter requirement of the corresponding encryption algorithm; if yes, temporarily store the key in the memory.

[0015] Optionally, the second execution unit is specifically configured to: when the second user instruction is a signing request, match a signing version according to the signing request; match the key to a corresponding signing process according to the signing version; after the signing process ends, match the key to a corresponding verifying process according to the signing version.

[0016] Optionally, the device further includes a third execution unit, which is specifically configured to: when a third user instruction is received, perform the format conversion operation or the key management operation on the key according to the third user instruction.

[0017] Optionally, the second execution unit is specifically configured to: when the second user instruction is a format conversion request, determine a format conversion type of the key according to the format conversion request; perform format verification on the key according to the format conversion type; identify a key type of the key that passes the format verification; perform the format conversion operation according to the format conversion type and the key type.

[0018] Optionally, the key management operation includes saving the key, querying the key and clearing the key.

[0019] The third aspect of the present application provides a device for key generation and key processing based on a front end, the device including: a processor, a memory, an input and output unit and a bus; The processor is connected with the memory, the input and output unit and the bus; The memory stores a program, and the processor invokes the program to execute the method of the first aspect and any optional aspect of the first aspect.

[0020] The fourth aspect of the present application provides a computer readable storage medium, which stores a program, and the program executes the method of the first aspect and any optional aspect of the first aspect when executed on a computer.

[0021] From the above technical solutions, the present application has the following beneficial effects: First, initialize the encryption algorithm library integrated in the front-end environment and containing at least two different key type encryption algorithms, call the corresponding encryption algorithm in the encryption algorithm library through the first user instruction to generate the key, and further execute the signing and verification operation, format conversion operation or key management operation after receiving the second user instruction. The entire key generation and key processing process is completed in the front-end environment, without the need to rely on the participation of the back-end server, avoiding the security risks such as data leakage that may occur in the transmission process of the key data between the front-end and the back-end, and improving the data security. At the same time, the encryption algorithm library contains at least two different key type encryption algorithms, which can meet the encryption needs of different scenes, and also improves the flexibility and data security. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the present application, the drawings needed in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can also be obtained according to these drawings without creative labor for those skilled in the art.

[0023] Figure 1 An embodiment flowchart of the method of key generation and key processing based on the front-end provided by the present application is shown in the figure. Figure 2 An embodiment flowchart of the method of key generation and key processing based on the front-end provided by the present application is shown in the figure. Figure 3 An embodiment flowchart of the method of key generation and key processing based on the front-end provided by the present application is shown in the figure. Figure 4 An embodiment flowchart of the method of key generation and key processing based on the front-end provided by the present application is shown in the figure. Figure 5 An embodiment flowchart of the method of key generation and key processing based on the front-end provided by the present application is shown in the figure. Figure 6 An embodiment structure schematic diagram of a system for front-end based key generation and key processing provided by the present application is provided; Figure 7 An embodiment structure schematic diagram of an apparatus for front-end based key generation and key processing provided by the present application is provided. DETAILED DESCRIPTION

[0024] It should be noted that the method for front-end based key generation and key processing provided by the present application can be applied to a terminal, a system, and a server. For example, the terminal can be a smart phone, a computer, a tablet computer, a smart television, a smart watch, a portable computer terminal, or a fixed terminal such as a desktop computer. For convenience of description, the system is taken as an execution subject for example illustration in the present application.

[0025] Referring to Figure 1 The present application first provides an embodiment of a method for front-end based key generation and key processing, which includes the following steps: S101, initializing an encryption algorithm library, the encryption algorithm library is integrated in a front-end environment, and contains at least two encryption algorithms of different key types; The encryption algorithm library contains a tool set of at least two encryption algorithms of different key types, which is used to support key generation, encryption and decryption, format conversion, and the like. The encryption algorithms in the encryption algorithm library can specifically include the SM2 algorithm of the national cryptography standard and the RSA algorithm commonly used internationally, and the like. Since there are differences in compliance, compatibility, and security requirements of keys in different scenarios, multiple encryption algorithms can be flexibly adapted to various scenarios, avoiding the limitations brought by a single encryption algorithm, thereby improving the versatility and expansibility of the system. Before the encryption algorithm library is called, the encryption algorithm library needs to be initialized, that is, a set of program modules encapsulating encryption-related logic is loaded and configured in the front-end environment, to ensure that all encryption-related operations are completed locally without relying on a back-end server. In this way, security risks such as interception and leakage of key data in network transmission can be avoided, and the dependence on back-end resources can be reduced and the response speed can be improved.

[0026] S102, after receiving a first user instruction, calling a corresponding encryption algorithm in the encryption algorithm library according to the first user instruction to generate a key; After the initialization of the encryption algorithm library is completed, the basic environment for key generation is ready. At this time, if the first user instruction is received, the key generation process can be started. The first user instruction is a specific requirement instruction of the user for key generation, which contains key type and other key data. After the system receives the first user instruction, it will first parse the core parameters in the first user instruction to determine the type of encryption algorithm to be called, then match and call the corresponding encryption algorithm from the initialized encryption algorithm library, and execute the key generation logic according to the parsed parameters. For example, when the first user instruction specifies to generate an SM2 key, the SM2 encryption algorithm in the encryption algorithm library is called. The finally generated key is an asymmetric key pair containing a public key and a private key, and the entire generation process is completed in the front-end environment without the need to interact with the back-end server.

[0027] S103, after receiving the second user instruction, performing a signature verification operation, a format conversion operation or a key management operation on the key according to the second user instruction.

[0028] In actual business scenarios, keys need to be processed in a specific way to meet usage requirements. For example, the original key generated may need to be signed for data verification, or it may need to be converted in format due to system compatibility requirements, or it may need to be temporarily saved for subsequent use. The second user instruction contains specific processing requirements for the generated key, including operation type and corresponding parameters. The operation type mainly includes signature verification operation, format conversion operation or key management operation. The signature verification operation uses the key to digitally sign and verify the validity of the signature to ensure that the data has not been tampered with and is trustworthy during transmission or storage. The format conversion operation converts the key between multiple formats according to the compatibility requirements of different systems or scenarios, solving the problem of key cross-system use caused by format inconsistency. The key management operation is used to locally control the life cycle of the key in the front-end environment.

[0029] In this embodiment, the encryption algorithm library integrated in the front-end environment and containing at least two different key type encryption algorithms is first initialized. The corresponding encryption algorithm in the encryption algorithm library is called through the first user instruction to generate the key. After receiving the second user instruction, the signature verification operation, format conversion operation or key management operation is further executed. The entire key generation and key processing process is completed in the front-end environment without the need to rely on the back-end server, avoiding the security risks such as data leakage that may occur during the transmission of key data between the front-end and back-end, and improving the data security. At the same time, the encryption algorithm library contains at least two different key type encryption algorithms, which can meet the encryption requirements of different scenarios and improve the flexibility and data security.

[0030] In the above step S102, after receiving the first user instruction, the system executes the key generation operation according to the first user instruction, please refer toFigure 2 , Figure 2 An embodiment flow diagram of generating a key in the front-end based key generation and key processing method provided in the present application is shown in the following table. The embodiment includes: S201, determining a key type and a key parameter according to a first user instruction, the key parameter including a key format and a key length; The key type and the key parameter determine that different types of keys correspond to different encryption logics and application scenarios. For example, the SM2 key is suitable for domestic compliance scenarios, and the RSA key is suitable for international general scenarios. If the key type is not clear, the subsequent call of the encryption algorithm will not match the business requirements. The key parameter directly affects the security, compatibility and usability of the key. The lack of specific parameters will cause the generated key to be unable to adapt to the system environment or meet the security standards. The key format contained in the key parameter is mainly used to solve the cross-system compatibility problem of the key. Different systems have different requirements for the encoding format of the key. For example, some systems only support RSA keys in PKCS8 format, while the national secret system usually requires SM2 keys to adopt ASN.1 structure format. Clearly defining the key format can ensure that the generated key can be directly recognized and used by the system. The key length is the core index that determines the encryption strength of the key. For example, the RSA key length can be selected as 1024 bits or 2048 bits. Generally, the longer the key length, the higher the encryption strength. Although the SM2 key has a fixed length specification, it needs to strictly follow the national secret standard. Determining the key length can ensure that the security level of the key matches the risk level of the business scenario.

[0031] S202, based on the key type and the key parameter, calling a corresponding encryption algorithm in an encryption algorithm library to generate a key.

[0032] After the key type and the key parameter are clear, the system will match and call the corresponding encryption algorithm from the initialized encryption algorithm library. The called encryption algorithm will execute the generation logic according to the determined key format and key length, such as PEM key format using Base64 encoding with header identification, DER key format being binary encoding, ensuring that the key can be correctly parsed by the target system. The key length directly affects the operation process of the algorithm, such as the 2048-bit length of RSA corresponding to a specific large prime number generation rule, and SM2 generating a fixed length key pair according to the national secret standard, ensuring that the encryption strength of the key meets the security requirements.

[0033] In this embodiment, the user's requirements are converted into specific technical indicators, the key type and the key parameter are clear, and then the corresponding algorithm in the encryption algorithm library is called to implement the generation logic according to the parameters, so that the key matches the business scenario. At the same time, through the built-in logic of the encryption algorithm library, the normativity of the generation process is ensured, and finally a safe, compatible and usable key is generated in the front-end environment, laying a foundation for subsequent signing and signature verification, format conversion and other operations.

[0034] In practical applications, after the key is generated, it is necessary to verify whether the key meets the expected target, so as to facilitate subsequent operations on the key. Please refer to Figure 3 , Figure 3 An embodiment of the method for verifying the key provided in the front-end based key generation and key processing of the present application is shown in the flowchart, and the embodiment includes: S301, verifying whether the key parameter of the key meets the parameter requirement of the corresponding encryption algorithm; In the key generation process, the key may be affected by factors such as algorithm call bias and parameter analysis error, resulting in that the actual generated key parameter does not meet the expectation, for example, the RSA key of 2048 bits may be insufficient due to abnormal operation, or the SM2 key format does not strictly follow the national standard, and if the key is directly used for subsequent operations, problems such as signature verification failure may occur, and the key with non-compliant parameters will reduce the encryption strength and bring data leakage risk, so hidden dangers need to be excluded in advance through verification. After the key is generated, the system first extracts the key parameter of the generated key, then calls the encryption algorithm corresponding to the key type in the encryption algorithm library to obtain the preset standard parameter requirement, and finally confirms whether the actual key parameter completely meets the standard parameter requirement through automatic comparison.

[0035] S302, if yes, temporarily storing the key in the memory.

[0036] When the actual key parameter meets the parameter requirement of the corresponding encryption algorithm, it indicates that the key passes the verification, and the key that passes the verification is temporarily stored in the memory of the front-end environment, instead of being transmitted to the back-end server or persistent storage, so as to facilitate quick retrieval of the key from the memory when the system receives a second user instruction, and further operations such as signature verification and format conversion are performed on the key.

[0037] In some specific embodiments, the key management operation includes saving the key, querying the key, and clearing the key.

[0038] Before receiving the second user instruction, the key is only temporarily stored in the memory, providing decision space for the user, who can select to perform signature verification and format conversion operations according to the needs, or can select to perform key management operations on the key, including saving the key, querying the key, and clearing the key. If the current key needs to be used for a long time, the key can be stored in the front-end secure storage area in an encrypted form by saving the key; if the key information needs to be confirmed, the key basic attributes in the memory can be retrieved by querying the key; if the key is no longer used or there is a security concern, the user can choose to clear the current key or regenerate the key, thereby improving the flexibility and response efficiency of the system.

[0039] In actual verification, there are also cases of verification failure. If the key parameter does not meet the parameter requirements of the corresponding encryption algorithm, the system will generate a verification failure prompt, which will contain specific failure reasons, such as key format error, key length error, or key pair mismatch, etc. At the same time, the system will delete the generated key, so as to facilitate the user to select to regenerate the key.

[0040] In this embodiment, by verifying whether the parameters of the generated key meet the standard requirements of the corresponding encryption algorithm, the key non-compliance problem caused by algorithm call deviation, parameter analysis error, etc. is excluded in advance, reducing the risk of subsequent operation failure and data leakage. The verified key is temporarily stored in the front-end memory, which not only facilitates quick retrieval when performing subsequent operations, but also reserves decision space for the user. When the verification fails, the system will prompt the reason and delete the invalid key, guiding to regenerate, which not only ensures the compliance and security of the key, but also improves the flexibility and reliability of the system operation.

[0041] In the above step S103, the second user instruction can be a request to perform a signing and verifying operation, a format conversion operation, or a key management operation. When the second user instruction is a signing and verifying request, the key needs to be matched to the corresponding signing and verifying process according to the signing and verifying request, so that the signature data matches the expected business scenario. Please refer to Figure 4 , Figure 4 An embodiment flowchart of a signing and verifying method based on the front-end key generation and key processing provided in this application is provided, which includes: S401, when the second user instruction is a signing and verifying request, matching the signing version according to the signing and verifying request; In the signing and verifying operation, different business scenarios have different requirements for the algorithm specification, security level, and compatibility of the signature. If the signing rules are not clear and unified, subsequent signing and verifying may fail due to incompatible standards. When the system receives a second user instruction that is a signing and verifying request, the system needs to first analyze the key information contained in the signing and verifying request, which may include business scenario attributes, security level requirements, target system compatibility, etc. Then, the system will match the corresponding signing version for the key according to these information, including V4 signing version, V5 signing version, etc.

[0042] S402, matching the key to the corresponding signing process according to the signing version; After the signing version is determined, the signature is generated by relying on the corresponding signing process. For example, the V4 signing version corresponds to the SM2 With RSA process, and the data is signed in the order of parameter standardization, SHA256 hash verification, RSA private key encryption, and Base64 encoding to generate signature data. The V5 signing version corresponds to the SM2 With SM3 process, and the key is signed in the order of PEM to HEX, SM3 hash verification, SM2 private key signature, and DER+Base64 encoding to generate signature data.

[0043] S403, after the signing process is completed, the key is matched to the corresponding verification process according to the signing version.

[0044] After the signing process generates the signature data, the authenticity and data integrity of the signature need to be verified by the verification operation. The rules of the verification process must be consistent with the signing version. If the signing uses the V4 version, the verification also needs to use the same version of the process, otherwise the verification will fail due to algorithm and format differences. Therefore, after the signing process is completed, the system will call the corresponding verification process according to the determined signing version to complete the matching of the signing version and the verification process. For example, for the V4 signing version, it is matched to the V4 version verification process, the RSA public key paired with the private key during signing is called first to verify the format compliance of the public key, then the Base64 encoded signature data output by the signing is decoded to restore the binary hash value encrypted by RSA, the original data obtained during verification is re-executed SHA256 hash operation to generate a verification reference hash value, and finally the decoded binary hash value is decrypted by the RSA public key to obtain the original hash value generated during signing. The original hash value obtained by decryption is compared with the verification reference hash value. If they are consistent, the verification is successful, and if they are not consistent, the verification fails. For the V5 signing version, it is matched to the V5 version verification process, the SM2 public key paired with the signing private key is called first to perform PEM to HEX format conversion, then the original data is re-calculated SM3 hash digest as a verification reference, and the signature data generated by the signing is sequentially decoded by Base64 and DER. The original SM3 hash value during signing is obtained by decrypting the converted SM2 public key. Finally, the original hash value and the reference hash value are compared. If they are consistent, the verification is successful, and if they are not consistent, the verification fails. At the same time, the DER structure of the signature data will be additionally verified for compliance. If the structure is abnormal, it is directly determined as failed. When the verification fails, a verification failure prompt is generated, which contains the specific reasons for the failure, such as hash value mismatch, public key format error, etc. The user can clear the data and re-verify according to the verification failure prompt, or ignore the verification process and continue to select and execute the subsequent format conversion operation or key management operation.

[0045] In some specific embodiments, after matching the key to the corresponding signature verification process according to the signing version, when receiving a third user instruction, a format conversion operation or a key management operation is performed on the key according to the third user instruction.

[0046] When the system completes the matching of the key to the corresponding signature verification process according to the signing version, it enters a subsequent operation waiting state. The user can select to perform a format conversion operation or a key management operation on the key according to needs, or first select to perform a format conversion operation and then perform a key management operation, so that the key processing is no longer limited to a single flow of signature verification, flexible subsequent operations are added, and the scene adaptability of key use is improved.

[0047] In this embodiment, the V4 signing version or the V5 signing version is first matched according to the service scene, security level and other information in the request, then the key is matched to the SM2 With RSA signing process or the SM2 With SM3 signing process to generate signature data according to the signing version, and finally the verification is completed according to the matching of the signature verification process according to the signing version, and when the signature verification fails, the specific reason is prompted and the user is supported to flexibly select subsequent operations. The version anchor is used to ensure that the signing and verification rules are unified, and the verification failure caused by incompatible standards is avoided. After the signature verification process is completed, the key format conversion and management operation are supported through the third user instruction, so that the key processing is more suitable for actual business. The whole process not only guarantees the authenticity of the signature, the data integrity and the operation safety, but also adapts to different business scene needs, and through the failure prompt and flexible operation options, the practicality, reliability and operation efficiency of the system are improved.

[0048] When the second user instruction is a format conversion request, the corresponding format conversion operation is performed on the key according to the format conversion request to improve the security of the key. Please refer to Figure 5 , Figure 5 An embodiment flowchart of a format conversion in a method for key generation and key processing based on a front end provided in the present application is provided, and the embodiment includes: S501, when the second user instruction is a format conversion request, determining the format conversion type of the key according to the format conversion request; In the process of key usage, different scenarios have different requirements for key formats. For example, front-end configuration often requires PEM format, while hardware device interaction relies on HEX format. If the formats do not match, the key cannot be used normally. When the system receives a second user instruction in the form of a format conversion request, the system needs to first parse the key information contained in the request, which includes specific parameters such as target usage scenario, downstream system interface requirements, and user-specified format target. Then, the system will determine the format conversion type based on the key information, such as converting PEM format to HEX format, i.e., converting text format with identifier to hexadecimal string; converting HEX format to PEM format, i.e., converting hexadecimal string to text format with standard identifier, etc.

[0049] S502, format verification of the key according to the format conversion type; Before format conversion, it is necessary to verify whether the original key format meets the conversion requirements. If the original format has errors or the original format does not match the format conversion type in the format conversion request, the converted key may be invalid. After determining the format conversion type, the system will perform targeted format verification on the key according to the format conversion type. If it is PEM format to HEX format, it will verify whether the original PEM format key contains complete header and tail identifiers, etc. If it is HEX format to PEM format, it will verify whether the original HEX format key contains characters from 0 to 9 and a to f, and whether the length is even. Then the system performs data conversion processing on the key that passes the format verification, including Base64 decoding, byte stream conversion, and encoding processing, etc.

[0050] S503, identifying the key type of the key that passes the format verification; Because the format structure and length of different key types are different, using a unified format conversion logic will destroy the core data of the key, so the conversion logic needs to match the key type. After the format verification, the system will further identify the key type and confirm the key type, such as parsing the algorithm identifier in the PEM format after Base64 decoding, the length and structure characteristics of the HEX format, and determining whether the key belongs to SM2 or RSA type.

[0051] S504, performing format conversion operation according to the format conversion type and the key type.

[0052] After the format conversion type and the key type are determined, the system calls corresponding conversion logic to perform the format conversion operation. If the key type is SM2, intelligent length detection is performed first to verify whether the length of the byte stream in the conversion process meets the SM2 key standard. If there is a slight deviation, dynamic random padding is used to supplement the compliant bytes. Then the ASN.1 structure is reconstructed to ensure that necessary nodes such as algorithm identifier and private key data segment are included. Finally, accurate data extraction is performed to filter redundant information and output the target format data. If the key type is RSA, the format identification is used to determine the PKCS specification that the RSA key complies with. Then the structure is parsed according to the corresponding specification to extract core parameters such as public key exponent and private key exponent, and the correlation between the parameters is preserved synchronously. Finally, the target format data is output.

[0053] After the format conversion, the key is also subjected to format reconstruction and packaging. For the SM2 key, the complete national secret ASN.1 structure is reconstructed. For the RSA key, the standard binary format is packaged according to the identified PKCS specification. At the same time, if the target format of the conversion format is PEM, the corresponding type of header and tail markers is automatically added, and intelligent formatting is performed according to the 64-character line break rule. Finally, the legality of the converted format is verified to ensure the effectiveness of the output key.

[0054] In this embodiment, the corresponding format conversion operation is performed on the key by confirming the format conversion type and the key type of the key. Intelligent key length processing, dynamic random padding, and intelligent PEM formatting are used in the format conversion process, which reduces the format errors that may be caused by manual operation and improves the fault tolerance and security. Finally, the key after the format conversion is packaged accordingly, so that the converted key meets the target format specification and improves the integrity and reliability of the key.

[0055] Please refer to Figure 6 The application also provides a system for key generation and key processing based on a front end, which comprises: An initialization unit 601 is configured to initialize an encryption algorithm library, the encryption algorithm library is integrated in a front-end environment, and contains at least two encryption algorithms of different key types; A first execution unit 602 is configured to call a corresponding encryption algorithm in the encryption algorithm library according to a first user instruction to generate a key after receiving the first user instruction. A second execution unit 603 is configured to perform a signing and verification operation, a format conversion operation, or a key management operation on the key according to a second user instruction after receiving the second user instruction.

[0056] Optionally, the first execution unit 602 is specifically configured to: determine the key type and key parameters according to the first user instruction, the key parameters including the key format and the key length; Based on the key type and the key parameter, a corresponding encryption algorithm in the encryption algorithm library is called to generate the key.

[0057] Optionally, the device further includes a checking unit 604, specifically configured to: check whether the key parameter of the key meets the parameter requirement of the corresponding encryption algorithm; if yes, temporarily store the key in the memory.

[0058] Optionally, the second execution unit 603 is specifically configured to: when the second user instruction is a signing and verifying request, match the signing version according to the signing and verifying request; match the key to the corresponding signing process according to the signing version; after the signing process ends, match the key to the corresponding verifying process according to the signing version.

[0059] Optionally, the device further includes a third execution unit 605, specifically configured to: when receiving the third user instruction, perform a format conversion operation or a key management operation on the key according to the third user instruction.

[0060] Optionally, the second execution unit 603 is specifically configured to: when the second user instruction is a format conversion request, determine the format conversion type of the key according to the format conversion request; perform format checking on the key according to the format conversion type; identify the key type of the key that passes the format checking; perform the format conversion operation according to the format conversion type and the key type.

[0061] Optionally, the key management operation includes saving the key, querying the key, and clearing the key.

[0062] The embodiments are described in detail with reference to the drawings Figures 1 to 5 Embodiments are not described here.

[0063] Please refer to Figure 7 The application further provides a device for generating and processing keys based on a front end, including: a processor 701, a memory 702, an input and output unit 703, and a bus 704; the processor 701 is connected with the memory 702, the input and output unit 703, and the bus 704; the memory 702 stores a program, and the processor 701 calls the program to execute any of the above methods.

[0064] The application also relates to a computer readable storage medium, which stores a program. When the program is run on a computer, the computer is caused to execute any of the above methods.

[0065] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the foregoing method embodiments, which will not be described here.

[0066] In the several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other manners. For example, the described device embodiments are merely schematic. The division of the units is merely a logical function division. There can be another division manner for the actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between the units can be indirect couplings or communication connections through some interfaces, devices or units, and can be electrical, mechanical or in other forms.

[0067] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, can be located in one place, or can be distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0068] In addition, each functional unit in the embodiments of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be implemented in the form of hardware, or in the form of software functional units.

[0069] The integrated unit, if implemented in the form of software functional units and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such an understanding, the technical solutions of the present application essentially or the part that makes a contribution to the prior art, or all or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

Claims

1. A method of front-end based key generation and key handling, characterized by, The method comprises: initializing an encryption algorithm library, the encryption algorithm library being integrated in a front-end environment and containing encryption algorithms of at least two different key types; after receiving a first user instruction, calling a corresponding encryption algorithm in the encryption algorithm library according to the first user instruction to generate a key; after receiving a second user instruction, performing a signature verification operation, a format conversion operation or a key management operation on the key according to the second user instruction.

2. The method of claim 1, wherein, The calling of the corresponding encryption algorithm in the encryption algorithm library according to the first user instruction to generate a key comprises: determining a key type and a key parameter according to the first user instruction, the key parameter comprising a key format and a key length; based on the key type and the key parameter, calling a corresponding encryption algorithm in the encryption algorithm library to generate a key.

3. The method of claim 1, wherein, After the calling of the corresponding encryption algorithm in the encryption algorithm library according to the first user instruction to generate a key, before the performing of the signature verification operation, the format conversion operation or the key management operation on the key according to the second user instruction, the method further comprises: checking whether the key parameter of the key meets the parameter requirement of the corresponding encryption algorithm; if yes, temporarily storing the key in the memory.

4. The method of claim 1, wherein, The performing of the signature verification operation on the key according to the second user instruction comprises: when the second user instruction is a signature verification request, matching a signature version according to the signature verification request; matching the key to a corresponding signature process according to the signature version; after the signature process ends, matching the key to a corresponding verification process according to the signature version.

5. The method of claim 4, wherein, After the matching of the key to the corresponding verification process according to the signature version, the method further comprises: when a third user instruction is received, performing the format conversion operation or the key management operation on the key according to the third user instruction.

6. The method of claim 1, wherein, The performing of the format conversion operation on the key according to the second user instruction comprises: when the second user instruction is a format conversion request, determining a format conversion type of the key according to the format conversion request; performing format checking on the key according to the format conversion type; identifying a key type of the key that passes the format checking; performing the format conversion operation according to the format conversion type and the key type.

7. The method according to any one of claims 1 to 6, characterized in that, The key management operation comprises saving the key, querying the key and clearing the key.

8. A system for front-end based key generation and key handling, characterized by The system comprises: an initialization unit configured to initialize an encryption algorithm library, the encryption algorithm library being integrated in a front-end environment and containing encryption algorithms of at least two different key types; a first execution unit configured to, after receiving a first user instruction, call a corresponding encryption algorithm in the encryption algorithm library according to the first user instruction to generate a key; a second execution unit configured to, after receiving a second user instruction, perform a signature verification operation, a format conversion operation or a key management operation on the key according to the second user instruction.

9. An apparatus for front-end based key generation and key handling, the apparatus comprising: The apparatus comprises: a processor, a memory, an input output unit and a bus. The processor is connected with the memory, the input / output unit and the bus; The memory stores a program, and the processor invokes the program to execute the method in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a program, and the program executes the method in any one of claims 1 to 7 when executed on a computer.

Images