Quantum key storage and use method based on mobile terminal

Abstract

The invention provides a quantum key storage and use method based on a mobile terminal, after a security medium is accessed to a charging terminal, the security medium generates a medium private key and a medium public key, the charging terminal generates a charging request and sends the charging request to a secret service platform, and the secret service platform generates to-be-charged data and sends the to-be-charged data to the charging terminal. The security medium stores a first key ciphertext and a charging key ciphertext, after the security medium accesses the use terminal, the security medium transencrypts the first key ciphertext based on the complete public key to obtain a second key ciphertext, stores the second key ciphertext and the charging key ciphertext in a local database, and after the security medium is moved out, stores the charging key ciphertext in the local database; and the using terminal obtains the first private key, the second key ciphertext and the charging key ciphertext, negotiates with the collaborative server to decrypt the charging key ciphertext to obtain the charging key, and performs session encryption based on the session key and the charging key. According to the application, through key charging, key transmission and key use processes, the user experience is improved while the intrusion risk is prevented.

Description

Technical Field

[0001] This application relates to the field of quantum encryption technology, and more specifically, to a method for storing and using quantum keys on a mobile device. Background Technology

[0002] With the increasing frequency of internet communication, data security has become a core pillar of information security systems. Encryption technology is used to ensure the confidentiality and integrity of sensitive user data during transmission, and the effectiveness of encryption technology depends entirely on the secure management of keys. If a key is leaked at any stage of generation, storage, distribution, or use, the entire encryption mechanism will fail, leading to a serious risk of data leakage. Therefore, secure key management is crucial for building a trusted communication system.

[0003] To enhance the security of key storage and computation, traditional solutions employ two isolation technologies. The first is hardware-level isolation, which involves deploying physical devices such as Hardware Security Modules (HSMs), smart cards, and USB Security Tokens (U-shields). By storing the key in an independent hardware security zone and performing encryption computations within the hardware environment, physical isolation between the key and software is achieved, effectively resisting security threats such as software theft and tampering. The second approach utilizes software or system-level security zones for key storage.

[0004] However, in the first approach, traditional hardware media is designed specifically for personal computers (PCs), while smartphones, tablets, and other mobile devices generally lack standard hardware interfaces. Even with OTG technology as a means of switching, issues such as inconvenience in carrying, easy loss, and poor compatibility exist, severely reducing the user experience and failing to meet the convenience and universality requirements of mobile applications. In the second approach, software-stored keys are vulnerable to reverse engineering and malicious application attacks. Relying on system-level security zones is insufficient to defend against system vulnerabilities or advanced persistent threats, failing to achieve the security level of traditional hardware devices. Summary of the Invention

[0005] The purpose of this application is to address the shortcomings of the prior art by providing a mobile-based quantum key storage and usage method, thereby solving the problems of poor user experience and low security protection in the prior art.

[0006] To achieve the above objectives, the technical solution adopted in this application is as follows: In a first aspect, this application provides a method for storing and using quantum keys on a mobile terminal. The method is applied to a key system, which includes: a secure medium, a filling terminal, a usage terminal, a cryptographic service platform, and a collaborative server. After the secure medium is connected to the refilling terminal, the secure medium generates a private key and a public key. The refilling terminal generates a refilling request and sends it to the security service platform. The refilling request includes: the secure medium's serial number, the media's public key, and a preset amount of refilling key. The secure service platform generates data to be recharged based on the recharge request. The data to be recharged includes a digital envelope, recharge key ciphertext, first key ciphertext, recharge key ciphertext hash value, and recharge key hash value. The secure medium stores the first key ciphertext and recharge key ciphertext in the data to be recharged. After the secure medium is connected to the user terminal, the secure medium re-encrypts the first key ciphertext in the secure medium based on the complete public key negotiated by the user terminal to obtain the second key ciphertext, and stores the second key ciphertext and the filling key ciphertext in the local database of the user terminal. After the secure medium is removed from the user terminal, the user terminal obtains the first private key, the second key ciphertext, and the recharge key ciphertext from the local database, and negotiates with the collaborative server to decrypt the recharge key ciphertext to obtain the recharge key. The user terminal then performs session encryption based on the session key obtained from the secure service platform and the recharge key.

[0007] Optionally, the secure medium generates a private key and a public key for the medium, including: The secure medium and the secure service platform respectively verify the user's identity. After successful verification, a key storage application and a key storage container are created in the secure medium, and an application access password is set. A key storage file is created, which is the file in the key storage container used to store the charging key. The secure medium generates a private key and a public key.

[0008] Optionally, the security service platform generates data to be filled based on the filling request, including: The secure service platform generates a charging key based on the charging request, and calls the hardware security module to generate the platform public key and the platform private key; The platform private key and the platform public key are encrypted using the media public key to obtain a digital envelope; Generate a filling encryption key, and encrypt the filling key based on the filling encryption key to obtain the filling key ciphertext; The charging encryption key is encrypted using the platform's public key to obtain the first key ciphertext; Calculate the hash value of the ciphertext of the injection key to obtain the hash value of the ciphertext of the injection key, and calculate the hash value of the injection key to obtain the hash value of the injection key.

[0009] Optionally, the secure medium stores the first key ciphertext and the filling key ciphertext in the data to be filled, including: The secret service platform sends the data to be filled to the filling terminal; The filling terminal calculates the hash value of the filling key ciphertext to obtain the first hash value to be verified; The filling terminal calculates the hash value of the filling key to obtain a second hash value to be verified; If the first hash value to be verified is the same as the hash value of the ciphertext of the filling key, and the second hash value to be verified is the same as the hash value of the filling key, then the data to be filled is sent to the secure medium. The secure medium verifies the data to be filled, and stores the first key ciphertext and the filling key ciphertext after successful verification.

[0010] Optionally, the security medium verifies the data to be filled, including: The secure medium decrypts the digital envelope using its private key to obtain the platform public key and the platform private key; The first key ciphertext is decrypted based on the platform's private key to obtain the key ciphertext to be verified. If the ciphertext of the charging key to be verified is the same as the ciphertext of the charging key, then the verification is successful.

[0011] Optionally, the secure medium uses the complete public key obtained through terminal negotiation to encrypt the first key ciphertext in the secure medium to obtain the second key ciphertext, which includes: The user terminal negotiates with the collaborative server to determine the first private key, the second private key, and the complete public key, and stores the first private key and the complete public key in the user terminal's local database. After the secure medium is connected to the user terminal, the user terminal sends the complete public key to the secure medium; the secure medium then uses the complete public key to encrypt the first key ciphertext in the secure medium to obtain the second key ciphertext.

[0012] Optionally, the secure medium uses the complete public key to encrypt the first key ciphertext in the secure medium to obtain a second key ciphertext, including: The secure medium uses the platform's private key to decrypt the first key ciphertext to obtain the first key, and then uses the complete public key to encrypt the first key to obtain the second key ciphertext.

[0013] Optionally, before accessing the terminal using the secure medium, the method further includes: The user terminal sends a creation request to the collaborative server. The creation request includes: user terminal identifier, current application identifier, and number of requests. Obtain the request response sent by the collaborative server, the request response including: soft module identifier; A local database is created based on the terminal identifier and the software module identifier; The user terminal negotiates and determines the first private key, the second private key, and the complete public key with the collaborative server.

