A cryptographic grammar signature method, a server, an encryption end and related devices

Abstract

The application discloses a password syntax signature method, a server, an encryption end and related devices, and the method comprises the following steps: the server sends original data to be signed to the encryption end, and constructs a signer information structure according to a preset password syntax standard, wherein a signature value field is arranged in the signer information structure; the encryption end receives the original data to be signed, calculates a hash value according to a preset asymmetric algorithm type, signs the hash value by using a local private key, returns the signature value in an original binary form to the server, and the server receives the signature value and writes the signature value into the signature value field, obtains a complete signer information structure, assembles the complete signer information structure into a signature data object, and finally outputs a signature result.

Description

Technical Field

[0001] This application relates to the field of data security technology, and in particular to a cryptographic signature method, a server, an encryption terminal, and related devices. Background Technology

[0002] In applications such as e-government, e-invoices, secure email, and software digital signatures, cryptographic message syntax signature mechanisms are widely used to ensure data integrity, authenticity of origin, and non-repudiation of operations. As an evolution of Public Key Cryptography Standard 7, cryptographic message syntax has stricter technical requirements in terms of syntax extensibility, multi-algorithm compatibility, customizable signature attributes, and cross-platform interoperability.

[0003] In hardware signature schemes, the entire signature process is typically completed within the encryption machine. This means the encryption machine generates and stores the private key within its hardware security domain and independently performs hash calculations, digital signature operations, and encapsulation of the signature result. Because the plaintext private key does not leave the hardware boundary, it is not exposed to the software environment during storage and use, effectively resisting software-level attacks and ensuring high key security.

[0004] However, the internal logic and output format of encryption machines are usually fixed, and their output signatures generally adopt the public-key cryptography standard VII structure, which cannot directly adapt to the format requirements of the cryptographic message syntax standard. At the same time, due to the fixed hardware logic, when application requirements such as supporting multiple algorithms, multi-signer collaboration, custom signature attributes, or timestamp extensions are needed, they cannot be flexibly implemented through software configuration. Summary of the Invention

[0005] This application provides a cryptographic syntax signature method, a server, an encryption terminal, and related devices. The server sends the original data to be signed to the encryption terminal and constructs a signature data object containing a signature value field. After the encryption terminal returns the signature value, the server writes the signature value field and embeds the signature data object to output the signature result. This solves the technical problem that the output format of existing hardware signature schemes is fixed and cannot adapt to cryptographic message syntax standards.

[0006] The first aspect of this application provides a method for cryptographic signature, applied on a server, the method comprising:

[0007] Send the original data to be signed to the encrypted end; According to the preset cryptographic syntax standard, a signer information structure is constructed, which includes a signature value field. The system receives the signature value returned by the encryption terminal after it has processed the original data to be signed, and writes the signature value into the signature value field to obtain the complete signer information structure. According to the preset cryptographic syntax standard, the complete signer information structure is assembled into a signature data object, and the signature result is output.

[0008] Optionally, writing the signature value into the signature value field to obtain the complete signer information structure includes: Parse the binary encoding of the signature value and verify whether the binary encoding is a valid encoding; When the binary encoding is valid, the signature value is written into the signature value field to obtain the complete signer information structure.

[0009] Optionally, the step of assembling the complete signer information structure into a signature data object according to the preset cryptographic syntax standard and outputting the signature result includes: According to the preset cryptographic syntax standard, the complete signer information structure is assembled into the preset position in the signature data object; The signature data object is serialized according to the differentiation encoding rules to generate a binary signature data string; According to the preset output mode, the binary signature data string is output as a signature result.

[0010] Optionally, the preset output modes include embedded output and discrete output; The embedded output is to encapsulate the original data to be signed into the signature data object before outputting the signature result, and output a signature data object that contains both the original data to be signed and the signature value. The separate output means that only the signature data object is output, and the original data to be signed is stored separately or transmitted independently from the signature data object.

[0011] A second aspect of this application provides a method for cryptographic signature, applied at an encryption end, the method comprising: Receive the raw data to be signed from the server, and calculate the hash value of the raw data to be signed according to the preset asymmetric algorithm type; Obtain the locally stored private key, and use the private key to perform a digital signature operation on the hash value to generate a signature value; The signature value is returned to the server in its original binary form.

[0012] Optionally, calculating the hash value of the original data to be signed according to a preset asymmetric algorithm type includes: Identify a preset asymmetric algorithm type, wherein the preset asymmetric algorithm type includes at least two different asymmetric algorithm types; Based on the preset algorithm correspondence, determine the target hash algorithm that matches the identified asymmetric algorithm type; The target hash algorithm is used to perform a hash operation on the original data to be signed to generate a hash value.

[0013] Optionally, obtaining the locally stored private key and using the private key to perform a digital signature operation on the hash value to generate a signature value includes: Read the private key corresponding to the preset asymmetric algorithm type locally; Based on the preset asymmetric algorithm type, determine the corresponding digital signature algorithm; Using the private key and the determined digital signature algorithm, a digital signature operation is performed on the hash value to obtain the original signature value; The original signature value is encoded according to the encoding rules specified by the digital signature algorithm to generate the signature value to be returned.

