Signature method and electronic equipment

Abstract

The invention provides a signature method, which is applied to first equipment and comprises the following steps: sending a signature request of a target file; the signature request comprises a first public key; wherein the first public key and the first private key are generated in pairs in a target module of the first device, and the target module is configured to store the first private key; in response to receiving a first signature key obtained by encryption based on the first public key, calling a first private key to decrypt the first signature key to obtain a second signature key; and processing the target file based on the second signature key to obtain a signature result. The invention further provides a signature method applied to the second device and an electronic device.

Description

Technical Field

[0001] This disclosure relates to the field of signatures, and more specifically, to a signature method and an electronic device. Background Technology

[0002] In scenarios such as firmware release, system boot chain protection, and software artifact delivery, it is often necessary to digitally sign target files (such as firmware images, boot components, or critical configuration files) to verify their integrity and source credibility during loading or distribution. Signing often relies on centralized signing services, which centrally store the signing private key on the server side and provide signing capabilities externally. However, there is a risk of interception, copying, or misuse during key distribution or signing interactions. Summary of the Invention

[0003] In view of this, this disclosure provides a signature method and an electronic device.

[0004] One aspect of this disclosure provides a signature method applied to a first device. The signature method includes: sending a signature request for a target file; the signature request including a first public key; wherein the first public key and a first private key are generated in pairs in a target module of the first device, and the target module is configured to: store the first private key; in response to receiving a first signature key obtained by encryption based on the first public key, calling the first private key to decrypt the first signature key to obtain a second signature key; and processing the target file based on the second signature key to obtain a signature result.

[0005] According to embodiments of this disclosure, before sending the signature request for the target file, the method further includes: the target module generating and sending an initial public key and identity information; and receiving a first public key obtained by signing and authenticating the initial public key based on the second private key of the second device in response to successful identity information verification.

[0006] According to embodiments of this disclosure, sending a signature request for a target file includes: the system firmware of a first device obtaining signature information; processing the signature information based on a third public key of a second device pre-configured in the system firmware to obtain a signature request; and the system firmware sending the signature request.

[0007] According to an embodiment of this disclosure, receiving a first signature key encrypted with a first public key includes: receiving a first signature key encrypted with the first public key after the first public key has been authenticated by a second public key, wherein the second public key and the second private key are generated in pairs in a second device.

[0008] According to an embodiment of this disclosure, in response to receiving a first signature key encrypted with a first public key, the system firmware calls a first private key to decrypt the first signature key to obtain a second signature key, including: the system firmware receiving the first signature key encrypted with the first public key and sending a decryption instruction to the target module; the decryption instruction includes the first signature key; the target module responding to the decryption instruction calls the first private key to decrypt the first signature key to obtain the second signature key.

[0009] According to embodiments of this disclosure, after obtaining the signature result, the method further includes: in response to the signature result indicating successful signing, obtaining the signature log generated during signing; sending the signature log to verify the signature result; and in response to the signature result indicating signature failure, recording the target signature position corresponding to the signature failure, wherein the target signature position is the starting signature position when re-signing the target file.

[0010] According to embodiments of this disclosure, the signature request includes a signature quantity request, and the second signature key includes multiple sub-signature keys corresponding to the signature quantity request. The multiple sub-signature keys are arranged in sequence, and each sub-signature key corresponds to a storage location. Based on the second signature key, the target file is processed, including: signing the target file using the first sub-signature key of the current storage location; in response to the completion of signing the target file with the first sub-signature key of the current storage location, deleting the first sub-signature key from the current storage location; writing the second sub-signature key of the next storage location into the current storage location and performing a signing operation on the target file; repeating the above operations until the signing is completed; the method further includes: in response to the completion of signing, deleting the remaining sub-signature keys among the multiple sub-signature keys.

[0011] According to embodiments of this disclosure, in response to the completion of signing, deleting the remaining sub-signature keys among a plurality of sub-signature keys includes at least one of the following: in response to the completion of signing with a plurality of sub-signature keys, deleting the first sub-signature key from the current storage location; in response to the completion of signing of the target file, deleting the first sub-signature key stored in each storage location.

[0012] Another aspect of this disclosure provides an alternative signature method applied to a second device, the method comprising: receiving a signature request including a first public key; generating a second signature key; processing the second signature key based on the first public key to obtain a first signature key; and sending the first signature key.

[0013] According to embodiments of this disclosure, before receiving a signature request including a first public key, the method further includes: receiving an initial public key and identity information, and verifying the identity information; in response to successful identity information verification, signing and authenticating the initial public key based on a second private key to obtain the first public key; sending the first public key; processing the signature request based on a third public key to obtain the signature request; receiving a signature request including the first public key and generating a second signature key, including: decrypting the signature request based on the third private key to obtain the first public key; wherein the third public key and the third private key are generated in pairs in a second device; verifying the first public key based on the second public key; generating the second public key and the second private key in pairs in a second device; and generating the second signature key in response to successful verification of the first public key.

[0014] Another aspect of this disclosure provides a first device, comprising: a processor; a target module; the processor being capable of performing the following operations based on target code: sending a signature request for a target file; the signature request including a first public key; wherein the first public key and a first private key are generated in pairs in the target module of the electronic device, and the target module is configured to: store the first private key; in response to receiving a first signature key encrypted based on the first public key, decrypt the first signature key using the first private key to obtain a second signature key; and process the target file based on the second signature key to obtain a signature result.

[0015] Another aspect of this disclosure provides a second device, comprising: a processor capable of performing the following operations based on object code: receiving a signature request including a first public key; generating a second signature key; processing the second signature key based on the first public key to obtain a first signature key; and sending the first signature key.

[0016] Another aspect of this disclosure provides a computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform a signature method according to any of the foregoing embodiments.

[0017] Another aspect of this disclosure provides a computer program product, including a computer program / instructions, characterized in that the computer program / instructions, when executed by a processor, implement the operation of the signature method of any of the foregoing embodiments. Attached Figure Description

[0018] The above and other objects, features, and advantages of this disclosure will become clearer from the following description of embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0019] Figure 1 A flowchart illustrating a signature method according to an embodiment of the present disclosure is shown schematically;

[0020] Figure 2 Another flowchart of a signature method according to an embodiment of the present disclosure is illustrated schematically;

[0021] Figure 3 A flowchart illustrating the sending of a signature request in a signature method according to an embodiment of the present disclosure is shown schematically.

[0022] Figure 4 A flowchart illustrating the process of obtaining a second signature key according to an embodiment of the present disclosure is shown.

[0023] Figure 5 Another flowchart of a signature method according to an embodiment of the present disclosure is illustrated schematically;

[0024] Figure 6 A flowchart illustrating a signature method according to an embodiment of the present disclosure is shown schematically.

[0025] Figure 7 A flowchart illustrating another signature method according to an embodiment of this disclosure is shown schematically;

[0026] Figure 8 This schematically illustrates another flowchart of another signature method according to an embodiment of the present disclosure;

[0027] Figure 9 A flowchart illustrating the generation of a second signature key according to another signature method based on an embodiment of the present disclosure is shown.

[0028] Figure 10 A block diagram of a signature device according to an embodiment of the present disclosure is shown schematically;