[0014] Optionally, the user terminal negotiates and determines the first private key, the second private key, and the complete public key with the collaborative server, including: The user terminal randomly generates a first private key and generates a first public key based on the first private key. The first public key is then sent to the collaborative server, so that the collaborative server generates a second private key and a complete public key based on the first public key, and sends the complete public key to the user terminal.

[0015] Optionally, the user terminal negotiates with the collaborative server to decrypt the ciphertext of the injection key to obtain the injection key, including: The user terminal generates a first intermediate value based on the second key ciphertext and the first private key, and sends the first intermediate value to the collaborative server, so that the collaborative server generates a second intermediate value based on the second private key and the first intermediate value, and sends the second intermediate value to the user terminal. The terminal uses the first private key to decrypt the second intermediate value to obtain the filling encryption key; The terminal uses the charging encryption key to decrypt the charging key ciphertext to obtain the charging key.

[0016] Secondly, this application provides a key system, which includes: a secure medium, a filling terminal, a user terminal, a cryptographic service platform, and a collaborative server. The key system is used to perform the steps of the mobile terminal-based quantum key storage and usage method described in the first aspect.

[0017] The beneficial effects of this application are as follows: During the key filling stage, after the secure medium is connected to the filling terminal, the secure medium generates a medium private key and a medium public key. The filling terminal generates a filling request and sends it to the cryptographic service platform. The cryptographic service platform generates data to be filled based on the filling request. The data to be filled includes a digital envelope, a filling key ciphertext, a first key ciphertext, a filling key ciphertext hash value, and a filling key hash value. The secure medium stores the first key ciphertext and the filling key ciphertext in the data to be filled, thereby directly storing the key in the secure area of ​​the secure medium through physical isolation, eliminating the risk of unauthorized reading, copying, and tampering. During the key transmission stage, the secure medium re-encrypts the first key ciphertext in the secure medium based on the complete public key negotiated by the user terminal to obtain a second key ciphertext. The second key ciphertext and the filling key ciphertext are stored in the local database of the user terminal. The re-encryption process is completed within the hardware of the secure medium. The user terminal only stores the ciphertext and does not access the plaintext, and the public key does not leave the security boundary, thereby avoiding risks such as public key replacement and algorithm attacks, and reducing the attack surface. During the key usage phase, the terminal retrieves the first private key, the second key ciphertext, and the charging key ciphertext from the local database, and negotiates with the collaborative server to decrypt the charging key ciphertext to obtain the charging key. Session encryption is performed based on the session key obtained from the security service platform and the charging key. The terminal and the collaborative server then negotiate to decrypt the charging key ciphertext, preventing a single entity from holding decryption rights. Furthermore, the concatenated encryption of the charging key and session key further satisfies security requirements. This embodiment overcomes the limitations of mobile adaptation of security media, eliminating the need for continuous connection between the security media and the terminal; only a brief connection is required during the key transmission phase. This solves the problems of inconvenience, poor compatibility, and poor user experience associated with external hardware on mobile devices. Moreover, compared to solutions relying on pure software storage or system-level security zones, this embodiment avoids exposing the key plaintext at the software level, thus resisting advanced persistent threats from reverse engineering, malicious application attacks, and system vulnerabilities, achieving a higher level of security protection. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram illustrating a scenario of a mobile terminal-based quantum key storage and usage method provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating a scenario of a mobile terminal-based quantum key storage and usage method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating a method for storing and using quantum keys on a mobile device, as provided in an embodiment of this application. Figure 4 This is a schematic diagram of a process for generating a medium private key and a medium public key, provided in an embodiment of this application; Figure 5 This is a schematic diagram of a process for generating data to be filled, provided in an embodiment of this application; Figure 6 This is a schematic diagram of a process for storing the first key ciphertext and the filling key ciphertext in the data to be filled, provided in an embodiment of this application; Figure 7 This is a schematic diagram of a process for verifying data to be filled, provided in an embodiment of this application; Figure 8 This is a schematic diagram of a process for determining a first private key, a second private key, and a complete public key, provided in an embodiment of this application; Figure 9 This is a schematic diagram of a process for obtaining a filling key provided in an embodiment of this application; Figure 10 This is a flowchart illustrating a key filling process provided in an embodiment of this application; Figure 11 This is a flowchart illustrating a key transfer process provided in an embodiment of this application; Figure 12 This is a flowchart illustrating a key usage process provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0021] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0023] In existing technologies, hardware isolation may have problems such as inconvenience in carrying, easy loss, and poor compatibility, which seriously reduce the user experience and cannot meet the convenience and universality requirements of mobile applications. Software isolation is vulnerable to reverse engineering and malicious application attacks, and relying on system-level security zones is difficult to defend against system vulnerabilities or advanced persistent threats, and cannot achieve the security level of traditional hardware devices.

[0024] Based on this, this application proposes a mobile terminal-based quantum key storage and usage method. This method first uses a charging terminal to charge the key into a secure medium. Then, after the secure medium is connected to the user terminal, the user terminal's private key is used to encrypt the charged key in the secure medium before storing it in a pre-built local database. During use, even if the secure key is removed from the user terminal, the user terminal can still encrypt the session content based on the charged key stored in the local database. This application stores the charged key in the user terminal's local database, eliminating the need for the secure medium to maintain an access state, thus improving user experience. Furthermore, remote transmission is avoided during the key charging stage, thereby preventing external attacks and ensuring charging security. Moreover, during key transmission and usage, the user terminal always retains the ciphertext of the charged key and does not directly access the plaintext, further reducing the potential attack surface.

[0025] Next, refer to Figure 1 This paper introduces application scenarios for mobile quantum key storage and usage methods. Among them, Figure 1 This is a schematic diagram of a scenario for a mobile terminal-based quantum key storage and usage method provided in an embodiment of this application.

[0026] like Figure 1As shown, the mobile-based quantum key storage and usage method in this application has three stages: key filling stage, key transmission stage, and key usage stage. In the key filling stage, the filling user connects a secure medium to a filling terminal, where the secure medium can be a USB key (U-shield) and the filling terminal can be a computer, etc. After the key is filled using the filling terminal, the filling user removes the secure medium. After receiving the filled secure medium, the user connects it to a user terminal, which can be a computer or a mobile terminal. The user terminal encrypts the filled key in the secure medium and stores it in a local database. The user can then remove the secure medium from the user terminal. When the user terminal performs session encryption, it only needs to retrieve the filled key from the local database to achieve session encryption.

[0027] Optionally, the mobile-based quantum key storage and usage method can be applied to key systems, such as... Figure 2 As shown, the key system includes secure media, a key-adding terminal, a user terminal, a key-service platform, and a collaborative server. The key-service platform integrates a Key Management System (KMS), which is responsible for key generation, encrypted storage, secure distribution, and destruction, as well as providing access control for keys. Additionally, the KMS can invoke a Hardware Security Module (HSM), which performs encrypted calculations on the key-adding mechanism to achieve hardware isolation. The collaborative server is a dedicated cloud service paired with the user terminal. The user terminal acts as a client, collaborating with the collaborative server to perform key encryption and decryption.