[0014] A third aspect of this application provides a cryptographic syntax signature server, comprising: The sending unit is used to send the original data to be signed to the encryption end; The construction unit is used to construct a signer information structure according to a preset cryptographic syntax standard, wherein the signer information structure includes a signature value field; The receiving unit is used to receive the signature value returned by the encryption end after performing signature processing on the original data to be signed, and write the signature value into the signature value field to obtain the complete signer information structure. The output unit is used to assemble the complete signer information structure into a signature data object according to the preset cryptographic syntax standard, and output the signature result.

[0015] The fourth aspect of this application provides a cryptographic syntax signature encryption end, including: The receiving unit is used to receive the original data to be signed from the server and calculate the hash value of the original data to be signed according to a preset asymmetric algorithm type. A signature unit is used to obtain a locally stored private key, and use the private key to perform a digital signature operation on the hash value to generate a signature value; The return unit is used to return the signature value to the server in its original binary form.

[0016] A fifth aspect of this application provides an apparatus for cryptographic syntax signing, the apparatus comprising: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program that the processor invokes to perform a method for signing the first aspect or the second aspect, and any one of the first aspect or the second aspect, using an optional cryptographic syntax.

[0017] As can be seen from the above technical solutions, this application has the following advantages: The encryption end performs hash calculations and digital signature operations within the hardware security domain. The plaintext private key does not leave the hardware boundary, effectively resisting software-level attacks and ensuring the security of the private key throughout its lifecycle. The encryption end only returns the raw signature value and does not perform any encapsulation operations on the cryptographic message syntax structure. This allows the server to independently construct the signer information structure according to the preset cryptographic syntax standard. After receiving the signature value returned by the encryption end and writing it into the signature value field, the server obtains the complete signer information structure. This complete signer information structure is then assembled into a signature data object and the signature result is output, forming a complete conversion link from the raw signature value to the standardized signature structure. When it is necessary to support multiple algorithms, multi-signer collaboration, timestamp extension, or custom signature attributes, it is only necessary to adjust the assembly logic of the signature data object or the construction method of the signer information structure on the server side. No modification to the encryption end hardware is required. This effectively solves the technical problems of the fixed output format and inability to adapt to the cryptographic message syntax standard of existing hardware signature schemes, and takes into account the dual requirements of hardware-level key security and software-level standard adaptation. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating an embodiment of cryptographic syntax signing applied to a server, as provided in this application; Figure 2 A flowchart illustrating an embodiment of outputting signature results in a cryptographic syntax signature applied to a server, as provided in this application; Figure 3 A flowchart illustrating an embodiment of cryptographic syntax signing applied to the encryption end provided in this application; Figure 4 A flowchart illustrating an embodiment of calculating the hash value of the original data to be signed in a cryptographic syntax signature applied to an encrypted end, as provided in this application; Figure 5 A flowchart illustrating an embodiment of generating a signature value in a cryptographic syntax signature applied to an encrypted end, as provided in this application; Figure 6A schematic diagram illustrating the structure of an embodiment of cryptographic syntax signing applied to the server side, as provided in this application; Figure 7 A schematic diagram of the structure of an embodiment of cryptographic syntax signature applied to the encryption end provided in this application; Figure 8 A schematic diagram of one embodiment of the cryptographic syntax signing apparatus provided in this application. Detailed Implementation

[0020] It should be noted that the cryptographic signature method, server, encryption terminal, and related devices provided in this application can be applied to scenarios requiring digital signature protection, such as e-government, e-invoices, secure email, and software digital signatures. In e-government scenarios, government agencies at all levels can sign electronic documents to ensure the authenticity of the document source and the integrity of its transmission. The output results conform to national electronic document archiving standards and can be directly stored long-term in the electronic archive system. In e-invoice scenarios, signature protection can be applied to the invoice information, supporting both embedded and separate output modes to facilitate integration with business processes of different invoice systems. In secure email communication, signature data conforming to the Secure Multipurpose Internet Mail Extensions standard can be generated for signing and encapsulating email content. In software and firmware distribution scenarios, it can be used to sign executable files, installation packages, or firmware upgrade packages, enabling users to verify the trustworthiness of the software source and the integrity of the documents.

[0021] This application first provides an embodiment of a method for cryptographic syntax signing applied to the server side. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 A flowchart illustrating an embodiment of cryptographic syntax signing applied to a server, provided in this application, includes: S101. Send the original data to be signed to the encryption end; The server obtains the original data that needs to be digitally signed and sends it to the encryption terminal. The original data to be signed can be any binary data that requires signature protection, such as electronic documents, structured data from electronic invoices, email content, software installation packages, or firmware images. A secure communication link is pre-established between the server and the encryption terminal. This link enables data exchange through the encryption machine's standard application programming interface, ensuring the confidentiality and integrity of data transmission.

[0022] Before sending the raw data to be signed, no preprocessing operations are performed on the data; that is, no hash calculations, format conversions, or encoding transformations are performed. Instead, the complete binary form of the raw data is directly transmitted to the encryption end. For example, in the scenario of electronic document circulation, the server sends the complete binary data of an approval document to be signed as the raw data to be signed directly to the encryption end through a secure communication link. The encryption end then performs the subsequent hash calculations and signing operations within the hardware security domain.