[0029] Figure 11 A block diagram schematically illustrates a signature device according to an embodiment of the present disclosure; and

[0030] Figure 12 A block diagram of an electronic device suitable for implementing the methods described above, according to embodiments of the present disclosure, is illustrated schematically. Detailed Implementation

[0031] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0032] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0033] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0034] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0035] In the embodiments disclosed herein, the collection, updating, analysis, processing, use, transmission, provision, disclosure, and storage of data (e.g., including but not limited to user personal information) comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. In particular, necessary measures have been taken to prevent unauthorized access to user personal information data and to safeguard user personal information security, network security, and national security.

[0036] Embodiments of this disclosure provide a signature method applied to a first device. The method includes: sending a signature request for a target file; the signature request includes a first public key; wherein the first public key and a first private key are generated in pairs in a target module of the first device, and the target module is configured to: store the first private key; in response to receiving a first signature key obtained by encryption based on the first public key, calling the first private key to decrypt the first signature key to obtain a second signature key; and processing the target file based on the second signature key to obtain a signature result.

[0037] Figure 1 A flowchart illustrating a signature method according to an embodiment of the present disclosure is shown schematically.

[0038] like Figure 1 As shown, the signature method applied to the first device may include at least operations S110, S120, S130 and S140.

[0039] In operation S110, a signature request for the target file is sent; the signature request includes a first public key; the second device receives the signature request and returns a first signature key encrypted based on the first public key. The first public key and the first private key are generated in pairs within the target module of the first device.

[0040] The target module is configured to perform operations S120~S140. The second device can be configured to receive a signature request containing a first public key, generate a second signature key for signing, encrypt and encapsulate the second signature key based on the first public key to obtain a first signature key, and then send the first signature key to the first device.

[0041] In operation S110, a signature request for the target file is sent; the signature request includes a first public key. The first public key and the first private key constitute an asymmetric key pair. The first public key can be provided externally and participate in key encapsulation operations, while the first private key resides within the security boundary of the target module in a non-exportable manner. The target module can be implemented by trusted hardware with secure storage and cryptographic operation capabilities. By isolating the execution environment, access control policies, and command interface constraints, the key material is restricted from leaving the target module in plaintext form. For example, the target module is implemented using a trusted platform module, where the key pair generation is completed internally; the first public key is exported via the module interface and written into the signature request, while the first private key is written into the module's non-volatile secure storage and configured as non-exportable.

[0042] A signature request can represent a trigger message for a task to be signed, and carries at least a first public key so that the key provider can perform targeted encrypted encapsulation of the signing key material based on the first public key, thereby enabling only the first device to have decapsulation capability. The signature request may also carry target file association information, including at least one of the target file body, target file digest, and target file identifier, to establish a verifiable binding between the subsequent signing result and the target file. For example, the signature request carries the target file hash value, file type marker, and the first public key and is sent to the key provider; in another implementation, the signature request carries the target file data block and the first public key.

[0043] Corresponding to operation S110, the second device receives a signature request from the first device and obtains a first public key (and optional target file association information / request identifier, etc.) from the signature request as input for subsequently generating and encapsulating the signature key.

[0044] In operation S120, the first private key is stored. Storing the first private key includes writing it into the protected storage area of ​​the target module and setting at least one of the following attributes for the first private key: non-exportable property, call authentication condition, or policy binding condition, to restrict the first private key from being read in plaintext or directly accessed by external programs. For example, the availability of the first private key in the execution environment corresponding to the first device is converged to "submitting a controlled cryptographic command and obtaining the calculation result," and the key plaintext does not enter the addressable area of ​​main memory, nor is it output in plaintext through a general interface.

[0045] In operation S130, in response to receiving the first signature key encrypted with the first public key, the first private key is used to decrypt the first signature key to obtain the second signature key. The first signature key can be a signature key ciphertext carrier, which is formed by encryption with the first public key; the second signature key corresponds to the signature key material after decryption of the ciphertext carrier, satisfying the input requirements for subsequent signature algorithm calls. The decryption process is completed within the target module, and the first private key only participates in cryptographic operations within the module; the second signature key, after being generated within the module, remains as transient key material or a protected cache object, and the external interface does not return the plaintext of the second signature key.

[0046] Corresponding to operation S130, in Figure 1 In the process, after receiving the signature request sent by operation S110, the second device generates a second signature key and encrypts and encapsulates the second signature key based on the first public key to obtain the first signature key. Then, it sends the first signature key to the first device. After receiving the first signature key, the first device triggers the target module to call the first private key to complete the decryption and obtain the second signature key.

[0047] For example, after receiving the first signature key ciphertext packet, the first device submits the ciphertext packet to the target module; the target module calls the first private key to perform decryption to obtain the second signature key, and stores the second signature key in the protected runtime storage area inside the module.

[0048] In operation S140, the target file is processed based on the second signature key to obtain a signature result. Specifically, processing the target file may include: performing a signature operation on the message digest based on the second signature key; and encapsulating the signature value to form a signature result. The signature result may include at least one of the following: signature value, algorithm identifier, version information, and verification information bound to the target file, to support the verification side in completing signature verification. For example, the target module receives the target file digest and internally calls the second signature key to output the signature value; in another implementation, a signature data structure containing the signature value and algorithm identifier is output, and the first device outputs the signature data structure along with the target file.

[0049] According to embodiments of this disclosure, the first private key and / or the second signing key are confined within the target module in the first device. "Confined within the target module" includes at least one or more of the following: the first private key is configured to be non-exportable; the second signing key is not written to main memory in plaintext; the second signing key is not output in plaintext via an operating system-accessible interface; key-related operations are triggered through the target module's command interface and completed within an isolated execution environment. The capabilities provided by the target module can be compressed into controlled cryptographic services such as decryption and signing. External entities obtain the signing result rather than the key material, reducing plaintext leakage points and lowering the risk of key duplication and manipulation. For example, general applications can only submit commands such as "decrypt the ciphertext carrier" and "sign the input digest," returning a signature value or status code; the interface does not return the plaintext of the first private key and the second signing key. Furthermore, since the second device sends the first signing key, encrypted and encapsulated based on the first public key, to the first device, the second device and the intermediate links in the transmission link do not need to transmit the plaintext form of the second signing key, further reducing the risk of the signing key material being intercepted or copied during the interaction process.

[0050] According to embodiments of this disclosure, by securing the first private key in the target module and confining the second signing key within the target module's isolated execution environment, the probability of key materials being stolen, copied, or maliciously replaced is reduced. Furthermore, this strengthens the binding between the signature result and the controlled cryptographic operations of the target module, improving the security and controllability of the signature process. In addition, the first private key is securely stored in the target module's local secure storage area in a non-exportable manner and does not leave the target module in plaintext during use. The second signing key exists within the target module's isolated execution environment as a protected object or transient key material and is invoked to complete the signature operation. It also does not need to be transmitted in plaintext over the network or stored on the network side, thus preventing key materials from being leaked during network transmission, link forwarding, or remote storage.

[0051] Figure 2 Another flowchart illustrating a signature method according to an embodiment of this disclosure is shown schematically.

[0052] like Figure 2 As shown, based on the aforementioned embodiments, before operation S110, the signature method may include operations S210~S220.