[0028] Next, refer to Figure 3 This paper introduces the specific implementation of mobile-based quantum key storage and usage methods. Figure 3 This is a flowchart illustrating a method for storing and using quantum keys on a mobile device, as provided in an embodiment of this application.

[0029] S301. After the secure medium is connected to the refill terminal, the secure medium generates a medium private key and a medium public key. The refill terminal generates a refill request and sends it to the security service platform. The refill request includes: the secure medium's medium serial number, the medium public key, and the preset refill key quantity.

[0030] As an optional implementation, after the secure medium is connected to the refilling terminal, the refilling terminal can prompt the refilling user to enter the personal identification number (PIN) password of the secure medium, and at the same time send the refilling user's identity information to the security service platform for login authentication.

[0031] After successful authentication, the charging terminal generates a media private key and a media public key. These are asymmetric key pairs generated by the secure media, specifically a public-private key pair based on the SM2 Elliptic Curve Public Key Cryptographic Algorithm (SM2). The media private key is stored in the secure area of ​​the secure media's hardware, while the media public key is used to prove the identity of the secure media to the security service platform. It is worth noting that the secure media randomly generates the public-private key pair in a hardware-isolated environment to avoid the risk of software-level theft.

[0032] In the refill request, the Serial Number (SN) is a unique identifier for the secure medium, used by the cryptographic service platform to distinguish different secure media and ensure the relevance of key refills. The refill key quantity is the number of quantum keys to be refilled into the secure medium, which is preset by the user and retrieved from the key pool by the cryptographic service platform based on this data.

[0033] S302. The security service platform generates data to be recharged based on the recharge request. The data to be recharged includes a digital envelope, recharge key ciphertext, first key ciphertext, recharge key ciphertext hash value, and recharge key hash value. The first key ciphertext and recharge key ciphertext in the data to be recharged are stored on a secure medium.

[0034] This step is the key filling process. After the security service platform receives the filling request, it verifies the operator's permissions through the access token, checks the legality of the security medium SN, and confirms that the amount of key to be filled is within the available limit. After the verification is successful, the process of generating the data to be filled is started.

[0035] Specifically, the KMS in the security service platform calls HSM to generate an SM2 encryption key pair, including the platform public key and the platform private key. Then, based on the media public key, the platform public key, and the platform private key, a digital envelope is generated. Then, based on the amount of recharged keys, the recharge key is extracted from the key pool, and the recharge key is encrypted based on the generated recharge encryption key to obtain the recharge key ciphertext. The recharge encryption key is then encrypted based on the platform public key to obtain the first key ciphertext. Then, the hash value of the recharge key and the hash value of the recharge key ciphertext are calculated respectively to obtain the recharge key hash value and the recharge key ciphertext hash value.

[0036] The digital envelope is used for secure transmission of platform key pairs. The filling key hash value and the filling key ciphertext hash value are used to verify data integrity and prevent tampering.

[0037] Optionally, after obtaining the data to be injected, the security service platform sends the data to the injection terminal. The injection terminal can verify the data to be injected based on the injection key hash value and the injection key ciphertext hash value. After successful verification, the data to be injected is sent to the secure medium so that the secure medium can store the data after successful verification.

[0038] S303. After the secure medium is connected to the user terminal, the secure medium re-encrypts the first key ciphertext in the secure medium based on the complete public key negotiated by the user terminal to obtain the second key ciphertext, and stores the second key ciphertext and the filling key ciphertext in the local database of the user terminal.

[0039] This step is the key transfer process. Before the secure medium is connected to the terminal, terminal initialization and the creation of a local database can also be performed. The local database can be, for example, an encrypted SQLite database.

[0040] Before the secure medium is connected to the user terminal, the terminal uses its Software Development Kit (SDK) to invoke the key generation function of the collaborative software module to negotiate with the collaborative server and obtain a first private key and a complete public key. These two keys are then stored in a local database. After the secure medium is connected to the user terminal, the user terminal can send the complete public key to the secure medium. The secure medium then uses the complete public key to encrypt the first key ciphertext, obtaining the second key ciphertext. Additionally, the first private key, which is a portion of the user terminal's private key, is one of the distributed components of the complete private key. It can be combined with a portion of the collaborative server's private key to form the complete private key, used for collaborative decryption in subsequent steps. The decryption process will be explained in detail later and will not be repeated here.

[0041] Specifically, the first key ciphertext is obtained by encrypting the injection encryption key using the platform's public key. The secure medium resides in the hardware secure zone. The first key ciphertext is decrypted using the platform's private key to obtain the injection encryption key. Then, the injection encryption key is encrypted using the complete public key to obtain the second key ciphertext. In this encryption process, the user terminal does not access the plaintext of the injection encryption key or the decryption process of the first key ciphertext, thus reducing the attack surface.

[0042] S304. After the secure medium is removed from the user terminal, the user terminal obtains the first private key, the second key ciphertext, and the charging key ciphertext from the local database, and negotiates with the collaborative server to decrypt the charging key ciphertext to obtain the charging key. The user terminal then performs session encryption based on the session key obtained from the secure service platform and the charging key.

[0043] This step is the key usage process. At this time, the user terminal's local database already stores the second key ciphertext, the filling key ciphertext, and the first private key. After the secure medium is removed from the user terminal, when session encryption is required, the user terminal retrieves the first private key and the second key ciphertext from the local database, and negotiates with the collaborative server to decrypt and obtain the filling encryption key based on the first key and the second key ciphertext. Then, it retrieves the filling key ciphertext from the local database and uses the filling encryption key to decrypt the filling key ciphertext to obtain the filling key.

[0044] The session key is a key generated by the security service platform for a single call session of the user terminal. It is sent to the user terminal in encrypted form and needs to be decrypted with the charging key before the data transmitted between the user terminal and the communication object can be encrypted to ensure the data security of a single session.

[0045] In this embodiment, during the key filling stage, after the secure medium is connected to the filling terminal, the secure medium generates a private key and a public key. The filling terminal generates a filling request and sends it to the secure service platform. The secure service platform generates data to be filled based on the filling request. The data to be filled includes a digital envelope, a ciphertext of the filling key, a ciphertext of the first key, a hash value of the ciphertext of the filling key, and a hash value of the filling key. The secure medium stores the ciphertext of the first key and the ciphertext of the filling key in the data to be filled, thereby directly storing the key in the secure area of ​​the secure medium through physical isolation, eliminating the risk of unauthorized reading, copying, and tampering. During the key transmission stage, the secure medium re-encrypts the ciphertext of the first key in the secure medium based on the complete public key negotiated by the user terminal to obtain a ciphertext of the second key. The ciphertext of the second key and the ciphertext of the filling key are stored in the local database of the user terminal. The re-encryption process is completed within the hardware of the secure medium. The user terminal only stores the ciphertext and does not access the plaintext, and the public key does not leave the security boundary, thereby avoiding risks such as public key replacement and algorithm attacks, and reducing the attack surface. During the key usage phase, the terminal retrieves the first private key, the second key ciphertext, and the charging key ciphertext from the local database, and negotiates with the collaborative server to decrypt the charging key ciphertext to obtain the charging key. Session encryption is performed based on the session key obtained from the security service platform and the charging key. The terminal and the collaborative server then negotiate to decrypt the charging key ciphertext, preventing a single entity from holding decryption rights. Furthermore, the concatenated encryption of the charging key and session key further satisfies security requirements. This embodiment overcomes the limitations of mobile adaptation of security media, eliminating the need for continuous connection between the security media and the terminal; only a brief connection is required during the key transmission phase. This solves the problems of inconvenience, poor compatibility, and poor user experience associated with external hardware on mobile devices. Moreover, compared to solutions relying on pure software storage or system-level security zones, this embodiment avoids exposing the key plaintext at the software level, thus resisting advanced persistent threats from reverse engineering, malicious application attacks, and system vulnerabilities, achieving a higher level of security protection.

