Intelligent cryptographic key system and signature method supporting ML-DSA algorithm

Abstract

This invention discloses a smart cryptographic key system and signature method supporting the ML-DSA algorithm, relating to the fields of network information security and electronic payment technology. In the system, a container management module is configured to include logically independent first and second type containers. The client's middleware establishes a one-to-one logical association between the first and second type containers based on a consistent subject DN field. A secure cryptographic operation module, in response to a single transaction signature instruction initiated by the client and forwarded by the client's middleware, performs signatures on the same transaction data using the SM2 private key in the first type container and the ML-DSA private key in the second type container within the same secure execution flow, and outputs a dual signature result consisting of the SM2 signature value and the ML-DSA signature value to the client's middleware in one go. This invention improves the security level and user experience of highly sensitive financial transactions.

Description

Technical Field

[0001] This invention relates to the fields of network information security and electronic payment technology, and in particular to a smart cryptographic key system and signature method that supports the ML-DSA algorithm. Background Technology

[0002] Currently, online banking, mobile payments, and other financial services are deeply integrated into the socio-economic operation, placing extremely high demands on the confidentiality, integrity, and non-repudiation of transaction data. The banking industry generally adopts digital certificate systems based on public key infrastructure to ensure these security attributes, with its trust foundation primarily built on the SM2 algorithm based on the elliptic curve discrete logarithm problem and the RSA algorithm based on the large integer factorization problem. However, the rapid development of quantum computing technology poses a real threat to this foundation of trust. Quantum algorithms have been proven to be able to break traditional public-key cryptographic algorithms such as RSA and SM2 in polynomial time. Once general-purpose quantum computers reach a practical scale, financial assets protected by these algorithms, such as long-term bonds, blockchain ledgers, and electronic contracts, will face severe challenges in terms of confidentiality loss and non-repudiation failure. Therefore, relevant standardization organizations are accelerating the standardization of quantum-resistant cryptography, among which the ML-DSA algorithm based on modular lattice theory is widely considered the preferred choice for the next-generation cryptographic standard due to its security and performance advantages.

[0003] In response to the disruptive threats posed by quantum computing, the industry has begun exploring migration paths from traditional cryptographic algorithms to quantum-resistant cryptography. In the banking sector, which heavily relies on cryptographic technology, relevant institutions are attempting to introduce support for quantum-resistant algorithms such as ML-DSA into existing smart key devices to achieve coexistence of the old and new cryptographic systems during the transition period. Current attempts primarily focus on calling the SM2 signature interface and the quantum-resistant signature interface separately at the application layer for the same transaction, generating a double signature through two independent signature operations, thus balancing compliance and forward-looking security. Simultaneously, some solutions are exploring the allocation of fixed storage areas within the smart key's file system to store keys and certificates for different algorithms.

[0004] However, the aforementioned existing technologies suffer from the following core drawbacks when applied to the massive and highly secure environment of banking information systems. First, the hardware storage architecture is rigid and space-constrained: Existing smart cryptographic keys typically employ fixed container structures, such as only dividing the space into RSA and SM2 containers, which cannot dynamically adapt to the storage requirements of quantum-resistant algorithms. For example, the public key size of ML-DSA-44 is much larger than SM2, and the overall size of the key pair and certificate also increases significantly. During the transition period, users may hold various forms of certificates, such as purely traditional certificates, purely quantum-resistant certificates, or hybrid certificates. Existing container management mechanisms cannot smoothly support both the old and new cryptographic systems on the same hardware. Second, the interaction friction and lack of atomicity in dual signatures: To simultaneously meet compliance and quantum-resistant security requirements, current transition solutions often require dual signatures for the same transaction. However, the application layer must call the signature interface twice consecutively—once for SM2 and once for the quantum-resistant signature interface. This serial calling method severely degrades the user experience, requiring users to repeatedly enter PIN codes or perform confirmation operations. More importantly, the two signatures are independent of each other in terms of timing. If one of the signatures fails or the device disconnects abnormally, an intermediate state may be generated where only a partial signature value is generated, resulting in inconsistent transaction data and failing to meet the strict requirements of high-sensitivity financial business for operational atomicity and data consistency. Summary of the Invention

[0005] This invention aims to overcome the shortcomings of the prior art, and specifically provides the following technical solution: 1) In a first aspect, the present invention provides an intelligent cryptographic key system supporting the ML-DSA algorithm, the specific technical solution of which is as follows: The container management module is configured to contain logically independent first-type containers and second-type containers. The first-type containers are used to store key pairs based on the SM2 algorithm and their corresponding public key certificates. The second-type containers are used to store key pairs based on the ML-DSA algorithm and their corresponding public key certificates. The certificates stored in the first-type containers and the certificates stored in the second-type containers have the same subject DN field. The client's middleware communicates with the container management module and is used to establish a one-to-one logical association between the first type of container and the second type of container based on a consistent topic DN field; The secure cryptographic operation module, connected to the container management module and the client's middleware, is used to respond to the client's middleware-forwarded single transaction signature instruction initiated by the client. In the same secure execution process, it calls the SM2 private key in the first type of container and the ML-DSA private key in the second type of container to sign the same transaction data, and outputs the double signature result consisting of the SM2 signature value and the ML-DSA signature value to the client's middleware at once.

[0006] The beneficial effects of the smart cryptographic key system supporting the ML-DSA algorithm provided by this invention are as follows: To address the rigidity of existing smart cryptographic key hardware storage architectures, this invention configures logically independent first and second type containers through a container management module. These containers store key pairs and corresponding public key certificates based on the SM2 algorithm and key pairs and corresponding public key certificates based on the ML-DSA algorithm, respectively. This allows the device to simultaneously accommodate two cryptographic systems with vastly different sizes, enabling smooth coexistence of multimodal certificates within the same hardware. Addressing the lack of atomicity in existing dual signature technologies, this invention establishes a one-to-one logical association between the first and second type containers through client-side middleware based on a consistent subject DN field. Upon receiving a single transaction signature instruction, the secure cryptographic operation module performs signatures on the same transaction data using both the SM2 and ML-DSA private keys within the same secure execution flow, outputting the dual signature result in a single step. This design completely avoids repeated authentication interactions caused by serial calls to the signature interface at the application layer, eliminates intermediate signature states resulting from independent signature timing, ensures the integrity and consistency of transaction data states, and significantly improves the security level and user experience of highly sensitive financial transactions.

[0007] Based on the above scheme, the intelligent cryptographic key system supporting the ML-DSA algorithm of the present invention can be further improved as follows.

[0008] Furthermore, the client's middleware is specifically used to: traverse all containers in the container management module during the initialization phase, extract the subject DN field of the certificate stored in the first type of container and compare it with the subject DN field of the certificate stored in the second type of container. When the comparison results match, establish a one-to-one correspondence between the handles of the first type of container and the handles of the second type of container in memory to obtain the logical association between the first type of container and the second type of container.

[0009] The beneficial effects of adopting the above-mentioned further scheme are as follows: by traversing the containers and comparing the certificate subject DN field, a one-to-one correspondence is established in memory between the handles of the first type of container and the handles of the second type of container. This process achieves automatic binding of two independent containers at the logical level, enabling subsequent signature operations to quickly locate the other associated container through any handle, avoiding manual intervention or pre-configuration. This dynamically established logical association provides an accurate addressing basis for the secure cryptographic operation module to perform atomic double signatures, ensuring that two containers under the same user identity can be called collaboratively, thus improving the accuracy and efficiency of transaction signature instruction execution.

[0010] Furthermore, the client's middleware is also used to: respond to a normal signature request initiated by the client, verify the PIN code entered by the user, and after successful verification, call the signature interface corresponding to the SM2 private key in the first type of container and the signature interface corresponding to the ML-DSA private key in the second type of container in turn to obtain the SM2 signature value and the ML-DSA signature value respectively, and encapsulate the SM2 signature value and the ML-DSA signature value into a double-signed data packet in PKCS#7 format and return it to the client.

[0011] The advantages of adopting the above-mentioned further solution are as follows: For ordinary signature scenarios such as login, after verifying the user's PIN code, the client's middleware sequentially calls the signature interface corresponding to the SM2 private key in the first type of container and the signature interface corresponding to the ML-DSA private key in the second type of container. This obtains the SM2 signature value and the ML-DSA signature value respectively, which are then encapsulated into a PKCS#7 format dual-signature data packet and returned to the client. This process implements dual signatures serially at the application layer, reusing the established container logic relationships without modifying the underlying atomic execution flow of the device. Two signature calls can be completed with a single PIN code verification, reducing the number of user interactions. Simultaneously, the standardized PKCS#7 encapsulation format facilitates unified signature verification on the server side, providing an efficient dual-identity authentication method for non-transactional scenarios such as login.