[0053] During operation S210, the target module generates and sends an initial public key and identity information. The initial public key corresponds to the first private key generated internally by the target module. The initial public key is in a pending authentication state and has not yet established a trusted binding relationship with signature permissions; the initial public key is externally visible, while the first private key remains within the target module's security boundaries and cannot be exported. The identity information represents the identity and permission attributes of the first device and the target module. The identity information includes at least one or more of the following: device identification information, module identification information, applicant information, and authorization scope information, to support the second device's review and decision-making regarding the signature permission application. For example... Figure 2 As shown, operation S210 corresponds to the interaction action of the first device sending the initial public key and identity information to the second device; corresponding to this sending action, the second device receives the initial public key and identity information and enters the identity information verification process.

[0054] For example, the identity information includes the device serial number of the first device, the hardware model identifier, the endorsement or certification information of the target module, the account identifier of the applicant, and the application purpose marker; the target module sends the initial public key and identity information to the second device (e.g., the certificate review / management side) through the communication interface of the first device. After receiving the information, the second device verifies the identity information and generates an authentication result for the initial public key when the verification is successful.

[0055] In operation S220, a response confirming successful identity verification is received, along with a first public key obtained by signing and authenticating the initial public key using the second device's second private key. The first public key can be understood as public key data signed and authenticated by the second device. The first public key and the initial public key are identical in key value or have a one-to-one correspondence, and carry authentication information indicating that signing authority has been granted. The authentication information includes at least one or more of the following: signature value, certificate identifier, and validity period information. Signature authentication is manifested in the second device performing a digital signature on the initial public key and outputting a distributable authentication result after verifying the identity information. This binds the first public key to the identity of the first device and the target module, providing traceable authorization for subsequent signature requests carrying the first public key. Figure 2 As shown, identity verification is completed by the second device; corresponding to the first device's action of "receiving the first public key", the second device generates and sends the first public key (or authentication data containing the first public key) to the first device after successful verification.

[0056] For example, a second device generates a digital certificate containing an initial public key and signs it with a second private key. The first device receives the digital certificate and extracts the first public key from it. The first public key is saved as the public key parameter for subsequent signature requests. In another implementation, the second device returns a combined structure of "initial public key + signature authentication data" as the first public key. The first device verifies the integrity of the structure and uses it as the public key parameter for the signature request.

[0057] According to an embodiment of this disclosure, after identity information verification is successful, the second device generates signature authentication data based on the second private key and the initial public key. The first device receives the signature authentication data and confirms the initial public key as the first public key before proceeding to the subsequent signature stage. This process is similar to... Figure 2 The interaction is consistent: the first device initiates and sends identity information and an initial public key; the second device completes verification and returns the authenticated first public key. Because the first public key carries signature authentication data, data without signature authentication lacks a matching basis in the authorization verification process. Forged or replaced public keys are more easily identified and rejected, reducing the probability of unauthorized entities obtaining signature capabilities through public key injection. Simultaneously, the first public key is bound to the identity information, ensuring consistency between the authorization recipient and the actual device performing the signature, reducing the likelihood of incorrect authorization and unauthorized access.

[0058] Figure 3 A flowchart illustrating the sending of a signature request in a signature method according to an embodiment of the present disclosure is shown.

[0059] like Figure 3 As shown, based on the aforementioned embodiments, operation S110 may include operations S310~S330. This process involves the interaction between the first device and the second device: the first device generates and encapsulates a signature request and sends it; the second device receives the signature request and processes it accordingly to return the data required subsequently (e.g., the first signature key) to the first device.

[0060] When operating the S310, the electronic device's system firmware acquires signature information. This system firmware can be a firmware program running during the pre-boot phase, such as BIOS / UEFI firmware, BootROM, first-stage / second-stage bootloader, trusted boot-related firmware components (e.g., a secure boot management module), or a combination thereof. The system firmware is typically stored in non-volatile media such as motherboard flash memory / read-only memory and is executed by the processor before the operating system loads. It is used to complete hardware initialization, boot measurements, policy loading, and controlled scheduling of cryptographic services. The target module can be trusted hardware or a protected execution unit with secure storage and cryptographic computation capabilities, such as a trusted platform module, a secure element, or a sub-module thereof. It is used to generate / store keys within an isolated security boundary and provide controlled cryptographic services such as decryption and signing, and the key material can be configured to be non-exportable.

[0061] The signature information represents the set of parameters for the signature task to be initiated, including at least one or more of the target file association information and the first public key. The target file association information includes at least one of the target file body, target file digest, target file identifier, and version identifier. The system firmware may obtain the signature information in the following ways: receiving the target file association information from the compilation / build process; reading the target file from the storage medium and calculating the digest; reading the first public key from the target module or triggering the export of the first public key; and combining the above information to form the data payload to be sent. For example, the signature information can be formed by concatenating the target file hash value, target file identifier, first public key, and request sequence number; in another implementation, the signature information carries the target file data block and the first public key.

[0062] The system firmware and the target module can interact through predefined hardware / firmware interfaces. For example, controlled commands such as "generate / export public key," "decapsulate / decrypt," and "sign" can be submitted via the bus and the target module's command set interface, and the returned public key, signature value, or status code can be received. The difference between the two lies in their characteristics: the system firmware runs on the main processor side, possessing process orchestration and data organization capabilities, but its execution environment is relatively general; the target module is trusted hardware with isolated execution and secure storage capabilities, capable of securely storing the first private key in a non-exportable manner and performing key-related operations within the isolation boundary. This allows the system firmware to "call cryptographic services to obtain results" rather than obtain the plaintext key, thus forming a division of labor relationship of "firmware scheduling + module-controlled operation."

[0063] In operation of S320, the signature information is processed based on the third public key of the second device pre-installed in the system firmware to obtain a signature request. The third public key and the third private key constitute an asymmetric key pair for secure transmission. The third private key is stored on the second device side, and the third public key is pre-installed in the system firmware or its trusted storage area. The signature information is encrypted and encapsulated based on the third public key to form a ciphertext payload. The ciphertext payload and the necessary plaintext fields together constitute the signature request. Processing the signature information can include: directly performing asymmetric encryption on the signature information using the third public key; or, encapsulating the session key based on the third public key and encrypting the signature information based on the session key to obtain the ciphertext payload and reduce the risk of transmission leakage. For example, the signature request contains the plaintext fields "protocol version, request serial number, first public key fingerprint" and the ciphertext field "signature information encrypted with the third public key"; in another implementation, the third public key is used to encapsulate the session key, and the signature information is encrypted based on the session key and written as the ciphertext payload into the signature request.

[0064] During operation S330, the system firmware sends a signature request. Corresponding to operation S330, the second device receives the signature request from the first device and completes request matching and parsing of necessary routing / session information based on the plaintext field in the signature request. At the same time, the second device performs restoration processing on the ciphertext field to obtain signature information, and enters the subsequent key generation and encapsulation process accordingly to return the first signature key obtained by encryption based on the first public key to the first device.