[0023] S102. Construct a signature data object with a signature value field in accordance with the preset cryptographic syntax standard. The signature data object is constructed according to a pre-defined cryptographic syntax standard, which refers to the cryptographic message syntax standard. This standard defines the overall format of the signature data object and the encoding rules for each component field. A signer information structure is established within this signature data object, and a signature value field is created within this structure. This field is not filled with a specific value at this stage, but is reserved for later writing the signature value returned by the encryption end. The signature data object also includes other fields to carry the signer's identity information, such as a signer identifier field, a digest algorithm field, and a signature algorithm field, which are used by the verifying party to identify the signer's identity and the type of algorithm used when verifying the signature. For example, in an electronic document signature scenario, the signature data object constructed by the server includes a signer identifier field, a digest algorithm field, and a reserved signature value field.

[0024] It should be noted that the server-side construction of the signature data object is independent of the encryption-side signature calculation, and there is no strict order constraint between the two steps. The server can complete the framework construction of the signature data object at any time after sending the original data to be signed to the encryption end and before receiving the signature value returned by the encryption end, ensuring that the signature value field has been created before receiving the signature value.

[0025] S103. Receive the signature value returned by the encryption end after processing the original data to be signed, write the signature value into the signature value field, and obtain the complete signer information structure. The signature value is received from the encryption end via a secure communication link, and the signature value data is read from that link. The length and binary format of the signature value depend on the type of asymmetric algorithm used by the encryption end; different algorithms generate signature values ​​that differ in byte length and internal structure.

[0026] Upon receiving the signature value, the validity of its binary encoding format is first verified. Only after confirming it is valid encoded data is the write operation performed. The verification process specifically includes: first, parsing the binary encoding of the signature value, identifying each component element, and verifying the integrity and legality of the encoding structure layer by layer; then, determining the expected length range of the signature value based on a preset asymmetric algorithm type, and judging whether the length of the received signature value is within the normal range; if the encoding structure of the signature value is complete and the length meets the expectation, the verification is considered successful; otherwise, the verification is considered unsuccessful.

[0027] After successful verification, the server writes the signature value into the signature value field of the signer information structure according to the data type and encoding format requirements defined in the cryptographic message syntax standard. During writing, the server does not perform any format conversion, encoding re-encapsulation, or add encapsulation identifiers to the signature value; instead, it directly fills the received raw binary signature value into this field, thus obtaining the signer information structure containing complete signature information. If verification fails, the signature result is deemed invalid, a signature value exception error is returned to the caller, and the signing process is terminated.

[0028] S104. According to the preset cryptographic syntax standard, assemble the complete signer information structure into a signature data object and output the signature result.

[0029] Following the hierarchical structure defined in the cryptographic message syntax standard, the complete signer information structure is placed as the core component of the signature data object, positioned at a designated location within the object, thus assembling the complete signature data object from the signer information structure. The assembled signature data object is then serialized and encoded according to a distinguishing encoding rule. This rule's basic encoding method involves encoding each data item in the signature data object as a binary fragment consisting of a type identifier, a length value, and a content value, concatenated sequentially. These fragments are then concatenated in their original structural order to form a continuous binary data string. This binary signature data string is the signature result conforming to the cryptographic message syntax standard format.

[0030] The binary signature data string is output according to a preset output mode, which includes two modes: embedded output and separate output. Embedded output means that the original data to be signed is encapsulated into a signature data object before the signature result is output, resulting in a complete signature data object containing both the original data and the signature value. Separate output means that only the signature data object is output, while the original data to be signed and the signature data object are stored separately or transmitted independently. Both output modes can be pre-configured or dynamically selected according to actual business needs.

[0031] The output signature result can be saved as a file or transmitted over a network to the verifier. Upon receiving the signature result, the verifier can verify the signature using a common cryptographic message syntax verification tool. The verification process includes: extracting the signature certificate, original data, and signature value from the signature data object; verifying the legality of the certificate chain; recalculating the hash value of the original data and comparing it with the hash in the signature value to confirm the integrity of the data and the authenticity of the signature. For example, in a software digital signature scenario, the server embeds a signer information structure containing the software installation package hash signature value into the signature data object and outputs a complete cryptographic message syntax signature file. This signature file is distributed along with the software installation package, and users can verify the trustworthiness of the installation package source and the integrity of the file using the operating system's signature verification function during installation.

[0032] In this embodiment, the encryption end performs hash calculations and digital signature operations within the hardware security domain. The plaintext private key does not leave the hardware boundary, which can resist software-level attacks and ensure the security of the private key throughout its entire lifecycle. The encryption end only returns the raw signature value without encapsulating any cryptographic message syntax structure. Before and after receiving the signature value, the server constructs a signature data object according to the cryptographic message syntax standard; after writing the signature value into the signature value field, it embeds the signature data object and outputs the complete signature result. In the entire signature method, key security is guaranteed by hardware, and the output format is adapted by software. When it is necessary to support multiple algorithms, multi-signer collaboration, timestamp extension, or custom signature attributes, the server can adjust the construction logic of the signature data object to achieve this, effectively solving the technical problems of existing hardware signature schemes having a fixed output format and being unable to adapt to cryptographic message syntax standards.