[0012] Furthermore, the secure cryptographic operation module is specifically used for: receiving a transaction signing instruction initiated by the client from the client's middleware via the client's middleware, verifying the PIN code entered by the user, wherein the transaction signing instruction carries the handles of the first type of container, the second type of container, and the transaction data; after successful verification, in the same secure execution process, signing the digest of the transaction data by calling the SM2 private key in the first type of container and the ML-DSA private key in the second type of container respectively, generating the SM2 signature value and the ML-DSA signature value, and outputting the SM2 signature value and the ML-DSA signature value as a double signature result to the client's middleware at once.

[0013] The beneficial effects of adopting the above-mentioned further scheme are as follows: The secure cryptographic operation module completes all operations—PIN code verification, digest calculation, SM2 private key signing, and ML-DSA private key signing—within a single transaction signature instruction, and outputs the two signature values ​​as an indivisible double-signature result at once. This atomic execution process eliminates the timing risks that may arise from serial calls at the application layer and completely avoids inconsistencies in transaction data caused by partial signature failures. Users only need to enter their PIN code once to complete the signature operations of two cryptographic systems simultaneously, reducing interaction steps and improving transaction efficiency. Meanwhile, the private key operation is completed entirely within a secure environment, and the double-signature results are output synchronously, providing complete data protection that meets compliance and quantum security requirements for highly sensitive financial transactions.

[0014] 2) In a second aspect, the present invention also provides a signature method for a smart cryptographic key device that supports the ML-DSA algorithm, the specific technical solution of which is as follows: A smart cryptographic key device supporting the ML-DSA algorithm is used. This device includes a container management module, client middleware, and a secure cryptographic operation module. The method includes: Through the container management module, configure logically independent first-class containers and second-class containers; the first-class container stores key pairs and corresponding public key certificates based on the national cryptographic SM2 algorithm, and the second-class container stores key pairs and corresponding public key certificates based on the ML-DSA algorithm, and the certificates stored in the first-class container and the certificates stored in the second-class container have the same subject DN field. Through the client's middleware, a one-to-one logical association is established between the first type of container and the second type of container based on a consistent topic DN field; Through the secure cryptographic operation module, in response to the client's middleware forwarding the single transaction signature instruction initiated by the client, the same transaction data is signed by calling the SM2 private key in the first type container and the ML-DSA private key in the second type container in the same secure execution process, and the double signature result consisting of the SM2 signature value and the ML-DSA signature value is output to the client's middleware at once.

[0015] 3) In a third aspect, the present invention also provides an electronic device, the electronic device including a processor coupled to a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to enable the electronic device to implement any of the above-mentioned signature methods for a smart cryptographic key device supporting the ML-DSA algorithm.

[0016] 4) In a fourth aspect, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned signature methods for a smart cryptographic key device supporting the ML-DSA algorithm.

[0017] It should be noted that the beneficial effects of the technical solutions of the second to fourth aspects of the present invention and their corresponding possible implementations can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below: Figure 1 This is a schematic diagram of the structure of an intelligent cryptographic key system supporting the ML-DSA algorithm according to an embodiment of the present invention; Figure 2 A schematic diagram illustrating the overall process of dual signature for corporate online banking login and transfer transactions.

[0019] Figure 3 A schematic diagram of the dual-container initialization and key generation process for a smart cryptographic key device.

[0020] Figure 4 This is one of the comparative diagrams of the dual signature process for corporate online banking.

[0021] Figure 5 This is the second illustration comparing the dual-signature process for corporate online banking.

[0022] Figure 6 A schematic diagram of the dual-container initialization and certificate import process for smart password key devices.

[0023] Figure 7 This is a flowchart illustrating a signature method for a smart cryptographic key device supporting the ML-DSA algorithm, according to an embodiment of the present invention. Detailed Implementation

[0024] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0025] The technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0026] like Figure 1As shown, an embodiment of the present invention provides an intelligent cryptographic key system supporting the ML-DSA algorithm, which includes a container management module, client middleware, and a secure cryptographic operation module. The container management module is configured to contain logically independent first-type and second-type containers. The first-type container stores key pairs and corresponding public key certificates based on the SM2 algorithm (China's national cryptographic standard). The second-type container stores key pairs and corresponding public key certificates based on the ML-DSA algorithm. The certificates stored in the first-type container and the certificates stored in the second-type container have the same Subject DN field. The specific implementation process is as follows: 1) In the secure file system of the smart cryptographic key device, two logically independent container types are predefined. The first type corresponds to the Chinese national cryptographic standard container, and its type identifier follows the existing SKF interface specification. It is used to store key pairs based on the Chinese national cryptographic SM2 algorithm and their corresponding public key certificates. The second type is defined as a quantum-resistant dedicated container, assigned a new container type value, such as CONTAINER_TYPE_PQ_SIG, and is used to store key pairs based on the ML-DSA algorithm and their corresponding public key certificates. These two types of containers are logically independent in the file system, each with its own independent storage space and access control permissions, ensuring that SM2 key materials and ML-DSA key materials are separated at the physical storage level, while being protected by the same security chip.

[0027] 2) Creating the first type of container: When issuing a digital certificate to a user, the certificate issuance tool calls the container creation interface SKF_CreateContainer, specifying the container type as a Chinese cryptographic standard container. The system allocates a storage area in the secure file system and initializes the container metadata, including container identifier, container type, container status, and container capacity. This container is ready to store subsequently generated key pairs based on the Chinese cryptographic SM2 algorithm and their corresponding public key certificates. Creating the second type of container: Similarly, the certificate issuance tool calls the container creation interface SKF_CreateContainer, but specifies the container type as a quantum-resistant dedicated container, with the type value set to the preset CONTAINER_TYPE_PQ_SIG. The system allocates another independent storage area in the secure file system and initializes the container metadata, including container identifier, container type, and container status. This container is specifically used to store key pairs based on the ML-DSA algorithm and their corresponding public key certificates. Its storage space must meet the large size requirements of ML-DSA algorithm keys and certificates; for example, an ML-DSA-44 public key is 1312 bytes, and the private key and certificate are correspondingly larger.

[0028] 3) The system calls the SKF_GenECCKeyPair interface to generate a signature key pair based on the SM2 algorithm within the first type of container. The generated private key is securely stored in the private key area of ​​the first type of container, while the public key can be obtained through the public key export interface for subsequent application for a public key certificate from a CA center. During the generation process, the system ensures the randomness and security of the key pair, conforming to relevant national cryptographic standards. The system then calls the extended PQC key generation interface SKFE_GenPQSigKeyPair, passing in the algorithm identifier, such as SGD_PQ_SIG_MLDSA44, to generate a signature key pair based on the ML-DSA algorithm within the second type of container. The generated private key is securely stored in the private key area of ​​the second type of container, and the public key can also be exported for certificate application. During the generation process, the system generates a lattice-based key according to the ML-DSA algorithm specification, ensuring quantum-resistant security.

[0029] 4) Obtain the SM2 public key from the first type of container by calling the public key export interface SKF_ExportPublicKey, and obtain the ML-DSA public key from the second type of container by calling the extension interface SKFE_ExportPQPublicKey. Submit these two public keys and user identity information to the CA center. When submitting, ensure that the Subject DN field used in the certificate applications is completely identical; that is, both certificate applications should contain the same information such as country, organization, and common name. The CA center will issue one SM2 public key certificate and one ML-DSA public key certificate, respectively, with the same Subject DN field in both certificates.

[0030] 5) Import the CA-issued SM2 public key certificate into the first type of container by calling the certificate import interface SKF_ImportCertificate to write the certificate data into the certificate storage area of ​​the first type of container and establish an association with the existing SM2 key pair within the container. Simultaneously, import the CA-issued ML-DSA public key certificate into the second type of container by calling the corresponding certificate import interface to write the certificate data into the certificate storage area of ​​the second type of container and establish an association with the existing ML-DSA key pair within the container. During the import process, the system verifies the integrity of the certificate and its matching with the private key. During certificate import, the system can automatically check whether the subject DN field of the imported certificate is consistent with the subject DN field of a certificate in another container belonging to the same user, or the upper-layer certificate issuance tool can ensure their consistency. Ultimately, the SM2 public key certificate stored in the first type of container and the ML-DSA public key certificate stored in the second type of container have completely identical subject DN fields, laying the foundation for subsequent container logical association.

[0031] 6) During the client-side middleware initialization phase, the middleware iterates through all containers in the container management module and extracts the subject DN field of the certificate stored in each container. Through string comparison, it establishes a one-to-one correspondence in memory between first-type and second-type container handles with the same subject DN field, forming a logical association. This allows subsequent operations to find the corresponding container using one handle, enabling collaborative work between the two containers. This association exists only in session memory and does not change the physical storage of the containers themselves.

[0032] The Subject DN field is a core data item in a public key certificate, short for Subject Distinguished Name. In the X.509 public key certificate standard, the Subject DN field uniquely identifies the certificate holder and typically includes attributes such as country, organization, and common name. In banking systems, the Subject DN field is often used to associate user identities, for example, containing the user's name or account information. In this technical solution, the Subject DN field is used as the logical association between certificates stored in the first type of container and certificates stored in the second type of container.