[0065] According to embodiments of this disclosure, the signature information is encrypted and encapsulated on the system firmware side and transmitted in ciphertext form. The second device can restore the signature information using only a third private key, thereby reducing the probability of the signature information being obtained in scenarios such as link eavesdropping or leakage of forwarding nodes. Furthermore, corresponding to this transmission process, after receiving a signature request, the second device restores the signature information only within its controlled execution environment and generates subsequent response data based on the restoration result, thereby reducing the unnecessary exposure of the signature information on the second device side.

[0066] According to an embodiment of this disclosure, receiving a first signature key encrypted with a first public key may include: receiving a first signature key encrypted with the first public key after the first public key has been authenticated by a second public key, wherein the second public key and the second private key are generated in pairs in the second device.

[0067] The second private key, which can correspond to the root private key or the upper-level private key of the trust chain, is stored on the second device side. It is used to generate signature authentication data for the initial public key, enabling the initial public key to obtain verifiable signature permission attributes. The second public key, which can also correspond to the root public key or the upper-level public key of the trust chain, is used to verify the signature authentication data to confirm that the source of the first public key is trustworthy and has not been tampered with. "The first public key is authenticated by the second public key" can be manifested as follows: the first public key carries the signature authentication data generated by the root private key. After the second device completes the verification based on the root public key and obtains a pass conclusion, it then performs encryption and encapsulation of the signature key material using the first public key to form the first signature key and sends it to the first device. Corresponding to the first device's action of "receiving the first signature key", after the signature verification is passed, the second device generates signature key material, encrypts and encapsulates the signature key material with the first public key to obtain the first signature key, and then sends the first signature key as a response to the first device. Only after the first device receives this response can it proceed to the subsequent process of calling the first private key to decrypt and obtain the second signature key.

[0068] For example, after the identity information is verified, the certificate verification and management system calls the root private key to sign the initial public key, forming the first public key data carrying the root signature; the second device, in subsequent processing, calls the root public key to verify the root signature. After successful verification, the one-time signature key material is encrypted and encapsulated using the first public key to obtain the first signature key and returned. This "return" corresponds to... Figure 3The interaction shown is the reciprocal response after the signature request is sent, i.e., the second device sends the first signature key back to the first device.

[0069] According to the embodiments of this disclosure, the root private key issuance and root public key verification bind the first public key and signing authority to a verifiable trust anchor. A public key without a valid root signature cannot trigger the issuance of signing key materials, reducing the probability that signing key materials can be obtained by unauthorized entities. At the same time, the signing key materials are transmitted and stored in ciphertext form after being encrypted and encapsulated by the first public key, reducing the risk of key leakage caused by link eavesdropping or copying in intermediate links, and improving the controllability of one-time signing key issuance and the security of its use.

[0070] Figure 4 A flowchart illustrating the process of obtaining a second signature key according to an embodiment of the present disclosure is shown.

[0071] like Figure 4 As shown, based on the aforementioned embodiments, operation S130 may include operations S410 to S420.

[0072] When operating S410, the system firmware receives a first signature key encrypted using a first public key and sends a decryption command to the target module; the decryption command includes the first signature key. The phrase "receive the first signature key encrypted using the first public key" corresponds to... Figure 4 The reciprocal transmission from the second device to the first device (system firmware side): After obtaining the first public key, the second device generates a second signature key and encrypts and encapsulates it based on the first public key to obtain the first signature key, and then sends the first signature key to the first device; the system firmware, as the receiving end on the first device side, receives the first signature key.

[0073] The system firmware can run within the isolated execution environment of the target module, possessing controlled data reception and cryptographic service scheduling capabilities. The first signature key is stored in ciphertext form on the system firmware side, and the system firmware does not obtain the plaintext key material corresponding to the first signature key. Decryption instructions can be represented as cryptographic service calls or command messages within the target module. In addition to the first signature key, they can also carry at least one of the following: algorithm identifier, key handle, session context, and integrity verification information, to support the target module in completing decryption and returning controlled results under consistent policy constraints.

[0074] For example, after the first signing key enters the pre-boot environment via the first device's communication interface, it is transferred to the system firmware. The system firmware encapsulates the first signing key into a command message and writes it into the target module's internal command queue. The command message contains the first signing key and a decryption opcode. Correspondingly, after the second device completes the generation of the first signing key, it returns it as a response message to the first device's communication interface, thereby enabling the system firmware to receive the first signing key.

[0075] During S420 operation, the target module responds to the decryption command by calling the first private key to decrypt the first signature key, obtaining the second signature key. Calling the first private key to decrypt the first signature key can correspond to asymmetric decryption or key decapsulation. The first private key resides securely in the target module's storage and maintains its non-exportable attribute. The decryption operation is performed by the target module's cryptographic engine within the isolation boundary. After being generated internally by the target module, the second signature key can be saved as a protected key object or transient key material. Externally visible results are limited to key reference information, operation status information, or the ability to call subsequent signature services. The plaintext of the second signature key is not output through the general interface.

[0076] According to the embodiments of this disclosure, the first signing key is kept in ciphertext form on the system firmware side and the decryption operation is limited to the isolation boundary of the target module. The plaintext exposure surface of the first private key and the second signing key is converged to the inside of the target module, reducing the probability of obtaining key materials through debugging interface snooping, main memory scanning, process injection and other paths. At the same time, the ciphertext carrier has a higher fault tolerance space in the receiving and handover stages, and the retransmission behavior caused by link fluctuations does not introduce the risk of plaintext leakage, thereby improving the reliability and security of the signing key distribution and decryption stages.

[0077] Figure 5 Another flowchart illustrating a signature method according to an embodiment of this disclosure is shown schematically.

[0078] like Figure 5 As shown, based on the aforementioned embodiments, the signature method after operation S140 may include operations S510 to S530.

[0079] In operation S510, in response to a successful signature result, the signature log generated during the signature process is retrieved. The signature log records key information about the signing process, including at least one or more of the following: target file association information, signature algorithm identifier, signature start and end times, execution entity identifier, and signature success indication information. For example, the signature log may contain the target file hash value, request sequence number, signature result code, and time consumption statistics, along with a log verification field output by the target module to indicate that the log has not been tampered with since its generation.

[0080] When operating the S520, a signature log is sent to verify the signature result. The recipient of the signature log can be the signature service side or a preset verification side, and as follows... Figure 5As shown, the receiver can be a second device. The verification side performs a consistency check based on the request identifier, target file association information, and signature result code in the signature log to confirm the execution status and correspondence of this signing task. Corresponding to the "send signature log" operation S520, the second device receives the signature log and performs verification processing based on the signature log to form a verification conclusion. In some implementations, the second device can also send the verification conclusion to the first device to indicate whether the signature result is acceptable. For example, the signature log is encapsulated into a log reporting code and sent to the verification side. After comparing the target file hash value with the request serial number, the verification side sends back the verification conclusion to confirm that the signature result is acceptable.

[0081] When operating S530, in response to a signature failure indicating a signature result, the target signature position corresponding to the signature failure is recorded. The target signature position is the starting signature position when re-signing the target file. The target signature position marks a progress point in the signature process, and its representation includes at least one of the following: the sequence number of the file to be signed, the offset within the file, the data block index, and the step number, so that subsequent retries can resume from this progress point instead of repeating the process from the starting point. The recording action is performed by the system firmware or the target module. In addition to the target signature position, the recorded content may also carry at least one of the following: the failure reason code, the failure occurrence time, and the context identifier, so as to complete the location and reproduction of the anomaly in the next retry.