[0046] Next, refer to Figure 4 The specific process of generating the media private key and media public key in step S301 above is described. Specifically, Figure 4 This is a schematic diagram of a process for generating a medium private key and a medium public key, provided in an embodiment of this application. S401, the security medium, and the security service platform respectively verify and fill in the user's identity.

[0047] Specifically, after the user physically connects the secure medium to the recharge terminal, the recharge terminal sends an authentication request to the secure medium through a hardware interface. The secure medium activates the hardware-level PIN verification module and displays a PIN input interface to the user through the recharge terminal. The PIN is stored in the secure medium's hardware secure area as a hashed encrypted message, not in plaintext. The user enters the preset secure medium PIN. The secure medium internally calls a hash verification algorithm to compare the entered PIN with the PIN hash value stored in the hardware secure area. If the comparison matches, the verification is successful, and the secure medium returns a media authorization approval instruction to the recharge terminal and activates the internal recharge function module. If the comparison does not match, the verification fails, and the recharge process terminates.

[0048] After the secure medium verification is successful, the filling terminal automatically initiates a user authentication request to the security service platform, simultaneously carrying the user's account identifier, encrypted password information, and the serial number of the secure medium. Upon receiving the request, the security service platform first verifies data integrity through a transport layer encryption channel to prevent tampering. Then, it extracts the user account and encrypted password information from the request. After decrypting the password information, the platform calculates the password hash value using a hash algorithm and compares it with the user password hash values ​​stored in the platform's database. If the comparison passes, it verifies the user account's permission level to confirm whether the user has the necessary permissions for key filling. If so, the secure medium verification is successful.

[0049] After all verification items pass, the security service platform generates a temporary access token, which is encapsulated in a preset format so that the terminal can perform key encapsulation through the security service platform. The encapsulated temporary access token includes information such as user identifier, permission scope, and validity period, and is returned to the terminal through an encrypted channel. If the verification fails, a specific error code is returned and the process is terminated.

[0050] S402. After successful verification, create a key storage application and a key storage container in the secure medium, set the application access password, and create a key storage file. The key storage file is the file in the key storage container used to store the charging key.

[0051] The key storage application is an independent functional module created within the secure area of ​​the secure medium hardware. It is used to handle key storage, encryption, and retrieval operations and is physically isolated from other functional modules of the secure medium to avoid the risk of cross-leakage.

[0052] The key storage container is a logically isolated space within a key storage application, with independent access control policies to further isolate different types of key data.

[0053] The key storage file is a binary file within the key storage container used to carry data related to the filling key, such as the fillkey.bin file. It only supports internal reading and writing within the secure medium and does not expose its file structure to the outside world.

[0054] S403, Secure Media generates media private key and media public key.

[0055] Specifically, after the secure medium completes the creation of the key storage application, key storage container, and key storage file, the filling terminal sends an instruction to the key storage application to generate a medium key pair. Upon receiving the instruction, the secure medium uses a hardware random number generator to generate a random number seed for the key pair, then generates a medium private key based on the random number seed, and finally generates a medium public key based on the medium private key.

[0056] In this embodiment, before the secure medium generates the medium private key and the medium public key, the secure medium and the cryptographic service platform respectively verify the identity of the user who performs the injection, ensuring the legitimate subject of the injection operation and guaranteeing the security of the injection process.

[0057] Next, refer to Figure 5 The following describes the step in step S302 above, where the security service platform generates the data to be injected based on the injection request. Figure 5 This is a schematic diagram of a process for generating data to be filled, provided in an embodiment of this application.

[0058] S501: The security service platform generates a charging key based on the charging request and calls the hardware security module to generate the platform public key and platform private key.

[0059] As an optional implementation, after receiving a charging request from the charging terminal, the cryptographic service platform first performs an integrity check on the charging request to prevent it from being tampered with. If the check is successful, it extracts the required quantum keys from the key pool of the quantum key distribution network connected to the cryptographic service platform, according to the preset charging key quantity.

[0060] As another alternative implementation, a symmetric key is generated by a hardware random number generator in the hardware security module.

[0061] It is worth noting that after the charging key is generated, it is only temporarily stored in the memory of the security service platform and is not written to the local disk. In addition, a unique identifier is assigned to the charging key, which is bound to the serial number of the security medium, the charging time, and the key validity period, and stored in the key index library of the security service platform for subsequent auditing and traceability.

[0062] Optionally, the security service platform sends a command to the hardware security module to generate a platform key. The hardware security platform generates a random number using a hardware random number generator, which serves as the platform private key. Then, it calculates the platform public key based on the platform private key. The platform private key and platform public key are stored only in the hardware security area of ​​the hardware security module and are not exported to the security service platform's host memory.

[0063] S502. Encrypt the platform private key and the platform public key based on the media public key to obtain a digital envelope.

[0064] The platform private key and the platform public key are encrypted based on the media public key, so that only the secure medium can decrypt the digital envelope with the media private key. Even if the data transmission link to be filled is hijacked, the attacker can only obtain the digital envelope. Without the media private key, the attacker cannot decrypt the platform key pair and thus cannot obtain the filling key, thereby ensuring the security of the digital envelope during transmission.

[0065] S503. Generate a filling encryption key, and encrypt the filling key based on the filling encryption key to obtain the filling key ciphertext.

[0066] Specifically, the hardware security module generates a charging encryption key based on a hardware random number generator. Then, it encrypts the charging key using this key, achieving the first layer of encryption. This step is computationally efficient and suitable for encrypting batches of charging keys.

[0067] S504. Encrypt the charging encryption key based on the platform public key to obtain the first key ciphertext.

[0068] Specifically, the charging encryption key is encrypted based on the platform's public key, so that the charging key is encrypted with a second layer, forming a key chain of the platform's public key, the first key ciphertext, the charging encryption key, and the charging key, thereby achieving the targeted security goal that only a secure medium can decrypt the charging key.

[0069] S505. Calculate the hash value of the ciphertext of the charging key to obtain the hash value of the ciphertext of the charging key, and calculate the hash value of the charging key to obtain the hash value of the charging key.

[0070] Specifically, the hash algorithm of the hardware security module is invoked to perform hash calculations on the ciphertext of the charging key and the charging key, respectively, to obtain the hash value of the ciphertext of the charging key and the hash value of the charging key.

[0071] The ciphertext hash value of the filling key and the filling key hash value are used for double verification, thereby achieving integrity protection throughout the entire process.

[0072] In this embodiment, the charging key is double-encrypted by charging encryption key and platform public key. Only the secure medium can decrypt it with the medium private key, ensuring that the key is not illegally stolen during targeted transmission. In addition, integrity verification is completed by calculating double hash value to prevent data from being tampered with.