[0033] The client-side middleware communicates with the container management module and is used to establish a one-to-one logical association between the first type of containers and the second type of containers based on a consistent Subject DN field. Specifically, during the initialization phase, all containers in the container management module are traversed, and the Subject DN fields of the certificates stored in the first type of containers are extracted and compared with those stored in the second type of containers. When the comparison results match, a one-to-one correspondence is established in memory between the handles of the first type of containers and the handles of the second type of containers to obtain the logical association between the first type of containers and the second type of containers. The specific implementation process is as follows: 1) The client middleware starts and initializes the communication connection with the smart key device. The middleware calls the device connection interface, such as SKF_ConnectDevice, to obtain the device handle of the currently inserted smart key device. This handle represents the entire device object, and all subsequent operations on this device will reference this handle. The middleware verifies the device status through the device handle, ensuring that the device is ready and supports subsequent enumeration operations.

[0034] 2) The client middleware calls the container enumeration interface, such as SKF_EnumContainers, through the device handle to obtain basic information about all containers on the device. This interface returns a list of container handles, where each element corresponds to a handle of a created container. These containers may include type 1 and type 2 containers, and may also contain other types of containers. The middleware temporarily stores the returned list of container handles in memory as raw data to be processed.

[0035] 3) The client middleware iterates through the list of container handles, performing a certificate reading operation on each handle in turn. For the currently iterated container handle, the middleware calls the certificate retrieval interface, such as SKF_GetCertificate, to extract the stored public key certificate data from the container. If the container has not yet imported a certificate, this interface may return a null value, and the middleware will skip this container and continue iterating to the next one.

[0036] 4) For containers whose certificates are successfully read, the client middleware parses the ASN.1 structure of the certificate and extracts the complete content of the Subject DN field. The Subject DN field typically consists of multiple relatively identifiable Names (RDNs), such as Country (C), Organization (O), and Common Name (CN). The middleware concatenates these RDNs into a standard string format, such as CN=Zhang San, O=XXX Bank, C=CN, and temporarily stores this string. It also records the container's handle and container type. The container type can be obtained through the container attribute interface SKF_GetContainerInfo to distinguish whether the container is a Type I or Type II container.

[0037] 5) The client middleware organizes all extracted container information into a temporary data table, which contains three columns: container handle, container type, and subject DN string. After all containers have been traversed, the middleware obtains a complete list of container information. This list reflects the identity and certificate content of all existing containers in the current device.

[0038] 6) The client-side middleware performs pairwise matching on the temporary data table. It first filters out records belonging to container type 1 and extracts their subject DN strings; then, it searches for records in container type 2 that have the exact same subject DN string. The string comparison uses an exact match method, requiring the two subject DN strings to be completely identical at the byte level to ensure a unique correspondence of identities.

[0039] 7) When a record in a first-type container and a record in a second-type container are found to have the same subject DN string, the client middleware determines that the two containers belong to the same user. At this point, the middleware creates a mapping entry in memory, using the handle of the first-type container as the key and the handle of the second-type container as the value, and stores it in a dedicated mapping table structure for association. This mapping table can be implemented using a hash table or a balanced tree to ensure the efficiency of subsequent lookups.

[0040] 8) The client middleware continues to traverse the remaining records, repeating the above comparison process until all possible pairings have been processed. Ultimately, the in-memory mapping table contains all successfully paired container handle pairs. If a first-type or second-type container does not find a corresponding container with a matching topic DN, that container is not included in the mapping table and will be used as an independent single container in subsequent business logic.

[0041] 9) The client middleware binds the established mapping table to the current device session and stores a reference to this mapping table in the session context. At this point, the container logical associations established during the initialization phase are complete. Subsequently, when the client initiates a request involving dual signatures, the middleware can quickly find the handle of the other associated container in the mapping table using the handle of either container, thus enabling collaborative operation between the two containers. This memory-mapped association is only valid during the current session and is destroyed when the device is unplugged or the session ends, ensuring real-time consistency for each use.

[0042] In this context, a handle is an abstract identifier used during the interaction between the smart key device and the client middleware. In a computer system, a handle is a unique value or pointer representing a resource object managed by the system kernel or driver layer. In this technical solution, the handle of the first type of container is a reference value generated by the container management module when creating the container and returned to the upper-layer application. It points to the data structure in memory representing that container. The client middleware can use this handle to send instructions to the smart key device to perform operations such as key generation, certificate import, and signature calculations on the container. The introduction of handles eliminates the need for upper-layer applications to directly manipulate physical storage addresses, ensuring security and modularity.

[0043] The one-to-one correspondence between the handles of the first type of container and the handles of the second type of container refers to a mapping table structure established in the memory of the client middleware. This mapping table exists in the form of key-value pairs, where each key corresponds to a handle of the first type of container and each value corresponds to a handle of the second type of container. This mapping is unidirectional and one-to-one, meaning that a handle of the first type of container is uniquely associated with a handle of the second type of container. This one-to-one correspondence is obtained by comparing the consistency of the Certificate Subject DN field, ensuring that two containers under the same user identity are bound together, providing the addressing basis for subsequent double-signature operations.

[0044] The logical association between the first and second types of containers refers to the fact that two physically independent containers are treated as a single logical unit within the client middleware session, jointly serving the same user's certificate system. This association does not alter the physical storage structure of the containers on the device; instead, it is implemented through a handle mapping table in memory. This allows applications to easily obtain the handle of one container using the handle of another, or to reference both containers simultaneously within a single signing instruction. This logical association enables upper-layer business logic to transparently handle dual-certificate scenarios without needing to concern itself with how the underlying containers are managed.

[0045] The secure cryptographic operation module, connected to the container management module and the client's middleware, responds to single-transaction signature instructions initiated by the client and forwarded by the client's middleware. Within the same secure execution flow, it signs the same transaction data using the SM2 private key in the first type of container and the ML-DSA private key in the second type of container, and outputs a double-signature result consisting of the SM2 signature value and the ML-DSA signature value to the client's middleware in one go. Specifically: After receiving the transaction signing instruction initiated by the client from the client's middleware, the middleware verifies the PIN code entered by the user. The transaction signing instruction carries handles to the first type of container, the second type of container, and the transaction data. After successful verification, in the same secure execution flow, the digest of the transaction data is signed using the SM2 private key in the first type of container and the ML-DSA private key in the second type of container, generating an SM2 signature value and an ML-DSA signature value. The SM2 signature value and the ML-DSA signature value are then output as a double-signature result to the client's middleware at once. The specific implementation process is as follows: 1) Client-side applications, such as online banking websites or mobile banking apps, will process the transaction data to be signed after the user confirms that the transaction information is correct. The transaction is assembled according to the business agreement. The client calls the transaction double-signature interface provided by the client's middleware, such as PQECCDigestSignData, and explicitly passes the handle of the first type of container in the interface parameters. Handles of second-class containers and transaction data When the client's middleware receives this call request, it obtains a complete transaction signature instruction.

[0046] 2) The client-side middleware requests a PIN code from the user. The client-side middleware prompts the user to enter a PIN code by displaying an input box on the interface or by calling a system secure input control. The user enters the PIN code string in a trusted environment. The client's middleware retrieves this string. To ensure secure transmission, the client's middleware may establish a secure channel with the smart key device to encrypt the PIN code before transmission, or it may transmit it securely directly through the underlying driver interface.

[0047] 3) The client's middleware forwards the transaction signing instruction to the smart key device. The client's middleware uses the handle of the first type of container obtained in step one. Handles of second-class containers Transaction data And the PIN code entered by the user obtained in step two. The data is assembled into a command packet that conforms to the device driver specification. The client's middleware then calls the device driver interface, such as SKFE_PQECCDigestSignData, to send this command packet to the smart key device. This command explicitly instructs the device to perform an atomic double-signature operation.

[0048] 4) After receiving the transaction signature instruction, the smart key device first verifies the PIN code entered by the user within its security chip. The device extracts the PIN code string from the instruction data packet. The device then compares the PIN with the one pre-stored in the device's secure storage area that belongs to the current user (implicitly associated with the container handle). If the comparison results are inconsistent, the device immediately terminates the process and returns an error code to the client's middleware, indicating that the PIN verification failed; if the comparison is consistent, the device marks the current session as authenticated, allowing subsequent private key operations to continue.

[0049] 5) After successful PIN code verification, the smart key device prepares to sign the transaction data. The device first calculates the transaction data. Summary. According to the preset security strategy, to ensure quantum-resistant security, the device uses a sufficiently strong hash algorithm, such as SHA-512, on the transaction data. Perform a hash operation to obtain a summary of the transaction data. The calculation formula is: ,in, This is the original transaction data. The generated digest value is 512 bits long. (If transaction data...) It is already a digest value, and the device may also use it directly as a digest. The specific behavior is determined by the interface definition.