[0082] For example, when signing the kth data block of the target file fails, the "file identifier + block index k + failure reason code" is written to the protected non-volatile storage; when signing is triggered again, the record is read and the process continues from the progress point corresponding to block index k.

[0083] When a signature is successful, the signature log records the target file association information, request identifier, and signature execution result. Upon receiving the signature log, the verification side can compare it with the corresponding signature request / target file information to confirm the consistency between the signature result and the target file. This allows for quick identification of the cause of any discrepancies, whether it's in the request parameters, target file content, or execution process information. Conversely, in the event of a signature failure, recording the target signature position allows subsequent re-signing to continue from the failed position, avoiding duplicate signing of completed parts, reducing time overhead from redundant calculations and transmissions, and minimizing process interruptions and resource waste caused by multiple retries.

[0084] Figure 6 A flowchart illustrating a signature method according to an embodiment of the present disclosure is shown.

[0085] like Figure 6As shown, based on the aforementioned embodiments, the signature request includes a signature quantity request, and the second signature key includes multiple sub-signature keys corresponding to the signature quantity request. The multiple sub-signature keys are arranged in order, and each sub-signature key corresponds to a storage location.

[0086] Operation S140 may include operations S610 to S630.

[0087] In operation S610, the target file is signed using the first sub-signature key located in the current storage location. The first sub-signature key is the sub-key material located in the current storage location among multiple sub-signature keys. The current storage location is a protected location within the target module used to temporarily store "currently available sub-signature keys". Signing the target file may include performing a signature operation on the target file or its digest and outputting the corresponding signature value. This signature operation only consumes the signature capability corresponding to the first sub-signature key in the current storage location. For example, when the number of signatures requested is N, the first sub-signature key is first written to the current storage location, and the target module calls this sub-signature key to generate the first signature value from the hash value of the target file.

[0088] In operation S620, in response to the completion of signing the target file with the first sub-signature key in the current storage location, the first sub-signature key is deleted from the current storage location. Deleting the first sub-signature key includes clearing the first sub-signature key from the current storage location, so that the storage location no longer retains the key material or key object corresponding to the sub-signature key. The deletion action is performed after signing is completed so that the first sub-signature key will no longer be called repeatedly; after deletion, the current storage location is in a state where the next sub-signature key can be written. For example, after the target module outputs the first signature value and returns a success status, it destroys the key object used to reference the first sub-signature key in the current storage location, or erases the corresponding key material from the protected storage.

[0089] In operation S630, the second sub-signature key from the next storage location is written to the current storage location to perform a signing operation on the target file. The next storage location is the storage location following the current storage location when multiple sub-signature keys are arranged in sequence, and the second sub-signature key is the sub-key material corresponding to the next storage location. After the second sub-signature key is written to the current storage location, the current storage location is updated to a new available sub-signature key entry, and subsequent signature operations continue to be performed based on this second sub-signature key to meet the multiple signature requirements corresponding to the signature quantity request.

[0090] Repeat steps S610 to S630 until the signing process ends. The end of the signing process indicates that all signature attempts corresponding to the requested number of signatures have been completed, or that the predetermined signing task for the target file has been completed, and there is no longer a need to call subsequent sub-signature keys.

[0091] According to embodiments of this disclosure, the method further includes: in response to the end of signing, deleting the remaining sub-signature keys among the multiple sub-signature keys. The remaining sub-signature keys are those that were not written to the current storage location and participated in the signing operation. Deleting the remaining sub-signature keys includes clearing their corresponding storage locations so that they can no longer be invoked by subsequent processes. The deletion of the remaining sub-signature keys can be triggered by the system firmware and executed by the target module. The deletion scope covers all storage locations corresponding to the multiple sub-signature keys to avoid leaving usable sub-signature key material after signing is completed.

[0092] Multiple sub-signature keys are rotated sequentially, and used sub-signature keys are invalidated after each signing. This ensures that the target module only needs to retain the currently used sub-signature keys at any given time, reducing the number of key materials residing within the module simultaneously. Furthermore, the "overwrite" operation of writing the sub-signature key from the next storage location to the current storage location effectively removes the sub-signature key that was previously located at that location, thus deleting the sub-signature key at the current location. This reduces the processing overhead of additional erasure steps and lowers the probability of used sub-signature keys remaining due to abnormal interruptions. Unused sub-signature keys are then cleared after signing to prevent residual sub-signature keys from being used in subsequent abnormal processes or repeated call scenarios. This reduces the risk of sub-signature keys being accidentally reused or abnormally invoked and improves the determinism of signature count control.

[0093] Based on the foregoing embodiments, deleting the remaining sub-signature keys among multiple sub-signature keys may include at least one of the following operations: deleting the first sub-signature key from the current storage location in response to the completion of signing with the multiple sub-signature keys; deleting the first sub-signature key stored in each of the storage locations in response to the completion of signing the target file. The remaining sub-signature keys are those that are still available at the end of the signing process but have not been actually consumed in generating the signature value. The remaining sub-signature keys include unused sub-signature keys located in non-current storage locations, and the last sub-signature key that may still reside in the current storage location when all signature quantity requests are satisfied.

[0094] The deletion of the remaining sub-signature key can be achieved by at least one of the following methods: performing a clear / erase operation on the storage location where the remaining sub-signature key is located; replacing the content of the corresponding location of the remaining sub-signature key with invalid data in an overwrite manner so that the location no longer holds atomic signature key material; or destroying the key object reference so that it cannot be used in subsequent calls.

[0095] For example, when the signature quantity request is N but the actual signature process ends after only M signatures are completed (M < N), the target module clears or overwrites the storage locations corresponding to the (M + 1)-th to the N-th sub-signature keys; when N signatures have been completed and the last sub-signature key still resides in the current storage location, the current storage location is overwritten to delete it, and the overwriting can be performed multiple times. For example, the preset invalid data is continuously written to this storage location three times to replace the original key content.

[0096] According to the embodiments of the present disclosure, at the end of the signature, the remaining sub-signature keys are deleted, so that the unconsumed sub-signature keys no longer remain in the storage location in an available form, reducing the probability of being continuously used in subsequent abnormal processes, repeated triggers, or unauthorized call scenarios; in addition, the deletion by means of overwriting (including multiple overwrites of the same location) can replace the original key content in the storage location without relying on additional key derivation or complex interactions, thereby improving the certainty of the deletion action and reducing the security risks brought by key residues.

[0097] Figure 7 The flowchart of another signature method according to the embodiments of the present disclosure is schematically shown.

[0098] As Figure 7 shown, based on the foregoing embodiments, another signature method is applied to the second device and may include operations S710 to S730. Figure 7 Meanwhile, the interaction relationship between the first device and the second device is shown: the first device sends a signature request, and the second device generates and returns the first signature key; among them, operation S710 includes S711 to S712, Figure 7 where S711 corresponds to the interaction action of "receiving the signature request", S712 corresponds to the local generation action of the second device, S720 corresponds to the local encapsulation processing action of the second device, and S730 corresponds to the interaction action of sending the first signature key to the first device.