[0073] During the process of sending the key to be refilled to the secure medium, the refilling terminal can verify the key. Next, refer to... Figure 6 The specific implementation methods of storing the first key ciphertext and the filling key ciphertext in the data to be filled in the secure medium in step S302 above are described.

[0074] S601, the security service platform sends the data to be filled to the filling terminal.

[0075] Specifically, since the data to be refilled is strongly bound to the temporary access token of the refilling terminal, the security service platform only sends data to the refilling terminal that holds a valid token and whose serial number of the security medium bound in the token matches the refilling request, thus avoiding data being mistakenly sent to unauthorized terminals.

[0076] S602. The filling terminal calculates the hash value of the filling key ciphertext to obtain the first hash value to be verified.

[0077] As an optional implementation, the hash value of the complete filling key ciphertext can be calculated, and the first hash value to be verified is the overall hash value.

[0078] As another optional implementation, ciphertext segments can be extracted according to preset rules, and hash calculations can be performed on each ciphertext segment to obtain a first hash value to be verified, which consists of multiple segments. The preset rules could be, for example, that the first 32 bytes, the middle 32 bytes, and the last 32 bytes of the key-filled ciphertext are each treated as a segment.

[0079] S603. The filling terminal calculates the hash value of the filling key to obtain the second hash value to be verified.

[0080] Specifically, the method for obtaining the second hash value to be verified can be the same as the two implementation methods for obtaining the first hash value to be verified in step S602 above, and will not be repeated here.

[0081] S604. If the first hash value to be verified is the same as the hash value of the ciphertext of the filling key, and the second hash value to be verified is the same as the hash value of the filling key, then the data to be filled is sent to the secure medium.

[0082] Specifically, if the first hash value to be verified is the hash value obtained from the complete ciphertext, it is directly compared with the hash value of the injecting key ciphertext. If the first hash value to be verified is the hash value composed of multiple fragments, the fragment corresponding to the injecting key ciphertext hash value is obtained according to a preset rule, and the two are compared to see if they are the same. Similarly, if the second hash value to be verified is the hash value obtained from the complete plaintext, it is directly compared with the hash value of the injecting key. If the second hash value to be verified is the hash value composed of multiple fragments, the fragment corresponding to the injecting key hash value is obtained according to a preset rule, and the two are compared to see if they are the same.

[0083] If both hash values ​​are identical, it means the data to be injected is complete, and the data to be injected can then be sent to the secure medium.

[0084] As an optional implementation, the filling terminal can send the digital envelope, filling key ciphertext, and first key ciphertext in the data to be filled to the secure medium, thereby reducing the amount of data transmitted and improving data transmission efficiency.

[0085] S605. The security medium verifies the data to be filled and stores the first key ciphertext and the filling key ciphertext after the verification is successful.

[0086] Specifically, the secure medium performs legitimacy and integrity verification on the digital envelope, the ciphertext of the filling key, and the ciphertext of the first key in the data to be filled. If the verification passes, the verified ciphertext of the first key and the ciphertext of the filling key can be stored in the key storage file in its own hardware secure area.

[0087] It is worth noting that the verification process of the secure medium is performed entirely within the hardware security zone, without relying on the software environment of the charging terminal, and can resist attacks from malicious programs on the terminal side.

[0088] As an alternative implementation, the Uniform Resource Locator (URL) of the security service platform and data such as the filling time can also be stored in the configuration file in the security medium.

[0089] In addition, after storing the verified first key ciphertext and the charging key ciphertext in the key storage file of its own hardware security zone, the secure medium can also reread the ciphertext fragment in the key storage file, calculate the hash value and compare it with the hash value before writing to ensure that there are no errors in the storage process; at the same time, it returns a storage success response to the charging terminal, and the charging terminal synchronizes the charging result with the security service platform.

[0090] In this embodiment, the filling terminal verifies the filling data based on the calculated first and second hash values ​​to be verified, thereby eliminating the risks of data tampering and illegal replacement.

[0091] The specific steps for verifying the filling data of the safety medium in step S605 above can be as follows: Figure 7 As shown. Among them, Figure 7 This is a schematic diagram of a process for verifying data to be filled, provided in an embodiment of this application.

[0092] S701. The secure medium decrypts the digital envelope using the medium's private key to obtain the platform's public key and platform private key.

[0093] Specifically, since the digital envelope is encrypted using the public key of the secure medium, the platform public key and platform private key are obtained by parsing the digital envelope based on the private key of the medium.

[0094] S702. Decrypt the first key ciphertext based on the platform private key to obtain the key ciphertext to be verified.

[0095] Specifically, since the first key ciphertext is encrypted using the platform's public key, the first key ciphertext is decrypted using the platform's private key to obtain the charging key ciphertext to be verified.

[0096] S703. If the ciphertext of the charging key to be verified is the same as the ciphertext of the charging key, then the verification is successful.

[0097] If the encrypted key to be verified is the same as the encrypted key, it means that the digital envelope, the platform public key obtained from decryption, the platform private key, and the encrypted key to be verified have not been tampered with, and the entire decryption chain is smooth and the data is complete.

[0098] If the ciphertext of the filling key is tampered with during transmission, or the first key ciphertext or digital envelope is illegally replaced, the ciphertext of the filling key to be verified will be inconsistent with the original ciphertext, thereby quickly identifying security risks and preventing illegal keys from being stored in secure media.

[0099] In this embodiment, the secure medium decrypts the digital envelope using its private key to obtain the platform public key and platform private key. It then decrypts the first key ciphertext using the platform private key to obtain the ciphertext for the charging key to be verified. If the ciphertext for the charging key to be verified matches the charging key ciphertext, the verification is successful. This hierarchical key decryption ensures that only the corresponding secure medium can unlock the complete key chain, preventing unauthorized media from stealing the key. Furthermore, all decryption and verification operations are performed within the hardware security zone of the secure medium, thus resisting malicious attacks from the terminal side and achieving a high level of protection.

[0100] Next, the step of converting and encrypting the first key ciphertext in the security medium based on the complete public key obtained through negotiation using the terminal in step S303 above, to obtain the second key ciphertext, will be described.

[0101] Optionally, the terminal and the collaborative server negotiate to determine a first private key, a second private key, and a complete public key, and store the first private key and the complete public key in the local database of the terminal.

[0102] Specifically, the terminal SDK is initialized using the terminal reference. The SDK sends a key negotiation creation request to the collaborative server, carrying the terminal identifier, the current application identifier, and the number of requests, which are used by the server to identify the negotiation subject.

[0103] The collaborative server verifies the legitimacy of the request. Once the verification is successful, the key generation module is activated to prepare to receive the terminal's first public key.

[0104] The terminal SDK is used to call the key generation function of the collaborative software module to randomly generate the first private key and the first public key based on the SM2 algorithm. The first private key is temporarily stored in the terminal memory.

[0105] The terminal sends part of the public key to the collaborative server through an encrypted channel. During the transmission, the first public key is symmetrically encrypted to prevent link hijacking and leakage.