[0050] 6) The smart cryptographic key device uses the private keys of two containers for signing within the same secure execution process, preventing any external interruptions or interference and ensuring the atomicity of the operation. First, the device uses the handle of the first type of container... Locate the corresponding container and securely extract the SM2 private key from it. Then, regarding the abstract... Perform SM2 signature calculation to generate SM2 signature value. The SM2 signature algorithm conforms to the national standard GB / T32918, and its operation process can be represented as follows: ,in, For the SM2 private key in the first type of container, A summary of transaction data. This generates the SM2 signature value. Next, the device uses the handle of the second type of container... Locate the quantum-resistant dedicated container and extract the ML-DSA private key from it. Then, for the same abstract Perform ML-DSA signature calculation to generate ML-DSA signature value. The ML-DSA signature algorithm follows the NISTFIPS 204 standard, and its operation process can be represented as follows: ,in, For the ML-DSA private key in the second type of container, A summary of transaction data. This is the generated ML-DSA signature value. Both signature operations are performed consecutively inside the secure chip, and the private key is never exposed to the outside.

[0051] 7) The smart key device will generate the SM2 signature value. and ML-DSA signature value The two signatures are combined to form a double-signature result. The device packages the two signature values ​​into a contiguous byte array according to a predefined format. For example, first store... Length field Store again Its own byte content, then stored Length field Finally, store The byte content. This packaging process is completed internally by the device, ensuring that the output is an indivisible whole, without any intermediate state where only a portion of the signature value is output.

[0052] 8) The smart cryptographic key device outputs the combined double-signature result to the client's middleware in one go. The device returns the entire byte array to the client's middleware through the driver interface. Upon receiving the complete return data, the client's middleware can confirm that the atomic double-signature operation has been successfully completed, without any partial failure.

[0053] After receiving the double-signature result, the client's middleware encapsulates it into a PKCS#7 format double-signature data packet according to application requirements. The client's middleware creates a SignedData object according to the PKCS#7 standard, sets the signer information, and stores the SM2 signature value. and ML-DSA signature value Place them into the corresponding SignerInfo objects. If the original text needs to be included, then include the transaction data. It is also encapsulated into the data packet. After encapsulation, the client's middleware returns the final PKCS#7 data packet to the client application.

[0054] The client application sends the received PKCS#7 double-signature data packet to the online banking server over the network. Upon receiving the data packet, the server calls a hybrid signature verification interface, such as verifyMixSignedMessage, to verify the validity of the SM2 signature and ML-DSA signature, respectively. The server extracts the signature value, certificate, and plaintext from the data packet, performs verification using the corresponding public key, and decides whether to process the transaction based on the verification result. The entire atomic double-signature process is then complete.

[0055] Atomic double signature refers to a middleware mechanism within the secure cryptographic operation module that, in response to a single transaction signature command, sequentially uses the SM2 private key from the first type of container and the ML-DSA private key from the second type of container to sign the digest of the same transaction data within the same secure execution flow. The generated SM2 and ML-DSA signature values ​​are then combined and returned to the client in a single middleware operation. This method ensures the synchronous completion of the two signature operations and the complete output of the results, avoiding the problem of missing signature values ​​due to timing discrepancies or device malfunctions, thus ensuring the integrity and non-repudiation of the transaction data.

[0056] PIN code, short for Personal Identification Number, is a credential used in smart key devices to verify a user's right to legally possess and use the device. When performing sensitive operations such as signing, users must enter the correct PIN code. The device compares the entered PIN code with a pre-stored PIN code in a secure storage area. Only after successful verification can subsequent private key operations be allowed, preventing unauthorized use of the device if it is lost. PIN codes are typically set by the user and are generally 6 to 8 digits or letters. Their secure storage and verification process are completed within the smart key's secure chip, ensuring they cannot be stolen externally.

[0057] Transaction data refers to the original information generated by the client during a financial transaction that requires digital signature. Taking bank transfers as an example, transaction data includes a set of key fields such as the recipient's account number, recipient's name, transfer amount, transaction time, and transaction serial number, and may also contain other agreed-upon information between the transacting parties. Transaction data represents the specific content of the transaction, and digitally signing it ensures the authenticity, integrity, and non-repudiation of the transaction. Before the actual signing operation, the transaction data is usually hashed to obtain a digest of the transaction data to improve signing efficiency and security. The format of the transaction data is defined by the application layer protocol and must remain complete and consistent during transmission and storage.

[0058] In this context, the client-side middleware is a software layer running on the user's computer or mobile device. It sits between the online banking client application and the smart key device, acting as a bridge and coordinator. The client-side middleware is responsible for communicating with the smart key device's driver, encapsulating the complex underlying command interfaces, and providing a simple and easy-to-use application programming interface (API) to the upper-layer application. In a dual-signature scenario, the client-side middleware receives the transaction signing command initiated by the client, parses the parameters carried in the command, calls the device driver interface, sends the command to the smart key device, and, upon receiving the device's response, encapsulates the result as necessary before returning it to the client. The client-side middleware also handles device discovery, container enumeration, and certificate reading, serving as the core hub for interaction between the client and the hardware device.

[0059] Optionally, in the above technical solution, the client's middleware is further used to: respond to a normal signature request initiated by the client, verify the PIN code entered by the user, and after successful verification, successively call the signature interface corresponding to the SM2 private key in the first type of container and the signature interface corresponding to the ML-DSA private key in the second type of container to obtain the SM2 signature value and the ML-DSA signature value respectively, and encapsulate the SM2 signature value and the ML-DSA signature value into a double-signed data packet in PKCS#7 format and return it to the client. The specific implementation process is as follows: 1) For example, on an online banking login page, after the user enters their username and password and clicks the login button, the client obtains a random number challenge value from the server for authentication. The client constructs a standard signature request and calls a standard double-signature interface provided by the client's middleware, such as PQECCSignData. The data to be signed is passed into this interface call. Simultaneously, it may pass in container selection information related to the user, such as the certificate subject DN obtained through a previous query or by the client's middleware directly finding the corresponding container handle based on the user's login name. Upon receiving this request, the client's middleware begins the processing flow.

[0060] 2) The client-side middleware displays a secure input dialog box via the interface, prompting the user to enter the PIN code for the smart key. The user enters the PIN code string in a trusted input environment. The client's middleware retrieves this string. To ensure secure transmission, the client's middleware temporarily stores the PIN code in a protected memory area and prepares to send it to the smart key device for verification via a secure channel.

[0061] 3) The client-side middleware verifies the PIN code entered by the user. The client-side middleware calls the PIN code verification interface of the smart key device, such as SKF_VerifyPIN, and sends the PIN code string... Send to the device. The smart password key device receives the PIN code within its security chip. The device compares the PIN code with the pre-stored PIN code associated with the current user in the secure storage area. If the comparison fails, the device returns an error code, the client's middleware returns a verification failure message to the client, and the process terminates. If the comparison succeeds, the device marks the current session as authenticated, allowing subsequent private key signing operations, and returns a verification success response to the client's middleware.

[0062] 4) After successful PIN code verification, the client's middleware prepares to call the signature interface corresponding to the SM2 private key in the first type of container. Based on the previously established container logical relationships, the client's middleware retrieves the handle of the first type of container corresponding to the current user from the memory mapping table. The client's middleware constructs SM2 signature instructions, calls the standard ECC signature interface SKF_ECCSignData, and passes in the handle of the first type of container. and data to be signed The instruction is sent to the smart key device. This instruction instructs the device to sign the data using the SM2 private key stored in the first type of container.

[0063] 5) The smart key device performs an SM2 signature operation and returns the SM2 signature value. The device, based on the received instructions, uses the handle of the first type of container. Locate the corresponding container and securely extract the SM2 private key from it. The device first processes the signature data. To perform hash operations, according to national cryptographic standards, the SM3 hash algorithm is typically used to calculate the digest. The calculation formula is: ,in, The data to be signed is passed in by the client. This is the generated 256-bit digest value. The device then uses the SM2 private key. Abstract Perform signature calculations to generate an SM2 signature value. The calculation process is expressed as follows: The device will generate the SM2 signature value. The middleware returned to the client.

[0064] 6) After receiving the SM2 signature value, the client's middleware continues to call the signature interface corresponding to the ML-DSA private key in the second type of container. The client's middleware retrieves the handle of the second type of container associated with the first type of container from the memory mapping table. The client's middleware constructs the ML-DSA signature instruction, calls the extended PQC signature interface SKFE_PQSignData, and passes in the handle of the second type of container. And the same data to be signed The instruction is sent to the smart key device. This instruction instructs the device to sign the data using the ML-DSA private key stored in the second type of container.

[0065] 7) The smart key device performs ML-DSA signature calculation and returns the ML-DSA signature value. The device, according to instructions, uses the handle of the second type of container. Locate the corresponding quantum-resistant dedicated container and securely extract the ML-DSA private key from the container. The device treats signature data. To perform hash operations, in accordance with the requirements of the quantum-resistant algorithm ML-DSA, the SHA-512 hash algorithm is typically used to calculate the digest. The calculation formula is: ,in, The data to be signed is passed in by the client. This is the generated 512-bit digest value. The device then uses the ML-DSA private key. Abstract Perform signature calculations to generate ML-DSA signature values. The calculation process is expressed as follows: The device will generate the ML-DSA signature value. The middleware returned to the client.