[0033] The signer information structure is embedded into the signature data object, and the signature result is output. The following section explains how to output the signature result; please refer to [link to documentation]. Figure 2 , Figure 2 A flowchart illustrating an embodiment of outputting a signature result in a cryptographic syntax signature applied to a server, provided in this application, includes: S201. According to the preset cryptographic syntax standard, assemble the complete signer information structure into the preset position in the signature data object; Following the hierarchical structure defined in the cryptographic message syntax standard, the complete signer information structure is assembled into the preset positions within the signature data object. The cryptographic message syntax standard specifies the overall structure of the signature data object, where the signer information structure resides at a specific level below the top-level structure, carrying all signature-related information for a single signer. During assembly, the server must ensure that each field in the signer information structure is placed as a complete structural unit into the preset positions within the signature data object, enabling the verifier to correctly locate and read the signer information during parsing. After assembly, the signature data object becomes a complete data object containing top-level structure information, encapsulated content information, and the complete signer information structure.

[0034] S202. Serialize the signature data object according to the distinguishing encoding rules to generate a binary signature data string; The complete signature data object, after embedding the signer information structure, is serialized and encoded. Distinguishing encoding rules is an encoding method that converts structured data into a binary byte stream. Its basic rule is: each data item in the data object is encoded as a binary fragment consisting of a type identifier, a length value, and a content value, which are then concatenated sequentially. All binary fragments are then concatenated according to their original order in the structure to form a continuous binary string. Different types of fields use corresponding type labels during encoding, and the length value is determined based on the actual length of the content value.

[0035] Specifically, the signature data object contains multiple levels and fields, and each field is encoded layer by layer from the inside out according to the distinguishing encoding rules. For the signer information structure, the signer identifier field, digest algorithm field, signature algorithm field, and signature value field are encoded first, and then the encoded fields are concatenated in order to form the complete encoding of the signer information structure. For the top-level structure, its version field, digest algorithm set field, encapsulated content information field, and the already encoded signer information structure are concatenated and encoded in order to finally generate a complete binary signature data string.

[0036] S203. Output the binary signature data string as a signature result according to the preset output mode.

[0037] The server generates a binary signature data string based on a preset output mode and outputs it as the final signature result. There are two output modes: embedded output and separate output. Embedded output refers to encapsulating the original data to be signed into a signature data object before outputting the signature result, outputting a complete signature data object that simultaneously contains the original data to be signed and the signature value. In this mode, based on the generated binary signature data string, the original data to be signed is filled into the encapsulation content information field of the signature data object, making the signature data object a self-contained complete data packet. Upon receiving this signature data object, the verifying party can directly extract the original data and signature value for verification without needing to obtain the original data file separately. This is suitable for scenarios where the signature and original data need to be delivered together, such as electronic document archiving and electronic invoice delivery, where the recipient can obtain both the original content and signature verification information from a single file.

[0038] Separate output refers to outputting only the signature data object, while the original data to be signed is stored or transmitted separately from the signature data object. In this mode, the signature result output by the server does not include the original data; the original data is saved separately or sent to the recipient through other channels. During verification, the verifier needs to obtain both the original data file and the signature data object simultaneously, using both together to complete the verification. This is suitable for system integration scenarios with existing data storage systems, such as in software installation package signing. The installation package itself already has fixed distribution channels and storage locations, and the signature file is distributed as a separate attachment. When the user downloads the package, they obtain both the installation package and the signature file. During verification, the installation package data is used as the original data, and the signature file is used as the verification basis.

[0039] The two output modes can be pre-configured or dynamically selected according to the actual needs of the business scenario. The server executes the corresponding output operation according to the selected mode, either saving the binary signature data string as a file to a specified storage location or transmitting it to the recipient over the network.

[0040] In this embodiment, after the signature value returned by the encryption end is written into the signature value field, the signer information structure is embedded into a preset position in the signature data object according to the cryptographic message syntax standard, so that the original signature value is given a standardized structural context. By serializing the embedded complete signature data object according to the differentiation encoding rules, a binary signature data string is generated, so that the signature result has good interoperability between different platforms and systems. Through two output modes, embedded and separate, the delivery method can be flexibly selected according to the business scenario. It can be packaged with the original data into a complete data package for use in single file scenarios such as electronic document archiving and electronic invoice delivery, or the signature and the original data can be output separately to adapt to the integration needs of existing independent distribution channels such as software installation package signing. It realizes the transformation of the original signature value returned by the encryption end into a complete signature result that conforms to the standard format, has cross-platform universality and scenario adaptability.

[0041] This application also provides an embodiment of a method for cryptographic syntax signing applied to an encrypted end; please refer to [link to embodiment]. Figure 3 , Figure 3 A flowchart illustrating an embodiment of cryptographic syntax signing applied to an encryption end, provided in this application, includes: S301. Receive the original data to be signed from the server and calculate the hash value of the original data to be signed according to the preset asymmetric algorithm type; After receiving the original data to be signed, the encryption terminal transmits it to the computation area within the hardware security domain. Within this domain, the encryption terminal determines the corresponding hash algorithm based on a preset asymmetric algorithm type and performs a hash operation on the original data to be signed using this algorithm, generating a fixed-length hash value. A hash operation is the process of mapping original data of arbitrary length to a fixed-length binary string using a hash function. This process is unidirectional and collision-resistant, meaning it is impossible to reverse-engineer the original data from the hash value, and the probability of different original data producing the same hash value is extremely low.