[0106] After receiving the first public key, the collaborative server decrypts it, generates the second private key based on the SM2 algorithm, and calculates the complete public key through algorithmic operations, ensuring that the complete public key has a mathematical correlation with the first and second private keys.

[0107] The collaborative server returns the complete public key to the user terminal through an encrypted channel, and at the same time stores the second private key in the server database, and binds it with the user terminal identifier and the current application identifier to avoid cross-terminal reuse.

[0108] The terminal SDK is used to store the first private key and the complete public key in the local database. Database access requires verification of a PIN password, which can be composed of device information and a random number from the server, forming a dual protection of storage encryption and access authorization.

[0109] It is worth noting that the complete public key and the first private key are stored in different data partitions of the local database, and the password component and the first private key of the local database are stored in different storage directories, such as memory partitions and local file partitions, to further reduce the risk of leakage.

[0110] Optionally, after the secure medium is connected to the user terminal, the user terminal sends the complete public key to the secure medium; the secure medium then uses the complete public key to re-encrypt the first key ciphertext in the secure medium to obtain the second key ciphertext.

[0111] Specifically, after the secure medium is connected to the user terminal, the user terminal can obtain the complete public key from the local database and send the secure medium to the secure medium. The secure medium can perform an association verification on the complete public key: verifying whether the terminal identifier corresponding to the public key is bound to its own SN, preventing the illegal import of public keys from causing the encrypted product to be tampered with.

[0112] When storing the second key ciphertext, the SDK adds additional fields such as the serial number of the terminal and the timestamp of the encryption to it. These fields are verified during subsequent use to avoid reusing ciphertext across terminals and batches.

[0113] In this embodiment, the first key ciphertext in the secure medium is encrypted using the complete public key in the local database, providing hardware-level isolation protection for key transmission.

[0114] The specific steps by which the secure medium encrypts the first key ciphertext based on the complete public key to obtain the second key ciphertext are as follows: Optionally, the secure medium uses the platform's private key to decrypt the first key ciphertext to obtain the first key, and then uses the complete public key to encrypt the first key to obtain the second key ciphertext.

[0115] Specifically, the terminal SDK is used to unlock the local database via a PIN password, extract the stored complete public key, and verify its format to prevent incomplete public key from causing encryption failure.

[0116] After verification, the complete public key is imported into the secure medium via a hardware encryption channel using the terminal SDK. Symmetric encryption is performed during transmission to prevent the public key from being hijacked and tampered with.

[0117] After receiving the complete public key, the secure medium uses the platform private key obtained by parsing the digital envelope to decrypt the first key ciphertext, thus obtaining the first key, which is the filling encryption key. This decryption process is performed entirely within the hardware security zone and the filling encryption key is not exposed to the terminal.

[0118] The secure medium invokes the SM2 asymmetric encryption algorithm, using the full public key as the encryption key, to encrypt the injected encryption key, generating a second key ciphertext. After encryption, the injected encryption key is immediately cleared from hardware memory to prevent residual leakage.

[0119] The secure medium exports the second key ciphertext to the user terminal through a hardware encryption channel. After receiving it, the SDK stores it together with the original charging key ciphertext in an independent partition of the local database, and access permissions are uniformly controlled by the database password.

[0120] In this embodiment, the secure medium uses the medium public key to decrypt the first key ciphertext to obtain the first key, and then uses the secure medium to encrypt the first key to obtain the second key ciphertext, providing hardware-level isolation protection for key transmission.

[0121] Before step S303 above, that is, before the secure media access terminal, such as Figure 8 As shown, the following steps can also be performed. Among them, Figure 8 This is a schematic diagram of a process for determining a first private key, a second private key, and a complete public key, provided in an embodiment of this application.

[0122] S801. The terminal sends a creation request to the collaborative server. The creation request includes: the terminal identifier, the current application identifier, and the number of requests.

[0123] Upon startup, the terminal SDK is initialized. The SDK automatically reads the device hardware information and generates a terminal identifier using the SM3 hash algorithm, preventing the transmission of hardware information in plaintext. The SDK extracts the current application's built-in current application identifier and encapsulates the creation request in a fixed format.

[0124] Requests are transmitted through an encrypted channel. The channel key is negotiated in real time by the user terminal and the cooperating server through a key exchange algorithm. An independent session key is generated for each request to prevent link hijacking.

[0125] During transmission, the terminal identifier and the current application identifier are SM4 symmetrically encrypted to further enhance field confidentiality and prevent requests from being forged after the identifier is stolen.

[0126] Additionally, users can set a preset timeout period as a timeout retransmission limit. If no response is received from the server after the preset timeout period, the system will automatically retransmit once; if there is still no response, a network error will be displayed, and the process will be terminated.

[0127] After receiving the request, the collaborative server immediately returns a confirmation of receipt, informing the terminal that the request has been accepted and preventing the terminal from sending it repeatedly.

[0128] S802. Obtain the request response sent by the collaborative server. The request response includes: soft module identifier.

[0129] Specifically, after receiving a creation request, the collaborative server verifies whether the terminal identifier has been registered on the security service platform, whether the current application identifier has key negotiation permissions, and whether the number of requests is within a preset reasonable range. Once the verification is successful, a soft module identifier is generated to ensure uniqueness.

[0130] The soft module identifier is encrypted using SM2 asymmetric encryption to prevent identifier leakage during transmission. The terminal SDK receives request responses through an encrypted channel, extracts the encrypted soft module identifier, and decrypts it using its own temporary private key to obtain the plaintext identifier.

[0131] S803. Create a local database based on the terminal identifier and the software module identifier.

[0132] Specifically, the terminal SDK is used to extract the terminal identifier and software module identifier stored in memory, and they are concatenated sequentially according to a preset order strategy to form the original password string. The SM3 hash algorithm is then used to calculate the password hash value, which serves as the final protection password for the database.

[0133] The protection password is generated only temporarily when the database is created and accessed, and is not written to the local terminal file. The original password component in memory is cleared immediately after use to prevent leakage.

[0134] The SDK calls the local database encryption interface, specifies the database storage path, and sets the database name. A preset encryption algorithm is used to encrypt the entire database file; the encryption key is the password hash value generated above, ensuring data storage security.

[0135] S804. The terminal and the collaborative server negotiate to determine the first private key, the second private key, and the complete public key.

[0136] Specifically, the terminal SDK calls the collaboration software module to generate a first private key and a first public key based on the SM2 algorithm. The first public key is then sent to the collaboration server. Upon receiving the first public key, the collaboration server verifies its integrity. If the verification passes, a second private key is generated, followed by a second public key. Finally, a complete public key is generated using the first and second public keys. The collaboration server encrypts the complete public key and sends the ciphertext to the user terminal via an encrypted channel. The user terminal receives the ciphertext and decrypts it to obtain the complete public key.

[0137] In this embodiment, a local database is created based on the terminal identifier and the software module identifier to prevent unauthorized access. The first private key and the second private key are stored in a distributed manner to fundamentally avoid the risk of complete key leakage and lay the foundation for subsequent encryption and collaborative decryption.

[0138] As an optional implementation, the process of using the terminal to negotiate and determine the first private key, the second private key, and the complete public key is as follows: the terminal randomly generates the first private key and generates the first public key based on the first private key, and sends the first public key to the collaborative server, so that the collaborative server generates the second private key and the complete public key based on the first public key, and sends the complete public key to the terminal.