[0066] 8) After receiving the two signature values, the client's middleware encapsulates them into a double-signature data packet in PKCS#7 format. The client's middleware creates a SignedData object according to the PKCS#7 standard, setting the version number, digest algorithm identifier, etc. A SignerInfo structure is created for each signature value, containing the SM2 signature value. The ML-DSA signature value is placed in the first SignerInfo file along with its corresponding certificate or certificate identifier. The corresponding certificate or certificate identifier is placed in the second SignerInfo. Depending on application requirements, a detached mode can be selected, meaning the data packet does not contain the original data to be signed. Alternatively, the application layer can send the original data separately; or the attached mode can be selected to send the original data... It is also encapsulated in the data packet. After the client's middleware completes the data packet assembly, it obtains a complete double-signed data packet in PKCS#7 format.

[0067] 9) The client's middleware returns the encapsulated PKCS#7 formatted double-signature data packet to the client application. Upon receiving this packet, the client application sends it to the server for login verification according to the online banking protocol. Upon receiving the packet, the server calls the hybrid signature verification interface to verify the validity of the SM2 signature and ML-DSA signature respectively, and decides whether to allow the user to log in based on the verification results. The entire process of processing a normal signature request is now complete. This process is executed serially at the application layer and does not require atomic operations within the device.

[0068] A standard signature request refers to a signature request initiated by a client application in financial information system login scenarios or non-transactional authentication scenarios. Standard signature requests typically do not involve specific financial transaction elements such as amount or payee; instead, they involve signing a random number or challenge value issued by the server to prove that the user possesses the private key of a legitimate digital certificate, thereby completing user authentication. For example, when a user logs into an online banking system, the server generates a random number and requests the client to sign it. The client uses a smart key to sign the random number and returns it to the server for verification. The server verifies the signature to confirm the user's identity. Standard signature requests have lower security requirements than transaction signature requests; therefore, the processing allows for application-layer serial calls to the signature interface, obtaining two signature values ​​sequentially before encapsulation, without requiring atomic operations within the device.

[0069] For common signature request scenarios such as online banking login, the client's middleware adopts a serial double-signature strategy, that is, serially calling the signature interface to achieve double signature.

[0070] Optionally, it also includes: implementing full key lifecycle management through an extended application programming interface (API): calling the SKFE_GenPQSigKeyPair interface to generate a signature key pair based on the ML-DSA algorithm within the second type of container; calling the SKFE_ExportPQPublicKey interface to export the ML-DSA public key from the second type of container for use in applying for a public key certificate from a CA center; the ML-DSA public key certificate issued by the CA center is written into the second type of container through a certificate import interface and associated with the private key within the container. All of the above operations are independent of the SM2 key management process in the first type of container, ensuring that the keys of the two cryptographic systems do not interfere with each other. Full key lifecycle management refers to the complete control over the generation, export, import, and use of key pairs based on the ML-DSA algorithm.