[0099] In operation S710, a signature request including a first public key is received, and a second signature key is generated. The signature request is a request message used by the second device to trigger key distribution. The signature request carries at least the first public key, and may also carry at least one of the following: request identifier, target file association information, signature algorithm identifier, and signature quantity request, so that the second device can determine the type and quantity of signature keys to be generated. Generating the second signature key can be understood as the second device generating key material or key objects based on a secure random source, and using this key material as data to be packaged and distributed; the second signature key can be a single signature key, or a set of multiple sub-signature keys corresponding to the signature quantity request. Corresponding to operation S710, the first device sends a signature request including the first public key to the second device, enabling the second device to receive the signature request and obtain the first public key; the signature request sent by the first device may also carry fields such as a request identifier, so that the second device can perform corresponding matching in the response.

[0100] For example, a signature request carries a first public key and a signature quantity request N, and a second device generates N one-time sub-signature keys and organizes them in order as a second signature key; in another implementation, a signature request carries a first public key and a target file hash value, and a second device generates a single signature key bound to this task as a second signature key.

[0101] In operation S720, the second signature key is processed based on the first public key to obtain the first signature key. "Processing based on the first public key" includes at least performing encrypted encapsulation on the second signature key, so that the first signature key carries the second signature key in ciphertext form. The first signature key may further include at least one of the following: algorithm identifier, encapsulation parameters, length information, and verification information, to support correct decapsulation on the receiving side. The encryption encapsulation method can be asymmetric encryption or a hybrid encryption method: the session key is encapsulated by the first public key, and then the second signature key is symmetrically encrypted using the session key to obtain the first signature key. Corresponding to operation S720, the first public key provided by the first device serves as input to the encapsulation processing of the second device, enabling the first device to subsequently use the first private key paired with the first public key within its target module to complete decapsulation / decryption to recover the second signature key.

[0102] For example, the second device uses the first public key to perform asymmetric encryption on the second signature key to obtain ciphertext as the first signature key; in another implementation, the second device first generates a session key and encapsulates the session key with the first public key, then encrypts the second signature key with the session key, and finally uses the "encapsulated session key + ciphertext payload" as the first signature key.

[0103] In operation S730, the first signature key is sent. Sending the first signature key includes returning the first signature key as the payload of a response message to the initiating side of the signature request. The response message may also carry at least one of the following: a request identifier, a return code, and a retransmission flag matching the signature request, so that the initiating side can confirm the correspondence and handle any exceptions. Corresponding to operation S730, the first device receives the first signature key sent by the second device, and confirms that the first signature key matches the sent signature request based on information such as the request identifier. Then, the first signature key is submitted to the target module to perform the subsequent decryption process to obtain the second signature key.

[0104] According to the embodiments of this disclosure, after receiving a signature request carrying a first public key, the second device generates a second signature key as needed, and uses the first public key to encapsulate the second signature key into a first signature key in ciphertext form before sending it, making it difficult to directly restore the signature key material if it is intercepted during transmission or intermediate forwarding. At the same time, the second signature key is generated by the second device in response to the request, which can reduce the reuse of the same key material between different signature tasks, thereby reducing the risk of multiple signature tasks being affected by a single leakage or abnormal acquisition.

[0105] Figure 8 Another flowchart of another signature method according to an embodiment of the present disclosure is illustrated schematically.

[0106] like Figure 8 As shown, based on the aforementioned embodiments, the signature method before operation S710 may include operations S810~S830. Figure 8 The interaction between the first device and the second device regarding public key authentication is also shown: the first device sends an initial public key and identity information, the second device receives the information, verifies the identity information, and generates a first public key and sends it back when the verification is successful.