[0139] The first and second private keys are stored on the user terminal and the collaborative server, respectively. No single entity possesses the complete private key. Even if a portion of the private key is stolen, an attacker cannot recover the complete private key, thus fundamentally avoiding the risk of single point of leakage. The first public key is a public key. Even if it is intercepted during transmission, an attacker cannot use it to obtain the first or second private key. Only the integrity of the transmission needs to be ensured, without the need for additional high-strength encryption.

[0140] As an optional implementation, the collaborative server can randomly generate a second private key and store it in a hardware secure area without writing it to the server's disk. Then, the collaborative server can generate a complete public key based on the second private key and the first public key. The collaborative server can encrypt the complete public key using the first public key and send the ciphertext to the user terminal. The user terminal can then decrypt the ciphertext using the first private key to obtain the complete public key.

[0141] Next, refer to Figure 9 The specific steps in step S304 above, where the terminal negotiates with the collaborative server to decrypt the ciphertext of the charging key to obtain the charging key, are described below. Figure 9 This is a schematic diagram of a process for obtaining a charging key provided in an embodiment of this application.

[0142] S901. The user terminal generates a first intermediate value based on the second key ciphertext and the first private key, and sends the first intermediate value to the collaborative server, so that the collaborative server generates a second intermediate value based on the second private key and the first intermediate value, and sends the second intermediate value to the user terminal.

[0143] Specifically, the terminal SDK is used to unlock the local database via a PIN password, extracting the first key ciphertext and the first private key. The SDK uses the first private key as the operation key to perform partial decryption operations on the second key ciphertext to obtain the first intermediate value. Then, the first intermediate value is encrypted based on the pre-shared shared key to obtain the first intermediate value ciphertext, which is then sent to the collaborative server through an encrypted channel.

[0144] The collaborative server uses the shared key to decrypt the first intermediate value ciphertext, obtaining the first intermediate value. Simultaneously, it extracts the second private key bound to the terminal from the server's hardware security zone and verifies the validity of the second private key.

[0145] After successful verification, the collaborative server calls the SM2 collaborative decryption module, using the second private key as the operation key, to perform a second operation on the first intermediate value to calculate the second intermediate value. The collaborative server can then use the first public key to encrypt the second intermediate value and send the ciphertext of the second intermediate value to the user terminal.

[0146] After receiving the second intermediate value ciphertext using the terminal, the second intermediate value ciphertext is decrypted using the first private key to obtain the second intermediate value.

[0147] S902. The terminal uses the first private key to decrypt the second intermediate value to obtain the filling encryption key.

[0148] Specifically, the terminal SDK first verifies the validity of the second intermediate value. After the verification is successful, the SDK calls the SM2 collaborative decryption module to decrypt the second intermediate value based on the first private key to obtain the filling encryption key.

[0149] Then, the validity of the charging encryption key is verified. If the verification is successful, the SDK can temporarily encrypt the charging encryption key with a pre-generated local key. The encrypted charging encryption key is temporarily stored in the terminal memory and is only temporarily decrypted when decrypting the charging key. After use, the plaintext charging encryption key in memory is immediately cleared.

[0150] S903. The terminal decrypts the ciphertext of the charging key based on the charging encryption key to obtain the charging key.

[0151] Upon receiving the usage instruction, the terminal SDK is used to extract the ciphertext of the charging encryption key from the local database. After verifying the integrity of the ciphertext, the ciphertext is decrypted based on the local key to obtain the charging encryption key. Then, the ciphertext is decrypted using the charging encryption key to obtain the charging key.

[0152] In this embodiment, the terminal and the collaborative server work together to decrypt the second key ciphertext, avoiding the risk of leakage from a single point of decryption.

[0153] Next, refer to Figure 10 This section describes the complete key filling process. Figure 10 This is a flowchart illustrating a key filling process provided in an embodiment of this application.

[0154] S1001, The filling terminal sends an authentication request to the secure medium; S1002. Secure media is used for authentication; S1003, The filling terminal sends an authentication request to the security service platform; S1004. The security service platform performs identity verification. If the security media and the security service platform are authenticated, then S1005, the security media creates a key storage application, a key storage container, and a key storage file; S1006, Secure medium generates medium private key and medium public key; S1007. The secure medium sends the media public key to the filling terminal. S1008. The filling terminal sends the security medium's serial number, media public key, and filling key quantity to the security service platform. S1009. The security service platform calls the HSM to generate a charging key; S1010, the security service platform calls HSM to generate the platform public key and platform private key; S1011, The security service platform calls HSM to encrypt the platform's public key and private key based on the medium's public key, and obtains the digital envelope; S1012, The security service platform calls HSM to generate a charging encryption key; S1013. The security service platform calls HSM to encrypt the charging key based on the charging encryption key, and obtains the charging key ciphertext. S1014. The security service platform calls HSM to encrypt and inject the encryption key based on the platform's public key, and obtains the first key ciphertext. S1015. The security service platform calls the HSM to calculate the ciphertext hash value of the injection key and the hash value of the injection key. S1016. The secure service platform sends the digital envelope, the ciphertext of the filling key, the ciphertext of the first key, the hash value of the ciphertext of the filling key, and the hash value of the filling key to the filling terminal. S1017. The filling terminal undergoes a valid verification. If the verification passes, then in S1018, the filling terminal sends the digital envelope, the filling key ciphertext, the first key ciphertext, the filling key ciphertext hash value, and the filling key hash value to the secure medium. S1019. Verify the legitimacy of the security medium; If the verification passes, then S1020, the first key ciphertext and the filling key ciphertext are stored on the secure medium.

[0155] After filling is complete, the next step is to refer to... Figure 11 This section describes the complete key transfer process. Figure 11 This is a flowchart illustrating a key transfer process provided in an embodiment of this application.

[0156] S1101. The terminal sends the terminal identifier, the current application identifier, and the number of requests to the collaborative server. S1102. The collaborative server sends the soft module identifier to the user terminal; S1103. The terminal creates a local database based on the terminal identifier and the software module identifier; S1104. Use the terminal to generate the first private key and the first public key; S1105. Use the terminal to send the first public key to the collaborative server; S1106, The collaborative server generates a second private key; S1107. The collaborative server generates a second public key based on the second private key; S1108. The collaborative server generates a complete public key based on the first public key and the second public key; S1109. The collaborative server sends the complete public key to the user terminal; S1110. Use the terminal to store the first private key and the complete public key in the local database; After the secure medium is connected to the terminal, S1111, the terminal obtains the complete public key from the local database; S1112. Use the terminal to send the complete public key to the secure medium; S1113. The security medium decrypts the first key ciphertext based on the platform's private key to obtain the filling encryption key; S1114. The secure medium encrypts the injected encryption key based on the complete public key to obtain the second key ciphertext; S1115. The secure medium sends the second key ciphertext and the filling key ciphertext to the user terminal. S1116. Use the terminal to store the second key ciphertext and the charging key ciphertext into the local database.

[0157] After the key transfer is complete, the next step is to refer to... Figure 12 This section describes the complete process of key usage. Figure 12 This is a flowchart illustrating a key usage process provided in an embodiment of this application. Before using the key, the security medium can be removed from the user terminal.