[0071] Figure 2 This fully demonstrates the dual-signature process for corporate online banking login and transfer transactions, involving the client, client middleware, and smart password key device (i.e., Figure 2 The system comprises several components, including a "UKey driver & quantum-resistant UKey," a server-side quantum-resistant SSL gateway, an online banking application, and a quantum-resistant signature server. Users first access the enterprise's online banking system through a browser, establishing a TLS 1.3+X25519 encrypted channel with the quantum-resistant SSL gateway and negotiating MLKEM768 quantum key encapsulation to complete the HTTPS handshake. The gateway forwards the offloaded HTTP data to the online banking application, which returns HTML, JS, CSS, and other resources to the client. After the page loads, the front-end JavaScript calls the client's middleware's findCert interface to query the SM2 and ML-DSA certificates stored in the device using specific attributes of the certificate subject DN field. The client's middleware then calls the SKFE_ExportPQPublicKey function via the SKF interface to export the ML-DSA public key certificate from the second type of container (i.e., the PQC container) and simultaneously obtains the SM2 public key certificate from the first type of container (i.e., the SM2 container), returning the public key certificates to the front-end. The frontend displays the user account information based on the CN field in the certificate. After the user enters the PIN code and clicks login, the frontend assembles the login message and initiates a normal signature request by calling the PQECCSignData interface via JavaScript. Upon receiving the request, the client's middleware performs serial double signature by simultaneously calling the signMessage and SKFE_PQSignData interfaces via the SKF interface: first, it uses the SM2 private key from the first type of container to generate a login random number. Perform the signing to obtain the SM2 signature value. Then, use the ML-DSA private key from the second type of container to generate the same random number. Perform the signing to obtain the ML-DSA signature value. The smart key device (UKey) performs the aforementioned signature operation after the user successfully verifies their PIN code once, and returns two signature data points to the client's middleware. The client's middleware encapsulates the received two signature data points in a PKCS#7 signature data packet and sends it to the server over the network. The server-side quantum-resistant SSL gateway receives, unloads, and forwards the data to the online banking application. The online banking application verifies the signature by calling the `verifySignedMessage` function via API, verifying the two signature data points in the PKCS#7 data packet and returning the verification result and certificate information from the signature data. It then verifies the CN field of the public key certificate and returns a success / failure login result to the client based on the verification result. In the scenario of executing a transfer transaction, after the user confirms the transfer information, the frontend initiates a transaction signature command by calling the transaction double-signature interface `PQECCDigestSignData` via JavaScript. The client's middleware performs transaction signing by calling the newly defined `SKFE_PQECCDigestSignData` interface through the SKF interface, passing in the handle of the first type of container. Handles of second-class containers and transaction data After the user re-enters the PIN code and presses the OK button on the UKey to confirm, the smart password key device performs atomic double signature within the secure password calculation module: calculating the transaction data digest. Using SM2 private keys respectively and ML-DSA private key Abstract Signature, generate SM2 signature value and ML-DSA signature value The middleware on the client side then returns both signature data points to the client's middleware at once. The client's middleware encapsulates the two signature data points in a PKCS#7 signature data packet (usually containing the original text) and sends it to the server. The server, after receiving, unloading, and forwarding the data, allows the online banking application to verify the signature by calling the `verifySignedMessage` function via API. This verifies the two signature data points in the PKCS#7 data packet, returns the verification result and certificate information, verifies the public key certificate (CN), and then returns a success / failure message to the client based on the verification result (corresponding to successful or failed transaction in the transaction scenario).

[0072] Figure 3 This demonstrates the complete process of dual-container initialization and key generation within the smart cryptographic key device, specifically the first type of container in the container management module (i.e., Figure 3 The "National Cryptographic Standard Container (SM2)" and the second category of containers (i.e. Figure 3The document describes the entire process of creating and importing a "Quantum-Resistant Dedicated Container (PQC)". The process begins with step one: building an independent container architecture. The certificate issuance tool calls the container creation interface SKF_CreateContainer to create a first-type container. This container conforms to the existing SKF interface specification and is used to store key pairs based on the Chinese national cryptographic algorithm SM2 and their corresponding public key certificates. Then, SKF_CreateContainer is called again, specifying the container type value as 0x08 (i.e., CONTAINER_TYPE_PQ_SIG) to create a second-type container. This container is specifically used to store key pairs based on the ML-DSA algorithm and their corresponding public key certificates. After container creation is complete, proceed to step two: generate key pairs separately. First, for the first type of container, call the standard SM2 key generation interface SKF_GenECCKeyPair to generate a key pair based on the national cryptographic SM2 algorithm within the container. Then, for the second type of container, call the extended post-quantum key generation interface SKFE_GenPQSigKeyPair, passing in the algorithm identifier (e.g., SGD_PQ_SIG_MLDSA44), to generate a key pair based on the ML-DSA algorithm within the container. After key generation, export public keys from both containers using the public key export interface. The public key exported from the second type of container is called the ML-DSA public key, and the one exported from the first type of container is called the SM2 public key. Subsequently, submit the two exported public keys and user identity information to the CA center. The CA center issues two certificates: an SM2 public key certificate and an ML-DSA public key certificate, strictly ensuring that the subject DN field of the two certificates is completely identical, ultimately forming dual certificates. The process proceeds to step three: certificate import and association. The CA-issued SM2 public key certificate is imported into the first type of container, and the ML-DSA public key certificate is imported into the second type of container. During import, the system verifies the match between the certificate and the private key within the container, completing the association between the certificate and the key. At this point, initialization is complete. The two containers respectively store the SM2 certificate and the ML-DSA certificate with consistent subject DN fields, laying a solid foundation for subsequent logical association establishment by the client middleware and the execution of dual-signature operations.

[0073] Figure 4 Using a comparative diagram of the entire dual-signature process in corporate online banking, this paper highlights the logical differences within smart password key devices under two scenarios: ordinary signature and transaction signature. The main participants involved in the diagram include the client (i.e.,...) Figure 4 "Online banking client / user" in the text), and the client's middleware (i.e. Figure 4 The "signature control (middleware)" and smart password key devices (i.e. Figure 4 The "UKey device (driver and security hardware)" and the server (i.e. Figure 4The "server-side (signature verification service)" in the context of Scenario 1: Ordinary Signature (Login) - Application Layer Serial Mode. The user first inserts a UKey. During the initialization phase, the client's middleware discovers a first-type container and a second-type container (i.e., dual containers (SM2 / PQC)) within the device and establishes a logical association. After the user enters their PIN code, the client's middleware calls the PIN code verification interface SKF_VerifyPIN for authentication. After successful authentication, it sequentially calls the standard ECC signature interface SKF_ECCSignData (i.e., calls SKF_ECCSignData(SM2 signature)) to perform an SM2 signature using the SM2 private key in the first-type container, and then calls the extended quantum signature interface SKFE_PQSignData (i.e., calls SKFE_PQSignData(ML-DSA signature)) to perform an ML-DSA signature using the ML-DSA private key in the second-type container. These two signature calls are executed serially at the application layer, triggering the smart key device's internal password authorization verification, SM2 private key operation, and ML-DSA private key operation, respectively, generating and returning SM2 and ML-DSA signature values. The client's middleware encapsulates the two signature values ​​into a PKCS#7 double-signature packet and sends it to the server. The server calls the mixed signature verification interface verifyMixSignedMessage to verify the SM2 and ML-DSA signatures in parallel, i.e., server-side mixed signature verification (SM2 verification + PQC verification), and returns a structured verification result. In Scenario 2: Transaction Signature (Transfer) - Driver Layer Atomic Aggregation Mode (UKey Core Logic), when a user initiates a transfer and assembles a message, the client calls the atomic double-signature interface PQECCDigestSignData, passing in the handles of the first type of container and the second type of container, i.e., passing in the SM2 + PQC double handles. The client's middleware transmits the instruction to the smart key device. The device executes an atomic process within the UKey's internal security handling (atomic operations): First, security check 1 is performed to verify that the hash algorithm strength is SHA-512 to prevent downgrade attacks; then, security check 2 is performed to confirm the PIN code authorization status; next, the transaction information (amount: 1000.00) is displayed on the screen, and the device waits for physical key confirmation; after user confirmation, the device performs atomic calculations, including locking memory data and calling the SM2 private key to generate the SM2 signature value Sig_SM2 (i.e.,...). ), and call the PQC private key to generate the ML-DSA signature value Sig_PQC (i.e. Finally, the two signature values, along with the certificates, are returned to the client's middleware in one go, resulting in a dual-signature + dual-certificate solution. The client's middleware encapsulates the result into a PKCS#7 data packet containing two SignerInfo values ​​and sends it to the server. The server then calls the mixed signature verification interface verifyMixSignedMessage again to verify the SM2 signature and ML-DSA signature in parallel and returns a structured verification result. Figure 4 The differences in the signature process under the two scenarios are clearly presented: ordinary signatures adopt the application layer serial mode, while transaction signatures adopt the device-level atomic aggregation mode, thereby ensuring security while meeting the needs of different business scenarios.

[0074] Figure 5 The diagram illustrates the entire process of dual signatures in corporate online banking, showcasing the differences between ordinary signatures and transaction signatures from the client side. Figure 5 The complete interaction process from the "online banking client / user" to the server is highlighted, emphasizing the smart password key device (i.e. Figure 5 The diagram illustrates the security processing logic within the "smart password key device." The main participants involved include the client, the client's middleware (i.e.,...) Figure 5The middleware consists of a "signature control", a smart key device, and a server. In Scenario 1: Ordinary Signature (Login) - Serial Dual Signature, the user first inserts a UKey (i.e., a smart key device). During the initialization phase, the client's middleware discovers a first type of container and a second type of container (i.e., dual containers (SM2 / PQC)) within the device and establishes a logical association. After the user enters a PIN code, the client's middleware calls the PIN code verification interface SKF_VerifyPIN for identity authentication. After successful authentication, it sequentially calls the standard ECC signature interface SKF_ECCSignData (i.e., calls SKF_ECCSignData(SM2 signature)) to perform an SM2 signature using the SM2 private key in the first type of container, and then calls the extended quantum signature interface SKFE_PQSignData (i.e., calls SKFE_PQSignData(ML-DSA signature)) to perform an ML-DSA signature using the ML-DSA private key in the second type of container. These two signature calls are executed serially at the application layer, triggering the smart key device's internal password authorization verification, SM2 private key operation, and ML-DSA private key operation, respectively, generating and returning SM2 and ML-DSA signature values. The client's middleware encapsulates the two signature values ​​into a PKCS#7 dual-signature packet and sends it to the server. The server calls the mixed signature verification interface verifyMixSignedMessage to verify the SM2 and ML-DSA signatures in parallel, i.e., server-side mixed signature verification (SM2 verification + PQC verification), and returns a structured verification result. In Scenario 2: Transaction Signature (Transfer) – Atomic Dual Signature, when a user initiates a transfer and assembles a message, the client calls the atomic dual-signature interface PQECCDigestSignData, passing in the handles of the first type of container and the second type of container, i.e., passing in the SM2 + PQC dual handles. The client's middleware transmits the instruction to the smart key device. The device executes an atomic process within the UKey's internal security handling (atomic operations): First, security check 1 is performed, checking the hash algorithm strength (e.g., SHA-512) to prevent downgrade attacks; then, security check 2 is performed to confirm the PIN code authorization status; next, the transaction information is displayed on the screen, and the user waits for physical key confirmation; after confirmation, the device performs atomic calculations, including locking memory data and generating an SM2 signature value using the SM2 private key. 1. Use the PQC private key to generate an ML-DSA signature value (That is, calling the PQC private key -> Sig_PQC), and finally returning the two signature values ​​and the corresponding certificate or certificate identifier (optionally returning the certificate / certificate identifier) ​​to the client's middleware. The client's middleware encapsulates the result into a PKCS#7 data packet containing two SignerInfo values ​​and sends it to the server. The server then calls the mixed signature verification interface verifyMixSignedMessage again to verify the SM2 signature and ML-DSA signature in parallel, and returns the structured verification result. Figure 5 The differences in the signature process under the two scenarios are clearly presented: ordinary signatures use serial double signatures, while transaction signatures use atomic double signatures, thus ensuring security while meeting the needs of different business scenarios.

[0075] Figure 6 The flowchart illustrates the complete steps of dual-container initialization and key generation within the smart password key device, specifically the first type of container in the container management module (i.e., Figure 6 The "National Cryptographic Standard Container (SM2)" and the second category of containers (i.e. Figure 6The document describes the entire process of creating and importing a "Quantum-Resistant Dedicated Container (PQC)". The process begins with step one: building an independent container architecture. The certificate issuance tool calls the container creation interface SKF_CreateContainer to first create a first-type container (i.e., a Chinese cryptographic standard container (SM2)). This container conforms to the existing SKF interface specification and is used to store key pairs based on the Chinese cryptographic SM2 algorithm and their corresponding public key certificates. Then, SKF_CreateContainer is called again, specifying the container type value as 0x08 (i.e., CONTAINER_TYPE_PQ_SIG) to create a second-type container (i.e., a quantum-resistant dedicated container (PQC)). This container is specifically used to store key pairs based on the ML-DSA algorithm and their corresponding public key certificates. After container creation is complete, proceed to step two: generate key pairs separately. First, for the first type of container, call the standard SM2 key generation interface SKF_GenECCKeyPair to generate a key pair based on the national cryptographic SM2 algorithm (i.e., an SM2 key pair) within the container. Then, for the second type of container, call the extended post-quantum key generation interface SKFE_GenPQSigKeyPair, passing in the algorithm identifier (e.g., SGD_PQ_SIG_MLDSA44), to generate a key pair based on the ML-DSA algorithm (i.e., an ML-DSA key pair) within the container. After key generation, export public keys from both containers using the public key export interface, and then submit the two exported public keys and user identity information to the CA center. The CA center issues two certificates: an SM2 public key certificate and an ML-DSA public key certificate, strictly ensuring that the SubjectDN field (i.e., SubjectDN) of the two certificates is completely identical, ultimately forming dual certificates. The process proceeds to step three: certificate import and association. The CA-issued SM2 public key certificate is imported into the standard container (i.e., the first type of container), and the ML-DSA public key certificate is imported into the PQC container (i.e., the second type of container). During import, the system verifies the matching between the certificate and the private key within the container, completing the association between the certificate and the key. At this point, initialization is complete. The two containers store the SM2 certificate and the ML-DSA certificate with consistent subject DN fields, respectively, laying a solid foundation for establishing logical associations with the client's middleware and performing dual-signature operations.

[0076] Example 1: Initialization of the dual-container system and key generation within the smart cryptographic key, specifically including the following steps: S101. The certificate issuance tool calls the container creation interface SKF_CreateContainer. First, it creates a first-type container (i.e., a standard SM2 container), for example, named "Con_SM2". Then, it creates a second-type container (i.e., a quantum-resistant dedicated container) with a type value of 0x08 (i.e., CONTAINER_TYPE_PQ_SIG), for example, named "Con_PQC". These two containers are logically independent in the container management module and are used to store key materials for different algorithms.

[0077] S102. For the first type of container "Con_SM2", the standard SM2 key generation interface SKF_GenECCKeyPair is called to generate a key pair based on the Chinese national cryptographic SM2 algorithm. For the second type of container "Con_PQC", the extended post-quantum key generation interface SKFE_GenPQSigKeyPair is called, and the algorithm identifier SGD_PQ_SIG_MLDSA44 (value 0x01400001) is passed in to generate a key pair based on the ML-DSA algorithm within the container, specifically the ML-DSA-44 parameter set. During the key generation process, the private key is securely stored in the corresponding container, and the public key can be exported for certificate application.

[0078] S103. The system calls the public key export interface SKFE_ExportPQPublicKey to export the ML-DSA public key from the second type of container "Con_PQC", and simultaneously calls the standard public key export interface to export the SM2 public key from the first type of container "Con_SM2". These two public keys and the user's identity information are submitted to the CA center. The CA center issues two public key certificates: one SM2 public key certificate and one ML-DSA public key certificate. Ensure that the subject DN field (i.e., the DN field) in the certificates is completely consistent, for example, containing the same country, organization, and common name. After the certificates are issued, the SM2 public key certificate is imported into the first type of container "Con_SM2", and the ML-DSA public key certificate is imported into the second type of container "Con_PQC". During import, the system verifies the matching between the certificate and the private key within the container, completing the container's initialization configuration.

[0079] Example 2: Implementation Logic of Serial Double Signature for Online Banking Login. This example demonstrates the serial double signature logic for the login process, i.e., the double signature process in a normal signature request scenario, to ensure the authenticity of the user's identity. Specifically, it includes the following steps: S201. When the user inserts the smart password key, the client's middleware (i.e., the online banking client control) traverses all containers in the container management module and finds that the certificates stored in the first type of container "Con_SM2" and the second type of container "Con_PQC" have the same subject DN field (i.e., DN). Based on this consistency, the client's middleware establishes a one-to-one correspondence between the handles of the first type of container and the handles of the second type of container in memory, thereby associating the two containers in the session.

[0080] S202. The webpage prompts "Please enter the smart key password". The user enters the PIN code, and the front end calls the PIN code verification interface SKF_VerifyPIN to send the PIN code to the secure password calculation module for verification. If the verification fails, the process terminates; if successful, the smart key enters the authenticated state, allowing subsequent private key calculations.

[0081] S203. The front-end JavaScript calls the standard double-signature interface PQECCSignData, which is implemented by the client's middleware. The client's middleware first calls the standard ECC signature interface SKF_ECCSignData, passing in the handle of the first type of container "Con_SM2", and performs a random number generation process for login. Perform an SM2 signature to obtain the SM2 signature value (i.e., Sig_SM2). The client's middleware then calls the extended post-quantum signature interface SKFE_PQSignData, passing in a handle to the second type of container "Con_PQC", and performs a random number transfer. Perform ML-DSA signing to obtain the ML-DSA signature value (i.e., Sig_PQC). These two signing calls are executed serially, and each returns a signature value independently.

[0082] S204, The client's middleware will obtain the SM2 signature value. and ML-DSA signature value Assemble into a SignedData data packet in PKCS#7 format, using Detach mode (i.e., without containing the original data). After encapsulation, the data packet is sent to the online banking backend for login verification over the network. Upon receiving the data packet, the server calls the hybrid signature verification interface to verify the validity of the two signature values ​​respectively.

[0083] Example 3: Atomic Double Signature Implementation Logic for Online Banking Transactions. This example demonstrates the atomic double signature logic for the transfer process, namely the dual signature process under the transaction signature instruction scenario, ensuring the non-repudiation of the transaction. Specifically, it includes the following steps: S301. When the user confirms the transfer information on the online banking page, the front-end JavaScript assembles the transaction message and obtains the transaction data. The front-end calls the transaction double-signature interface PQECCDigestSignData, which is provided by the client's middleware.

[0084] S302, The interface input parameters include: the handle of the first type of container. (i.e., hContainer), the handle of the second type of container (i.e., hPQContainer), transaction data The Base64 encoded form b64SrcData (which can be the original transaction text or a digest), and the digest algorithm parameter ulPQHashAlg that specifies the PQC signature, for example, set to SHA-512.

[0085] S303. The client's middleware transmits the above parameters and calls the underlying driver interface SKFE_PQECCDigestSignData to send the transaction signature instruction to the secure password calculation module of the smart password key device.

[0086] The S304 smart password key device displays key information such as the transaction amount on its screen, awaiting user confirmation via physical buttons. At this point, the PIN code verification status can be reused, or the user can be required to re-enter the PIN code for confirmation.

[0087] S305. After user confirmation, the secure password calculation module performs an atomic double-signature operation within the same secure execution flow. First, the transaction data is calculated. Abstract ,like If it's a digest, use it directly. Then, utilize the SM2 private key from the first type of container. Abstract Perform SM2 signing and generate SM2 signature value. Simultaneously, the ML-DSA private key in the second type of container is used. For the same abstract Perform ML-DSA signing and generate ML-DSA signature value. These two signature operations are performed consecutively within the secure chip, and the private key is not exposed to the outside.

[0088] S306, the secure cryptographic operation module will generate and The two signature values ​​are combined into a single byte array and returned to the client's middleware in one go. Upon receiving this array, the client's middleware encapsulates the two signature values ​​into a PKCS#7 formatted data packet, using Attach mode (i.e., including the original transaction text). Then, the signature is sent to the online banking server for verification.

[0089] Example 4: Mobile terminal (mobile banking) transaction signature, specifically including the following steps: S401. The mobile banking app calls the connectDev interface to establish a communication connection with the smart password key device via Bluetooth. This device has the same built-in security password calculation module and container management module as in Example 3.

[0090] S402. The APP calls the signature interface sign_pqc provided by the mobile SDK, which encapsulates the functionality of the client's middleware.

[0091] S403. When calling the interface, explicitly pass two sets of algorithm parameters. For example, the signature algorithm identifier `signAlg` for the first type of container can be set to `SM2`, and the signature algorithm identifier `signAlg_pqc` for the second type of container can be set to `ML_DSA`, along with the corresponding hash algorithms `hashAlg` and `hashAlg_pqc`. In addition, the transaction data to be signed must also be passed. And handles to the two containers (which can be automatically obtained by the SDK based on the user certificate or passed in from the upper layer).

[0092] S404. After receiving the transaction signature instruction, the Bluetooth smart key device internally executes the same atomic double-signature logic as in Example 3: verifying the user's PIN code (possibly entered via a mobile phone or the device itself), and processing the transaction data. Calculate the digest, and sign it using the SM2 private key in the first type of container and the ML-DSA private key in the second type of container respectively, to generate the SM2 signature value. and ML-DSA signature value The SDK then returns both signature values ​​to the mobile SDK at once. The SDK encapsulates the result and returns it to the app, completing the transaction signing.

[0093] This invention configures logically independent first and second type containers through a container management module. These containers store key pairs and corresponding public key certificates based on the SM2 algorithm and key pairs and corresponding public key certificates based on the ML-DSA algorithm, respectively. A consistent subject DN field is used to establish a logical association between the two containers in memory. This achieves a smooth introduction of the quantum-resistant ML-DSA algorithm while maintaining compatibility with the existing national cryptographic standard GM / T 0016. This architecture completely solves the problem of rigid storage space in traditional smart cryptographic keys, enabling devices to simultaneously accommodate two types of certificates with vastly different sizes, eliminating the engineering barriers of complex mixed certificate management and incompatibility with older devices. Furthermore, this invention performs atomic double-signature operations in a single transaction signature instruction through a secure cryptographic operation module. It signs the digest of the same transaction data using both the SM2 private key and the ML-DSA private key, outputting the double-signature result in one go. This avoids the risks of duplicate PIN code verification and signature timing caused by serial calls at the application layer, ensuring the integrity and consistency of highly sensitive transaction data and significantly improving the user experience. For common signature scenarios such as login, the client's middleware sequentially calls two sets of signature interfaces and encapsulates them into a PKCS#7 format dual-signature data packet, simplifying the interaction process while ensuring dual authentication. The entire solution, through the organic combination of independent container storage, logical association management, and a dual-path processing mechanism, provides the banking industry with a secure, efficient, and highly compatible quantum-resistant cryptographic migration solution.

[0094] like Figure 7 As shown, an embodiment of the present invention provides a signature method based on a smart cryptographic key device supporting the ML-DSA algorithm. The smart cryptographic key device supporting the ML-DSA algorithm includes a container management module, client middleware, and a secure cryptographic operation module. The method includes: S1. Configure logically independent first-class containers and second-class containers through the container management module; wherein, the first-class container stores key pairs and corresponding public key certificates based on the national cryptographic SM2 algorithm, and the second-class container stores key pairs and corresponding public key certificates based on the ML-DSA algorithm, and the certificates stored in the first-class container and the certificates stored in the second-class container have the same subject DN field. S2. Through the client's middleware, establish a one-to-one logical association between the first type of container and the second type of container based on the consistent topic DN field; S3. Through the secure cryptographic operation module, in response to the single transaction signature instruction initiated by the client and forwarded by the client's middleware, the same transaction data is signed by calling the SM2 private key in the first type container and the ML-DSA private key in the second type container in the same secure execution process, and the double signature result consisting of the SM2 signature value and the ML-DSA signature value is output to the client's middleware at once.

[0095] Optionally, in the above technical solution, a one-to-one logical association between the first type of container and the second type of container is established through middleware on the client side, specifically including: During the initialization phase, the middleware on the client traverses all containers in the container management module, extracts the subject DN field of the certificate stored in the first type of container, and compares it with the subject DN field of the certificate stored in the second type of container. When the comparison results match, a one-to-one correspondence is established between the handles of the first type of container and the handles of the second type of container in memory to obtain the logical association between the first type of container and the second type of container.

[0096] Optionally, in the above technical solution, the method further includes a standard signature step: The client-side middleware responds to a regular signature request initiated by the client and verifies the PIN code entered by the user. After successful verification, the signature interface corresponding to the SM2 private key in the first type of container and the signature interface corresponding to the ML-DSA private key in the second type of container are called in turn to obtain the SM2 signature value and the ML-DSA signature value respectively. The SM2 signature value and ML-DSA signature value are encapsulated into a double-signed data packet in PKCS#7 format and then returned to the client.

[0097] Optionally, in the above technical solution, the secure cryptographic operation module responds to the client's middleware-forwarded single transaction signature instruction, and within the same secure execution process, signs the same transaction data by calling the SM2 private key in the first type of container and the ML-DSA private key in the second type of container respectively, and outputs the double signature result at once, specifically including: After receiving the transaction signature instruction initiated by the client from the client's middleware via the secure password operation module, the module verifies the PIN code entered by the user. The transaction signature instruction carries the handles of the first type of container, the second type of container, and the transaction data. After successful verification, in the same secure execution process, the digest of the transaction data is signed by calling the SM2 private key in the first type of container and the ML-DSA private key in the second type of container respectively, generating SM2 signature value and ML-DSA signature value. The SM2 signature value and ML-DSA signature value are output to the client's middleware as a double signature result at once.

[0098] It should be noted that the beneficial effects of the signature method for a smart cryptographic key device based on the ML-DSA algorithm provided in the above embodiments are the same as those of the smart cryptographic key system supporting the ML-DSA algorithm described above, and will not be repeated here. Furthermore, the method and system embodiments provided in the above embodiments belong to the same concept, and their specific implementation processes are detailed in the method embodiments, and will not be repeated here.

[0099] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned signature methods for a smart cryptographic key device supporting the ML-DSA algorithm.

[0100] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned signature methods for a smart cryptographic key device supporting the ML-DSA algorithm.

[0101] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0102] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. An intelligent cryptographic key system supporting ML-DSA algorithm, characterized in that, include: The container management module is configured to include a logically independent first type of container and a second type of container; the first type of container is used to store key pairs based on the Chinese national cryptographic SM2 algorithm and the corresponding public key certificates; the second type of container is used to store key pairs based on the ML-DSA algorithm and the corresponding public key certificates; wherein, the certificates stored in the first type of container and the certificates stored in the second type of container have the same subject DN field; The client's middleware communicates with the container management module and is used to establish a one-to-one logical association between the first type of container and the second type of container based on the consistent topic DN field. The secure cryptographic operation module, connected to the container management module and the client's middleware, is used to respond to a single transaction signature instruction initiated by the client and forwarded by the client's middleware. In the same secure execution process, it calls the SM2 private key in the first type of container and the ML-DSA private key in the second type of container to sign the same transaction data, and outputs a double signature result consisting of the SM2 signature value and the ML-DSA signature value to the client's middleware at once.

2. The intelligent key system supporting ML-DSA algorithm according to claim 1, wherein, The middleware of the client is specifically used to: traverse all containers in the container management module during the initialization phase, extract the subject DN field of the certificate stored in the first type of container and compare it with the subject DN field of the certificate stored in the second type of container. When the comparison results are consistent, establish a one-to-one correspondence between the handles of the first type of container and the handles of the second type of container in memory to obtain the logical association between the first type of container and the second type of container.

3. The intelligent key system supporting ML-DSA algorithm according to claim 1, wherein, The middleware of the client is also used to: respond to a normal signature request initiated by the client, verify the PIN code entered by the user, and after successful verification, call the signature interface corresponding to the SM2 private key in the first type of container and the signature interface corresponding to the ML-DSA private key in the second type of container in turn to obtain the SM2 signature value and the ML-DSA signature value respectively, and encapsulate the SM2 signature value and the ML-DSA signature value into a double-signed data packet in PKCS#7 format and return it to the client.

4. The intelligent key system supporting ML-DSA algorithm according to claim 2, wherein, The secure cryptographic operation module is specifically used for: receiving a transaction signing instruction initiated by the client and forwarded by the client's middleware through the client's middleware; verifying the PIN code entered by the user; wherein the transaction signing instruction carries the handle of the first type of container, the handle of the second type of container, and transaction data; after successful verification, signing the digest of the transaction data by calling the SM2 private key in the first type of container and the ML-DSA private key in the second type of container respectively in the same secure execution flow, generating an SM2 signature value and an ML-DSA signature value, and outputting the SM2 signature value and the ML-DSA signature value as a double signature result to the client's middleware at once.

5. A signature method for a smart cryptographic key device supporting the ML-DSA algorithm, characterized in that, A smart cryptographic key device supporting the ML-DSA algorithm is used. The smart cryptographic key device includes a container management module, client middleware, and a secure cryptographic operation module. The method includes: The container management module configures logically independent first-type containers and second-type containers. The first-type containers store key pairs and corresponding public key certificates based on the SM2 algorithm, while the second-type containers store key pairs and corresponding public key certificates based on the ML-DSA algorithm. The certificates stored in the first-type containers and the certificates stored in the second-type containers have the same subject DN field. Through the middleware of the client, a one-to-one logical association between the first type of container and the second type of container is established based on the consistent topic DN field; The secure cryptographic operation module responds to the single transaction signature instruction initiated by the client and forwarded by the client's middleware. In the same secure execution process, it calls the SM2 private key in the first type of container and the ML-DSA private key in the second type of container to sign the same transaction data, and outputs the double signature result consisting of the SM2 signature value and the ML-DSA signature value to the client's middleware at once.

6. The signature method for a smart cryptographic key device supporting the ML-DSA algorithm according to claim 5, characterized in that, The middleware on the client establishes a one-to-one logical association between the first type of container and the second type of container, specifically including: During the initialization phase, the middleware of the client traverses all containers in the container management module, extracts the subject DN field of the certificate stored in the first type of container, and compares it with the subject DN field of the certificate stored in the second type of container; When the comparison results match, a one-to-one correspondence is established in memory between the handles of the first type of container and the handles of the second type of container to obtain the logical association between the first type of container and the second type of container.

7. The signature method for a smart cryptographic key device supporting the ML-DSA algorithm according to claim 5, characterized in that, The method also includes a standard signature step: The middleware of the client responds to the ordinary signature request initiated by the client and verifies the PIN code entered by the user. After successful verification, the signature interface corresponding to the SM2 private key in the first type of container and the signature interface corresponding to the ML-DSA private key in the second type of container are called in turn to obtain the SM2 signature value and the ML-DSA signature value respectively. The SM2 signature value and the ML-DSA signature value are encapsulated into a double-signed data packet in PKCS#7 format and then returned to the client.

8. The signature method for a smart cryptographic key device supporting the ML-DSA algorithm according to claim 6, characterized in that, The secure cryptographic operation module responds to the client's middleware-forwarded single transaction signature instruction. Within the same secure execution flow, it uses both the SM2 private key in the first type of container and the ML-DSA private key in the second type of container to sign the same transaction data, and outputs the double-signature result in one go. Specifically, this includes: After receiving the transaction signature instruction initiated by the client and forwarded by the client's middleware through the secure password operation module, the module verifies the PIN code entered by the user. The transaction signature instruction carries the handle of the first type of container, the handle of the second type of container, and the transaction data. After successful verification, in the same secure execution process, the digest of the transaction data is signed by calling the SM2 private key in the first type of container and the ML-DSA private key in the second type of container respectively, generating SM2 signature value and ML-DSA signature value; The SM2 signature value and the ML-DSA signature value are output as a double signature result to the middleware of the client at once.

9. An electronic device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements a signature method for a smart cryptographic key device based on an ML-DSA algorithm as described in any one of claims 5 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the signature method of the smart cryptographic key device based on the ML-DSA algorithm as described in any one of claims 5 to 8.

Images