[0107] In operation S810, the initial public key and identity information are received, and the identity information is verified. The initial public key is the public key data for which signature permissions are to be applied for. The identity information is used to characterize the identity attributes of the subject corresponding to the initial public key. The identity information may include at least one or more of the following: subject identification information, device identification information, account information, qualification certificate information, and application scenario information. Verifying the identity information can be understood as the second device verifying the authenticity, validity, and association relationship between the identity information and the initial public key. Only after the verification is passed is the public key signature authentication process allowed. Among them, the association relationship verification may include checking the submission source of the initial public key, the consistency between the applicant subject identifier and the pre-registered information. Corresponding to operation S810, the first device generates or obtains the initial public key and collects the identity information, and sends the initial public key and identity information to the second device through the communication interface, enabling the second device to receive and trigger the identity information verification process (e.g., Figure 8S811 corresponds to the send / receive action, and S812 corresponds to the verification action on the second device side.

[0108] In operation S820, in response to successful identity verification, the first public key is obtained by signing and authenticating the initial public key based on the second private key. Signing and authenticating the initial public key based on the second private key can be understood as follows: the second device uses the second private key to generate signature authentication data for the initial public key or its digest data, and combines the signature authentication data with the initial public key to form a first public key that can be verified by the second public key. The first public key can be obtained in the form of a "public key structure carrying signature authentication data" or a "certificate structure containing the initial public key and signed by the second private key," as long as it enables subsequent determination of whether the first public key has passed signature authentication based on the second public key. Corresponding to operation S820, the first device, as the applicant, does not need to perform signature authentication operations. Instead, after receiving the first public key generated by the second device, it uses it as an authenticated public key for subsequent signature requests.

[0109] In operation S830, the first public key is sent. Corresponding to operation S830, the first device receives the first public key sent by the second device and can associate the first public key with the corresponding initial public key application based on the request identifier or session information, so as to carry the first public key when sending a signature request to the second device in the future.

[0110] Figure 9 A flowchart illustrating the generation of a second signature key is shown in another signature method according to an embodiment of the present disclosure.

[0111] like Figure 9 As shown, based on the aforementioned embodiments, the signature request is obtained by processing a third public key. Operation S710 may include operations S910-S930. In some embodiments, before the first device sends the signature request, the second device generates a third public key and a third private key, and configures the third public key to the first device (e.g., by presetting, distributing, or writing to a trusted storage area) so that the first device can encrypt and encapsulate the signature request based on the third public key; corresponding to this configuration action, the first device receives the third public key and saves it as a public key parameter for generating the signature request.

[0112] In some embodiments, the second device also generates a second public key and a second private key, and configures the second public key to the first device (e.g., to enable the first device to obtain and save verifiable first public key / certificate information); corresponding to this configuration action, the first device receives the second public key and completes the saving.

[0113] In operation S910, the signature request is decrypted based on the third private key to obtain the first public key; wherein, the third public key and the third private key are generated in pairs in the second device. The third private key is used to decrypt or decapsulate the signature request processed by the third public key, enabling the second device to recover the first public key and its associated request information from the ciphertext payload of the signature request; the third public key can be pre-set on the first device side for encrypting and encapsulating the signature request to reduce the probability of the request content being obtained during transmission. Decrypting the signature request to obtain the first public key may include: decrypting the ciphertext payload of the signature request to obtain plaintext request data, and then parsing the first public key field from the plaintext request data; or first decapsulating the session key and then decrypting the ciphertext payload to finally obtain plaintext content containing the first public key. Corresponding to operation S910, the first device encrypts and encapsulates the signature information based on the third public key to obtain the signature request, and sends the signature request to the second device, enabling the second device to receive the signature request and decrypt it based on the third private key to obtain the first public key.

[0114] In operation S920, the first public key is verified based on the second public key; the second public key and the second private key are generated in pairs in the second device. Verifying the first public key based on the second public key can be understood as the second device using the second public key to verify the signature authentication data carried in the first public key, confirming that the first public key was indeed generated by the second private key and has not been tampered with during transmission and storage. The verification may include checking the correctness of the signature authentication data and the integrity of the first public key structure. Only after successful verification is subsequent generation of the second signature key allowed; if verification fails, the request is rejected or a failure indication message is returned. Corresponding to operation S920, the first device carries the first public key (e.g., a first public key structure carrying signature authentication data or a certificate structure containing the first public key) when sending a signature request, enabling the second device to verify the first public key based on the second public key.

[0115] During operation of S930, in response to the successful verification of the first public key, a second signature key is generated. Generating the second signature key can be understood as the second device generating key material or key objects to be distributed based on the signature request corresponding to the verified first public key, for subsequent encryption and encapsulation by the first public key to form the first signature key. The generation of the second signature key can be associated with request information, such as determining the type or quantity of the second signature key based on the algorithm identifier, signature quantity request, or task identifier in the request, but the specific implementation details are not limited.

[0116] According to embodiments of this disclosure, after receiving the initial public key, the second device first verifies the identity information, and then uses the second private key to complete the signature authentication of the initial public key, so that the first public key has the trusted attribute that can be verified by the second public key, thereby reducing the probability of unauthorized public keys entering the subsequent signature key distribution process; at the same time, the signature request is processed by the third public key and decrypted by the second device using the third private key, which can reduce the risk of the first public key and request information being leaked during the transmission of the signature request; the second signature key is generated only after the first public key is verified and approved on the signature request side, so that the generation and distribution of the signature key material are more in line with the authorization verification order, reducing the risk of the signature key being incorrectly distributed or triggered by a forged request.

[0117] Figure 10 A block diagram of a signature device according to an embodiment of the present disclosure is shown schematically.

[0118] like Figure 10 As shown, the signature device 1000 may include a first sending module 1010, a first storage module 1020, a first decryption module 1030, and a first processing module 1050.

[0119] The first sending module 1010 is used to send a signature request for a target file; the signature request includes a first public key. In some embodiments, the first sending module 1010 can be used to perform operation S110 in the above signature method, which will not be described in detail here.

[0120] The first storage module 1020 is used to store the first private key. In some embodiments, the first storage module 1020 can be used to perform operation S120 in the above signature method, which will not be described in detail here.

[0121] The first decryption module 1030 is configured to, in response to receiving the first signature key encrypted based on the first public key, call the first private key to decrypt the first signature key to obtain the second signature key. In some embodiments, the first decryption module 1030 may be used to perform operation S130 in the above signature method, which will not be elaborated here.

[0122] The first processing module 1040 is used to process the target file based on the second signing key to obtain a signature result. In some embodiments, the first processing module 1040 may be used to perform operation S140 in the above-described signing method, which will not be described in detail here.

[0123] Figure 11 A block diagram of a signature device according to an embodiment of the present disclosure is shown schematically.

[0124] like Figure 11As shown, another signature device 1100 may include a first generation module 1110, a second processing module 1120, and a second sending module 1130.

[0125] The first generation module 1110 is used to receive a signature request including a first public key and generate a second signature key. In some embodiments, the first generation module 1110 can be used to perform operation S710 in the above signature method, which will not be described in detail here.

[0126] The second processing module 1120 is used to process the second signature key based on the first public key to obtain the first signature key. In some embodiments, the second processing module 1120 can be used to perform operation S720 in the above signature method, which will not be described in detail here.

[0127] The second sending module 1130 is used to send the first signature key. In some embodiments, the second sending module 1130 may be used to perform operation S730 in the above signature method, which will not be described in detail here.

[0128] Any one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure, or at least part of the functions of any one or more of them, can be implemented in one module. Any one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure can be implemented by dividing them into multiple modules. Any one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure can be at least partially implemented as hardware circuitry, such as a Field-Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a System-on-Chip, a System-on-a-Substrate, a System-on-Package, an Application-Specific Integrated Circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure can be at least partially implemented as computer program modules, which, when run, can perform corresponding functions.

[0129] For example, any plurality of the first transmitting module 1010, the first storage module 1020, the first decryption module 1030, and the first processing module 1050 can be combined into one module / unit / subunit, or any one of these modules / units / subunits can be split into multiple modules / units / subunits. Alternatively, at least part of the functionality of one or more of these modules / units / subunits can be combined with at least part of the functionality of other modules / units / subunits and implemented in one module / unit / subunit. According to embodiments of this disclosure, at least one of the first transmitting module 1010, the first storage module 1020, the first decryption module 1030, and the first processing module 1050 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the first sending module 1010, the first storage module 1020, the first decryption module 1030, and the first processing module 1050 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0130] It should be noted that the data processing system part in the embodiments of this disclosure corresponds to the data processing method part in the embodiments of this disclosure. The specific description of the data processing system part is referred to in the data processing method part, and will not be repeated here.

[0131] Figure 12 A block diagram of an electronic device suitable for implementing the methods described above, according to embodiments of the present disclosure, is illustrated schematically. Figure 12 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0132] like Figure 12As shown, an electronic device 1200 according to an embodiment of the present disclosure includes a processor 1201, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1202 or a program loaded from a storage portion 1208 into a random access memory (RAM) 1203. The processor 1201 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 1201 may also include onboard memory for caching purposes. The processor 1201 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0133] RAM 1203 stores various programs and data required for the operation of electronic device 1200. Processor 1201, ROM 1202, and RAM 1203 are interconnected via bus 1204. Processor 1201 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 1202 and / or RAM 1203. It should be noted that the programs may also be stored in one or more memories other than ROM 1202 and RAM 1203. Processor 1201 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in said one or more memories.

[0134] According to embodiments of this disclosure, the electronic device 1200 may further include an input / output (I / O) interface 1205, which is also connected to a bus 1204. The electronic device 1200 may also include one or more of the following components connected to the input / output (I / O) interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the input / output (I / O) interface 1205 as needed. A removable medium 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1210 as needed so that computer programs read from it can be installed into the storage section 1208 as needed.

[0135] According to embodiments of this disclosure, the electronic device 1200 may further include a security module 1212 (optional). The security module 1212 may be a Trusted Platform Module (TPM), a security chip, a Hardware Security Module (HSM), a Trusted Execution Environment (TEE), or other security units with cryptographic operation and key protection capabilities. The security module 1212 may be connected to the processor 1201 via a bus 1204 or via an input / output (I / O) interface 1205, and is used to perform controlled operations related to keys and / or store key materials. In some embodiments, the security module 1212 may store a first private key and perform decryption of the first signature key within an isolation boundary to obtain a second signature key for signing; in some embodiments, the security module 1212 may also store a second private key for signature authentication (e.g., a root private key or a trust chain upper-level private key) and / or a third private key for decrypting a signature request, and perform corresponding cryptographic operations within an isolation boundary; in other embodiments, the aforementioned private keys may also be stored in the protected storage area of ​​the electronic device 1200 and the processor 1201 may call a cryptographic library to perform operations, and the specific implementation is not limited.