[0158] S1201. Use the terminal to obtain the first private key and the second key ciphertext from the local database; S1202: The terminal obtains the first intermediate value based on the first private key and the second key ciphertext; S1203. Use the terminal to send the first intermediate value to the collaborative server; S1204. The collaborative server obtains the second intermediate value based on the second private key and the first intermediate value; S1205, The collaborative server sends the second intermediate value to the user terminal; S1206. The terminal decrypts the second intermediate value based on the first private key to obtain the filling encryption key; S1207. Use the terminal to obtain the charging key ciphertext from the local database; S1208. The terminal decrypts the ciphertext of the charging key based on the charging encryption key to obtain the charging key; S1209. Use the terminal cache to charge the key; S1210. Use the terminal to send a session key request to the security service platform; S1211. The secure service platform sends the session key ciphertext to the user terminal; S1212. Use the terminal to obtain the charging key from the cache, decrypt the session key ciphertext, and obtain the session key; S1213. The terminal uses the session key to perform session encryption and data transmission of the data to be encrypted.

[0159] The specific execution process of each of the above steps has been described in detail in the foregoing embodiments, and will not be repeated here.

[0160] This application also provides a key system, which includes: a secure medium, a filling terminal, a user terminal, a cryptographic service platform, and a collaborative server. The key system is used to execute the steps of a mobile terminal-based quantum key storage and usage method.

[0161] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for storing and using quantum keys on a mobile device, characterized in that, The method is applied to a key system, which includes: a secure medium, a filling terminal, a user terminal, a cryptographic service platform, and a collaborative server. After the secure medium is connected to the refilling terminal, the secure medium generates a private key and a public key. The refilling terminal generates a refilling request and sends it to the security service platform. The refilling request includes: the secure medium's serial number, the media's public key, and a preset amount of refilling key. The secure service platform generates data to be recharged based on the recharge request. The data to be recharged includes a digital envelope, recharge key ciphertext, first key ciphertext, recharge key ciphertext hash value, and recharge key hash value. The secure medium stores the first key ciphertext and recharge key ciphertext in the data to be recharged. After the secure medium is connected to the user terminal, the secure medium re-encrypts the first key ciphertext in the secure medium based on the complete public key negotiated by the user terminal to obtain the second key ciphertext, and stores the second key ciphertext and the filling key ciphertext in the local database of the user terminal. After the secure medium is removed from the user terminal, the user terminal obtains the first private key, the second key ciphertext, and the refill key ciphertext from the local database, and negotiates with the collaborative server to decrypt the refill key ciphertext to obtain the refill key. The user terminal then performs session encryption based on the session key obtained from the secure service platform and the refill key.

2. The method for storing and using quantum keys on a mobile device according to claim 1, characterized in that, The secure medium generates a private key and a public key for the medium, including: The secure medium and the secure service platform respectively verify the user's identity. After successful verification, a key storage application and a key storage container are created in the secure medium, and an application access password is set. A key storage file is created, which is the file in the key storage container used to store the charging key. The secure medium generates a private key and a public key.

3. The method for storing and using quantum keys on a mobile device according to claim 1, characterized in that, The security service platform generates data to be filled based on the filling request, including: The secure service platform generates a charging key based on the charging request, and calls the hardware security module to generate the platform public key and the platform private key; The platform private key and the platform public key are encrypted using the media public key to obtain a digital envelope; Generate a filling encryption key, and encrypt the filling key based on the filling encryption key to obtain the filling key ciphertext; The charging encryption key is encrypted using the platform's public key to obtain the first key ciphertext; Calculate the hash value of the ciphertext of the injection key to obtain the hash value of the ciphertext of the injection key, and calculate the hash value of the injection key to obtain the hash value of the injection key.

4. The method for storing and using quantum keys on a mobile device according to claim 1, characterized in that, The secure medium stores the first key ciphertext and the filling key ciphertext in the data to be filled, including: The security service platform sends the data to be recharged to the recharge terminal; The filling terminal calculates the hash value of the filling key ciphertext to obtain the first hash value to be verified; The filling terminal calculates the hash value of the filling key to obtain a second hash value to be verified; If the first hash value to be verified is the same as the hash value of the ciphertext of the filling key, and the second hash value to be verified is the same as the hash value of the filling key, then the data to be filled is sent to the secure medium. The secure medium verifies the data to be filled, and stores the first key ciphertext and the filling key ciphertext after successful verification.

5. The method for storing and using quantum keys on a mobile device according to claim 4, characterized in that, The safety medium verifies the data to be filled, including: The secure medium decrypts the digital envelope using its private key to obtain the platform public key and the platform private key; The first key ciphertext is decrypted based on the platform's private key to obtain the key ciphertext to be verified. If the ciphertext of the charging key to be verified is the same as the ciphertext of the charging key, then the verification is successful.

6. The method for storing and using quantum keys on a mobile device according to claim 1, characterized in that, The secure medium uses the complete public key negotiated with the terminal to encrypt the first key ciphertext in the secure medium, resulting in a second key ciphertext, which includes: The user terminal negotiates with the collaborative server to determine the first private key, the second private key, and the complete public key, and stores the first private key and the complete public key in the user terminal's local database. After the secure medium is connected to the user terminal, the user terminal sends the complete public key to the secure medium; the secure medium then uses the complete public key to encrypt the first key ciphertext in the secure medium to obtain the second key ciphertext.

7. The method for storing and using quantum keys on a mobile device according to claim 6, characterized in that, The secure medium uses the complete public key to encrypt the first key ciphertext in the secure medium to obtain the second key ciphertext, which includes: The secure medium uses the platform's private key to decrypt the first key ciphertext to obtain the first key, and then uses the complete public key to encrypt the first key to obtain the second key ciphertext.

8. The method for storing and using quantum keys on a mobile device according to claim 1, characterized in that, Prior to the use of the secure media access terminal, the method further includes: The user terminal sends a creation request to the collaborative server. The creation request includes: user terminal identifier, current application identifier, and number of requests. Obtain the request response sent by the collaborative server, the request response including: soft module identifier; A local database is created based on the terminal identifier and the software module identifier; The user terminal negotiates and determines the first private key, the second private key, and the complete public key with the collaborative server.

9. The method for storing and using quantum keys on a mobile device according to claim 8, characterized in that, The user terminal and the collaborative server negotiate and determine the first private key, the second private key, and the complete public key, including: The user terminal randomly generates a first private key and generates a first public key based on the first private key. The first public key is then sent to the collaborative server, so that the collaborative server generates a second private key and a complete public key based on the first public key, and sends the complete public key to the user terminal.

10. The method for storing and using quantum keys on a mobile device according to claim 1, characterized in that, The user terminal negotiates with the collaborative server to decrypt the ciphertext of the injection key to obtain the injection key, including: The user terminal generates a first intermediate value based on the second key ciphertext and the first private key, and sends the first intermediate value to the collaborative server, so that the collaborative server generates a second intermediate value based on the second private key and the first intermediate value, and sends the second intermediate value to the user terminal. The terminal uses the first private key to decrypt the second intermediate value to obtain the filling encryption key; The terminal uses the charging encryption key to decrypt the charging key ciphertext to obtain the charging key.

Images