[0042] The encryption terminal is pre-configured with one or more asymmetric algorithm types, with different types of asymmetric algorithms corresponding to different hash algorithms. The encryption terminal automatically matches the corresponding hash algorithm based on the pre-configured asymmetric algorithm type, ensuring the correct compatibility between the hash algorithm and the signature algorithm in subsequent signature operations. For example, if the configuration uses the RSA algorithm or elliptic curve cryptography algorithm, it matches the first type of hash algorithm; if the configuration uses the Chinese national standard SM2 algorithm, it matches the second type of hash algorithm.

[0043] S302. Obtain the locally stored private key, use the private key to perform a digital signature operation on the hash value, and generate a signature value; The private key corresponding to the preset asymmetric algorithm type is obtained from the local hardware. This private key is generated within the hardware security domain during the initialization phase of the encryption terminal, and its plaintext form does not leave the hardware security boundary from the time of generation. The encryption terminal stores the private key in hardware, and the software cannot read the plaintext data of the private key. It can only call the private key for signature calculation through the application programming interface provided by the encryption terminal.

[0044] The corresponding digital signature algorithm is determined based on the preset asymmetric algorithm type. Then, using the obtained private key and the determined signature algorithm, a digital signature operation is performed on the generated hash value to generate the original signature value. The basic principle of digital signature operation is: using the private key to perform mathematical transformations on the hash value to generate a numerical result related to both the hash value and the private key; this result is the original signature value. Different types of asymmetric algorithms correspond to different signature operation mechanisms. The signature operation is completed within the hardware security domain of the encryption terminal. The plaintext private key never leaves the hardware boundary throughout the entire signing process. Software environments and external attackers cannot obtain the private key information, thus ensuring the security of the private key.

[0045] S303. Return the signature value to the server in its original binary form.

[0046] The generated signature value is returned to the server via a secure communication link. This signature value is returned in its raw binary form; that is, the encryption end does not add any cryptographic message syntax structure encapsulation information to the signature value, nor does it perform any format conversion or add any encapsulation identifiers. Instead, it directly outputs the raw binary data generated by the signature operation. After the encryption end returns the signature value in its raw binary form, the signing process ends.

[0047] In practical applications, the encryption terminal receives document data to be signed from the server, calculates the hash value of the document data within the hardware security domain, signs the hash value using the unit's private key stored internally on the encryption terminal, and returns the signature value to the server in raw binary form. Upon receiving this raw binary signature value, the server fills it into the corresponding fields of a pre-built signature data object, forming a complete cryptographic message syntax signature. Throughout the entire process, the unit's private key remains stored internally on the encryption terminal and is never exported in any form. Even if the server is attacked, the attacker cannot obtain the private key. Because the encryption terminal returns a raw binary signature value without any cryptographic message syntax structure encapsulation information, the server can flexibly organize the structure and field content of the signature data object according to actual business needs, without being limited by the encryption terminal's output format.

[0048] In this embodiment, the encryption end receives the original data to be signed and completes the hash calculation within the hardware security domain. The private key is generated and stored within the hardware security domain, and the plaintext does not leave the hardware boundary. The signature operation is performed within the hardware security domain. Throughout the process, the plaintext of the private key is not exposed to the software environment, effectively resisting software-level private key theft attacks. The generated signature value is directly returned to the server in its original binary form without adding any cryptographic message syntax structure encapsulation information to the signature value, nor is any format conversion or additional encapsulation identifier added. This allows the server to flexibly organize the structure and field content of the signature data object according to actual business needs, without being limited by the output format of the encryption end.

[0049] The following explains how to calculate the hash value of the original data to be signed. Please refer to [link / reference needed]. Figure 4 , Figure 4 A flowchart illustrating an embodiment of calculating the hash value of the original data to be signed in a cryptographic syntax signature applied to an encrypted end, provided in this application, includes: S401. Identify a preset asymmetric algorithm type, wherein the preset asymmetric algorithm type includes at least two different asymmetric algorithm types; After receiving the raw data to be signed from the server, the encryption end first identifies the type of asymmetric algorithm currently being used. The encryption end has pre-configured asymmetric algorithm types; different types of asymmetric algorithms correspond to different algorithm parameters and operational logic in subsequent hash calculations and signature operations. Therefore, the encryption end needs to determine the type of algorithm currently being used before performing hash calculations.

[0050] Asymmetric algorithm types include at least two different asymmetric algorithm types. For example, the first asymmetric algorithm is the RSA algorithm or elliptic curve cryptography algorithm, and the second asymmetric algorithm is the SM2 algorithm. The first and second asymmetric algorithms differ in key length, operation mechanism, signature structure, etc., specifically in subsequent hash algorithm matching, signature algorithm selection, and signature value format.

[0051] S402. Based on the preset algorithm correspondence, determine the target hash algorithm that matches the identified asymmetric algorithm type; S403. Use the target hash algorithm to perform a hash operation on the original data to be signed to generate a hash value.