[0136] In this embodiment of the disclosure, when the electronic device 1200 is used as the first device, the processor 1201 can execute a program for implementing the method flow of the first device side, such as receiving a first signature key obtained by encryption based on a first public key, sending a decryption instruction to the security module 1212 (e.g., system firmware running on a TPM or a target module controlled by it), causing the security module 1212 to call the first private key to decrypt the first signature key within the isolation boundary to obtain a second signature key, and performing signature-related operations on the target file based on the second signature key; when the signature is successful, the signature log is acquired and processed for subsequent verification, and when the signature fails, the corresponding signature position is recorded so that the signature can be re-signed from that position; when multiple sub-signature keys are involved, they are used in the order of their storage positions and the used sub-signature keys are invalidated at the current position (including the deletion effect achieved by overwriting), and the remaining sub-signature keys are cleared when the signature ends. When electronic device 1200 acts as a second device, processor 1201 can execute programs to implement the method flow on the second device side. For example, it can receive an initial public key and identity information, verify the identity information, and after successful verification, use a second private key to sign and authenticate the initial public key to obtain a first public key and send it; receive a signature request including the first public key and generate a second signature key, encrypt and encapsulate the second signature key based on the first public key to obtain a first signature key and send it; if the signature request has been processed by a third public key, use the third private key to decrypt the signature request to obtain the first public key, and verify the first public key based on the second public key, and generate a second signature key after successful verification. These functions can be implemented directly by processor 1201 or by processor 1201 in conjunction with security module 1212.

[0137] According to embodiments of this disclosure, the method flow according to embodiments of this disclosure can be implemented as a computer software program. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable storage medium, the computer program containing program code for performing the method shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by processor 1201, it performs the functions defined in the system of embodiments of this disclosure. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules, wherein the computer program modules can be used to implement a first device-side function, a second device-side function, or both functions simultaneously. This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The aforementioned computer-readable storage medium carries one or more programs, which, when executed, implement the method according to embodiments of this disclosure.

[0138] According to embodiments of this disclosure, the computer-readable storage medium can be a non-volatile computer-readable storage medium. Examples include, but are not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0139] For example, according to embodiments of this disclosure, a computer-readable storage medium may include ROM 1202 and / or RAM 1203 and / or one or more memories other than ROM 1202 and RAM 1203 described above.

[0140] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods provided in the embodiments of this disclosure. When the computer program product is run on an electronic device, the program code is used to enable the electronic device to implement the signature method provided in the embodiments of this disclosure.

[0141] When the computer program is executed by the processor 1201, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0142] In one embodiment, the computer program may rely on tangible storage media such as optical storage devices or magnetic storage devices. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via communication section 1209, and / or installed from removable medium 1211. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof. According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code may be executed entirely on a user computing device, partially on a user device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing devices can be connected to user computing devices via any type of network, including local area networks (LANs) or wide area networks (WANs), or they can be connected to external computing devices (e.g., via the Internet using an Internet service provider).

[0143] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions. Those skilled in the art will understand that the features described in the various embodiments of the present disclosure can be combined and / or combined in various ways, even if such combinations are not explicitly described in the present disclosure. In particular, the features described in the various embodiments of this disclosure may be combined and / or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0144] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A signature method applied to a first device, the method comprising: Send a signature request for the target file; the signature request includes a first public key; The first public key and the first private key are generated in pairs in the target module of the first device, and the target module is configured as follows: Store the first private key; in response to receiving the first signature key obtained by encryption based on the first public key, call the first private key to decrypt the first signature key to obtain the second signature key; process the target file based on the second signature key to obtain a signature result.

2. The method according to claim 1, further comprising, before sending the signature request for the target file: The target module generates and sends an initial public key and identity information; Upon receiving a response indicating that the identity information has been verified, the system authenticates the first public key by signing the initial public key using the second private key of the second device.

3. The method according to claim 2, wherein sending the signature request for the target file includes: The system firmware of the first device obtains signature information; The signature information is processed based on the third public key of the second device pre-installed in the system firmware to obtain the signature request; The system firmware sends the signature request.

4. The method according to claim 3, wherein responding to receiving a first signature key encrypted based on the first public key, and decrypting the first signature key using the first private key to obtain a second signature key, comprises: The system firmware receives the first signature key obtained by encryption based on the first public key, and sends a decryption command to the target module; The decryption instruction includes the first signature key; In response to the decryption command, the target module calls the first private key to decrypt the first signature key to obtain the second signature key.

5. The method according to claim 1, further comprising, after obtaining the signature result: In response to the signature result indicating successful signature, the signature log generated during the signature process is retrieved; Send the signature log to verify the signature result; In response to the signature result indicating a signature failure, the target signature position corresponding to the signature failure is recorded, and the target signature position is the starting signature position when re-signing the target file.

6. The method according to claim 1, wherein the signature request includes a signature quantity request, the second signature key includes a plurality of sub-signature keys corresponding to the signature quantity request, the plurality of sub-signature keys are arranged in order, and each sub-signature key corresponds to a storage location; The processing of the target file based on the second signature key includes: The target file is signed using the first sub-signature key located in the current storage location; Upon completion of signing the target file using the first sub-signature key at the current storage location, the first sub-signature key is deleted from the current storage location. Write the second sub-signature key of the next storage location into the current storage location, and perform a signature operation on the target file; Repeat the above steps until the signing process is complete; The method further includes: In response to the end of the signing process, the remaining sub-signature keys among the plurality of sub-signature keys are deleted.

7. The method according to claim 6, wherein deleting the remaining sub-signature keys among the plurality of sub-signature keys in response to the end of signing includes at least one of the following: In response to the completion of signing by the plurality of sub-signature keys, the first sub-signature key is deleted from the current storage location; In response to the completion of the signing of the target file, the first sub-signature key stored in each of the storage locations is deleted.

8. A signature method applied to a second device, the method comprising: Receive a signature request including the first public key and generate a second signature key; Based on the first public key, the second signing key is processed to obtain the first signing key; Send the first signing key.

9. The method of claim 8, further comprising, before receiving the signature request including the first public key: Receive the initial public key and identity information, and verify the identity information; In response to the successful verification of the identity information, the first public key is obtained by signing and authenticating the initial public key based on the second private key; Send the first public key; The signature request is obtained by processing a third public key; The step of receiving a signature request including a first public key and generating a second signature key includes: The signature request is decrypted based on the third private key to obtain the first public key; wherein the third public key and the third private key are generated in pairs in the second device; The first public key is verified based on the second public key; the second public key and the second private key are generated in pairs in the second device; In response to the successful verification of the first public key, the second signing key is generated.

10. A first device, comprising: processor; Target module; The processor is capable of performing the following operations based on the target code: Send a signature request for a target file; the signature request includes a first public key; wherein the first public key and a first private key are generated in pairs in a target module of an electronic device, and the target module is configured to: store the first private key; in response to receiving a first signature key encrypted based on the first public key, call the first private key to decrypt the first signature key to obtain a second signature key; and process the target file based on the second signature key to obtain a signature result.

Images