[0052] Taking the first and second asymmetric algorithms mentioned above as examples, when the encryption end identifies the current preset asymmetric algorithm type as the first asymmetric algorithm, i.e., RSA or elliptic curve cryptography, the encryption end uses the SHA-256 algorithm to perform a hash operation on the original data to be signed, generating a first-type hash value. There is a preset correspondence between the first asymmetric algorithm and the SHA-256 algorithm, which is pre-configured within the encryption end. The security strength of the first asymmetric algorithm determines its minimum requirement for the output length of the hash algorithm; the two are mathematically complementary. The hash value, as the input to the signature operation, must match the length and security of the hash algorithm; otherwise, the signature operation will fail or the signature strength will be insufficient.

[0053] The hash operation is performed within the hardware security domain of the encryption end. The original data to be signed is divided into blocks according to the block length specified by the SHA-256 algorithm. The SHA-256 algorithm performs compression and iterative operations on each data block, finally outputting a 256-bit binary string, which is the first type of hash value. Throughout the entire operation, the original data to be signed flows within the hardware security domain in the form of a binary stream and does not enter the software environment.

[0054] When the encryption end identifies the current preset asymmetric algorithm type as the second type, namely the SM2 algorithm, it selects the SM3 algorithm to perform a hash operation on the original data to be signed, generating a second type of hash value. There is also a preset correspondence between the SM2 and SM3 algorithms, which is pre-configured within the encryption end. The mathematical mechanism of the SM2 algorithm determines its requirements for the hash algorithm, and the SM3 algorithm, as a complementary hash algorithm to SM2, matches the SM2 algorithm in terms of security level.

[0055] The hash operation is performed within the hardware security domain of the encryption end. The original data to be signed is divided into blocks according to the block length specified by the SM3 algorithm. The SM3 algorithm performs compression and iterative operations on each data block, finally outputting a 256-bit binary string, which is the second type of hash value. Throughout the entire operation, the original data to be signed flows within the hardware security domain in the form of a binary stream and does not enter the software environment.

[0056] In this embodiment, the currently used preset asymmetric algorithm type is identified, and then the corresponding hash algorithm is matched according to the identification result to perform hash operation on the original data to be signed. This ensures that the hash algorithm used in the hash operation is always compatible with the asymmetric algorithm used in the subsequent signature operation, avoiding the problem of signature failure or insufficient signature strength due to the mismatch between the hash algorithm and the signature algorithm. The hash operation is performed inside the hardware security domain of the encryption end. The original data to be signed flows in the form of a binary stream inside the hardware security domain and does not enter the software environment, reducing the risk that the original data will be intercepted or tampered with by the software layer during the hash calculation stage.

[0057] The following explains how to generate a signature value; please refer to [link / reference]. Figure 5 , Figure 5 A flowchart illustrating an embodiment of generating a signature value in a cryptographic syntax signature applied to an encrypted end, provided in this application, includes: S501. Read the private key corresponding to the preset asymmetric algorithm type locally; The encryption endpoint reads the private key corresponding to the preset asymmetric algorithm type from the key storage area within its hardware security domain. Specifically, based on the currently preset asymmetric algorithm type, it locates the private key storage unit matching that algorithm type within the key storage area within the hardware security domain. The key storage area is a protected storage region within the hardware security domain, where each storage unit stores a key pair, and each key pair is stored separately according to the algorithm type. Access to the key storage area is protected by hardware security mechanisms; no software-level read request can directly access this area. Before performing a read operation on the key storage area, the legitimacy of the read request must be verified. The verification process includes: confirming that the context state of the current signature process matches the key read operation; and confirming that the read request originates from an authorized computation process within the encryption endpoint, rather than a direct call from an unauthorized external interface. This verification mechanism is executed by the security control module of the hardware security domain to prevent unauthorized reading of the private key.

[0058] After successful verification, the encryption end retrieves the located private key from the key storage area, loads it into the working area of ​​the computing unit within the hardware security domain, and clears all copies of the private key outside the working area. During the retrieval process, the private key is transmitted in encrypted form within the hardware, decrypted into plaintext only within the working area of ​​the computing unit, and the plaintext private key never leaves the boundary of the hardware security domain. The encryption end locks the private key's access, ensuring that it can only be used for the current signature operation, and is cleared from the working area after the operation is complete. The private key is temporarily stored in the hardware computing unit for subsequent signatures. If the private key needs to be used multiple times in the current signing process, it will remain in the hardware computing unit until the current signing process ends.

[0059] S502. Determine the corresponding digital signature algorithm based on the preset asymmetric algorithm type; After reading the private key, the encryption terminal determines the corresponding digital signature algorithm based on the preset asymmetric algorithm type. An internal mapping relationship between asymmetric algorithm types and digital signature algorithms is pre-configured and stored in the encryption terminal's hardware security domain as an algorithm configuration table. The algorithm configuration table records information such as the signature algorithm identifier, algorithm operation parameters, and algorithm standard version for each asymmetric algorithm type. After identifying the current preset asymmetric algorithm type, the encryption terminal queries the algorithm configuration table to obtain the relevant information of the digital signature algorithm corresponding to that type. When the encryption terminal identifies the current preset asymmetric algorithm type as a first-type asymmetric algorithm, it queries the algorithm configuration table to obtain the algorithm identifier of the first-type digital signature algorithm; when it identifies the current preset asymmetric algorithm type as a second-type asymmetric algorithm, it obtains the algorithm identifier of the second-type digital signature algorithm. The first-type and second-type digital signature algorithms differ in mathematical mechanisms, operation steps, and parameter configurations, and are adapted to different types of asymmetric algorithms respectively.

[0060] S503. Using the private key and the determined digital signature algorithm, perform a digital signature operation on the hash value to obtain the original signature value; Using the digital signature algorithm determined by the private key loaded into the working area of ​​the computing unit, a digital signature operation is performed on the generated hash value to generate the original signature value. Specifically, the encryption end loads the hash value from the storage area into the input register of the hardware computing unit, and loads the private key from the working area into the key register of the computing unit. The hardware computing unit performs a series of mathematical transformation operations on the hash value according to the operation rules of the digital signature algorithm, and finally generates a numerical result related to both the hash value and the private key, which is the original signature value.

[0061] Different types of digital signature algorithms involve different mathematical operations during execution. The first type of digital signature algorithm involves large integer modular exponentiation or modular multiplication during the signing process. This process includes multiple steps: converting the hash value to a large integer format, using the private parameters in the private key as the exponent or base, performing modular exponentiation to obtain intermediate results, and combining the intermediate results according to the algorithm rules to form the original signature value. The second type of digital signature algorithm involves elliptic curve multiplication and modular arithmetic during the signing process. This process includes: mapping the hash value to a point or scalar on an elliptic curve, performing elliptic curve multiplication using the private key as a scalar, and combining the results according to the algorithm rules to form the original signature value.

[0062] S504. Encode the original signature value according to the encoding rules specified by the digital signature algorithm to generate the signature value to be returned.

[0063] The generated raw signature value is encoded according to the encoding rules specified by the digital signature algorithm to generate the signature value to be returned to the server. The raw signature value exists in its original binary form within the hardware after the signature operation is completed. Different types of digital signature algorithms generate raw signature values ​​with different data structures: some algorithms generate two large integer parameters, which need to be arranged into a data structure according to a specific order and format; others generate a single numerical value, which needs to be padded and formatted according to a specified bit length. To facilitate server reception and subsequent processing, the encryption end needs to convert the raw signature value into the agreed-upon data transmission format according to the standard specifications of the digital signature algorithm.

[0064] Encoding rules refer to the encoding method of signature values ​​specified in the digital signature algorithm standard specification. Different types of digital signature algorithms may have different encoding rules. The encoding rules of the first type of digital signature algorithm specify the order of each parameter in the original signature value in the encoded data structure, the length representation of each parameter, and the overall encoding format; the encoding rules of the second type of digital signature algorithm also specify the encoding method of its signature result, but differ from the first type of encoding rules in the number of parameters, parameter arrangement, and encoding structure.

[0065] According to the encoding rules corresponding to the current digital signature algorithm, the components of the original signature value are arranged in the prescribed order, and necessary type identifiers and length information are added to form an encoded binary data string. The encoding operation is completed within the hardware security domain. The encoded signature value is still binary data; the encryption end does not add any cryptographic message syntax structure encapsulation information, nor does it attach any format headers or encapsulation identifiers. After encoding, the encryption end returns the generated signature value to the server in its original binary form via a secure communication link.

[0066] In this embodiment, the encryption end verifies the legitimacy of the request before reading the private key, then locates and loads the private key into the working area of ​​the computing unit. The private key is transmitted in encrypted form within the hardware, decrypted into plaintext only in the working area, and does not cross the hardware security domain boundary. It is immediately cleared from the working area after the operation is completed, ensuring that the private key is not exposed to the software environment throughout the entire process of reading, transmitting, and using. By querying the internal algorithm configuration table, a matching digital signature algorithm is determined according to the asymmetric algorithm type, ensuring that the digital signature algorithm and hash algorithm are compatible, avoiding signature failure or insufficient security strength due to algorithm mismatch. The signature operation is performed within the hardware security domain, and the intermediate calculation results are only temporarily stored in the hardware register, which is inaccessible to the software layer, further ensuring the security of the private key during the signing process. The original signature value is returned after being standardized and encoded according to the encoding rules, and the encoding process does not add any encapsulation information, allowing the server to obtain a directly usable original signature value. From the secure reading and loading of the private key, the correct matching of the algorithm, the secure execution of the signature process, to the standardized output of the signature value, the process is sequentially connected, ensuring that the private key never leaves the hardware security boundary, thus improving the security of the key system in collaborative signature scenarios.

[0067] This application also provides a cryptographic syntax signature server. Figure 6 A schematic diagram of a structure for an embodiment of cryptographic syntax signing applied to a server provided in this application, wherein the server includes: The sending unit 601 is used to send the original data to be signed to the encryption end; The construction unit 602 is used to construct the signer information structure according to the preset cryptographic syntax standard. The signer information structure has a signature value field. The receiving unit 603 is used to receive the signature value returned by the encryption end after the original data to be signed is processed, and write the signature value into the signature value field to obtain the complete signer information structure. Output unit 604 is used to assemble the complete signer information structure into a signature data object according to the preset cryptographic syntax standard and output the signature result.

[0068] This application also provides a cryptographic syntax signature encryption terminal, please refer to [link / reference]. Figure 7 A schematic diagram of a structure for an embodiment of cryptographic syntax signing applied to an encryption terminal provided in this application, the encryption terminal comprising: The receiving unit 701 is used to receive the original data to be signed from the server and calculate the hash value of the original data to be signed according to the preset asymmetric algorithm type. The signature unit 702 is used to obtain the locally stored private key, use the private key to perform digital signature operation on the hash value, and generate a signature value; Return unit 703 is used to return the signature value to the server in its raw binary form.

[0069] This application also provides a device for cryptographic syntax signing; please refer to [link to relevant documentation]. Figure 8 , Figure 8 A schematic diagram of an embodiment of the cryptographic syntax signing apparatus provided in this application, the apparatus comprising: Processor 801, memory 802, input / output unit 803, bus 804; The processor 801 is connected to the memory 802, the input / output unit 803, and the bus 804; The memory 802 stores a program, and the processor 801 calls the program to execute any of the above cryptographic syntax signature methods.

[0070] This application also relates to a computer-readable storage medium on which a program is stored. When the program is run on a computer, the computer executes any of the cryptographic signature methods described above. For detailed embodiments, please refer to... Figures 1-5 The specific implementation examples are not described here.

[0071] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0072] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

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

[0074] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0075] If the integrated unit 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 this application, in essence, or the part that contributes to the prior art, 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 includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for cryptographic signature, characterized in that, Applied to the server side, the method includes: Send the original data to be signed to the encrypted end; According to the preset cryptographic syntax standard, a signer information structure is constructed, which includes a signature value field. The system receives the signature value returned by the encryption terminal after it has processed the original data to be signed, and writes the signature value into the signature value field to obtain the complete signer information structure. According to the preset cryptographic syntax standard, the complete signer information structure is assembled into a signature data object, and the signature result is output.

2. The method for cryptographic signature according to claim 1, characterized in that, The step of writing the signature value into the signature value field to obtain the complete signer information structure includes: Parse the binary encoding of the signature value and verify whether the binary encoding is a valid encoding; When the binary encoding is valid, the signature value is written into the signature value field to obtain the complete signer information structure.

3. The method for cryptographic signature according to claim 1, characterized in that, The process of assembling the complete signer information structure into a signature data object according to the preset cryptographic syntax standard and outputting the signature result includes: According to the preset cryptographic syntax standard, the complete signer information structure is assembled into the preset position in the signature data object; The signature data object is serialized according to the differentiation encoding rules to generate a binary signature data string; According to the preset output mode, the binary signature data string is output as a signature result.

4. The method for cryptographic signature according to claim 3, characterized in that, The preset output modes include embedded output and discrete output; The embedded output is to encapsulate the original data to be signed into the signature data object before outputting the signature result, and output a signature data object that contains both the original data to be signed and the signature value. The separate output means that only the signature data object is output, and the original data to be signed is stored separately or transmitted independently from the signature data object.

5. A method for cryptographic signature, characterized in that, Applied to the encryption end, the method includes: Receive the raw data to be signed from the server, and calculate the hash value of the raw data to be signed according to the preset asymmetric algorithm type; Obtain the locally stored private key, and use the private key to perform a digital signature operation on the hash value to generate a signature value; The signature value is returned to the server in its original binary form.

6. The method for cryptographic signature according to claim 5, characterized in that, The step of calculating the hash value of the original data to be signed according to a preset asymmetric algorithm type includes: Identify a preset asymmetric algorithm type, wherein the preset asymmetric algorithm type includes at least two different asymmetric algorithm types; Based on the preset algorithm correspondence, determine the target hash algorithm that matches the identified asymmetric algorithm type; The target hash algorithm is used to perform a hash operation on the original data to be signed to generate a hash value.

7. The method for cryptographic signature according to claim 5, characterized in that, The step of obtaining the locally stored private key and using the private key to perform a digital signature operation on the hash value to generate a signature value includes: Read the private key corresponding to the preset asymmetric algorithm type locally; Based on the preset asymmetric algorithm type, determine the corresponding digital signature algorithm; Using the private key and the determined digital signature algorithm, a digital signature operation is performed on the hash value to obtain the original signature value; The original signature value is encoded according to the encoding rules specified by the digital signature algorithm to generate the signature value to be returned.

8. A cryptographic syntax signature server, characterized in that, include: The sending unit is used to send the original data to be signed to the encryption end; The construction unit is used to construct a signer information structure according to a preset cryptographic syntax standard, wherein the signer information structure includes a signature value field; The receiving unit is used to receive the signature value returned by the encryption end after performing signature processing on the original data to be signed, and write the signature value into the signature value field to obtain the complete signer information structure. The output unit is used to assemble the complete signer information structure into a signature data object according to the preset cryptographic syntax standard, and output the signature result.

9. A cryptographic syntax signature encryption terminal, characterized in that, include: The receiving unit is used to receive the original data to be signed from the server and calculate the hash value of the original data to be signed according to a preset asymmetric algorithm type. The signature unit is used to obtain the locally stored private key, and use the private key to perform a digital signature operation on the hash value to generate a signature value; The return unit is used to return the signature value to the server in its original binary form.

10. An apparatus for cryptographic syntax signing, characterized in that, The device includes: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor invokes to perform the method as described in any one of claims 1 to 7.

Images