Key charging method and device, electronic equipment, storage medium and program product

Abstract

The invention provides a key charging method and device, electronic equipment, a storage medium and a program product, and relates to the technical field of security. The method comprises the following steps: receiving a key charging request; the key charging request comprises a first identifier of the card to be charged; under the condition that a new first key needs to be generated, generating the new first key based on a second key of the to-be-charged card and first data used for generating the first key; the second key is generated based on the first identifier; based on the new first key, encrypting a third key of the to-be-charged card generated by the first platform to obtain a first ciphertext; and sending the first ciphertext and the first data to a second platform. According to the invention, the situation that the first keys encrypted for the third key are the same each time can be avoided, so that the security of key charging is improved; and the second platform is prevented from having the third key, so that the security of the third key is improved.

Description

Technical Field

[0001] This application relates to the field of security technology, and in particular to a key filling method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] With the rapid development of internet technology, network security risks of information systems continue to increase, and the threats and challenges are becoming increasingly severe. Cryptographic security is a crucial foundation of information security, effectively protecting the data security of network information systems. Cryptographic technology is a core technology and important means of ensuring the security of network information systems. Therefore, to improve the security of business systems, it is necessary to inject keys into the secure area of ​​the terminal.

[0003] Currently, keys are sent in batches from the primary cryptographic service platform to the key filling platform for filling. The key filling platform can obtain the same full set of keys as the primary cryptographic service platform, which cannot guarantee the security of the key filling process. Summary of the Invention

[0004] This application provides a key filling method, apparatus, electronic device, storage medium, and program product to address the low security of the key filling process in the prior art and achieve highly secure key filling.

[0005] This application provides a key injection method applied to a first platform, the key injection method comprising: Receive a key recharge request; the key recharge request is used to request the recharge of a third key for the card to be recharged, and the key recharge request includes a first identifier of the card to be recharged; If a new first key needs to be generated, a new first key is generated based on the second key of the card to be refilled and the first data used to generate the first key; the second key is generated based on the first identifier. Based on the new first key, the third key of the card to be recharged generated by the first platform is encrypted to obtain the first ciphertext; The first ciphertext and the first data are sent to the second platform.

[0006] This application also provides a key injection method, applied to a terminal with a card to be injected installed, the key injection method comprising: Receive second data from the second platform; the second data includes the first ciphertext generated by the first platform. If the second data also includes first data for generating a first key, a new first key is generated based on the second key of the card to be recharged and the first data; the second key is generated based on the first identifier of the card to be recharged. The new first key is used to decrypt the first ciphertext to obtain the third key of the card to be recharged generated by the first platform.

[0007] This application also provides a key injection method applied to a second platform, the key injection method comprising: Receive the first ciphertext and the first data for generating the first key sent by the first platform; The first ciphertext and the first data are injected into the card to be injected installed in the terminal; Wherein, the first ciphertext is obtained by encrypting the third key of the card to be recharged generated by the first platform based on the new first key; the new first key is generated based on the second key of the card to be recharged and the first data; the second key is generated based on the first identifier of the card to be recharged.

[0008] This application also provides a key filling method applied to a third platform, the key filling method comprising: Receive the fifth key sent by the first platform; Based on the fifth key and the first identifier of the card to be recharged, a second key for the card to be recharged is generated; Write the second key into the card to be filled; The fifth key is generated based on the second identifier of the card to be recharged; the terminal installed on the card to be recharged is used to generate a new first key based on the second key and the first data used to generate the first key; the new first key is used to decrypt the first ciphertext recharged by the second platform to obtain the third key of the card to be recharged generated by the first platform.

[0009] This application also provides a key filling device, deployed on a first platform, the key filling device comprising: A request receiving module is used to receive a key recharge request; the key recharge request is used to request the recharge of a third key for a card to be recharged, and the key recharge request includes a first identifier of the card to be recharged; The first generation module is configured to generate a new first key based on the second key of the card to be refilled and the first data used to generate the first key when a new first key needs to be generated; the second key is generated based on the first identifier. The key encryption module is used to encrypt the third key of the card to be recharged generated by the first platform based on the new first key to obtain the first ciphertext; The ciphertext sending module is used to send the first ciphertext and the first data to the second platform.

[0010] This application also provides a key filling device, deployed on a terminal with a card to be filled installed, the key filling device comprising: The first receiving module is used to receive the second data charged by the second platform; the second data includes the first ciphertext generated by the first platform. The second generation module is configured to generate a new first key based on the second key of the card to be recharged and the first data, provided that the second data also includes first data for generating the first key; the second key is generated based on the first identifier of the card to be recharged. The new first key is used to decrypt the first ciphertext to obtain the third key of the card to be recharged generated by the first platform.

[0011] This application also provides a key filling device, deployed on a second platform, the key filling device comprising: The second receiving module is used to receive the first ciphertext sent by the first platform and the first data used to generate the first key; The data filling module is used to fill the first ciphertext and the first data into the card to be filled installed in the terminal; Wherein, the first ciphertext is obtained by encrypting the third key of the card to be recharged generated by the first platform based on the new first key; the new first key is generated based on the second key of the card to be recharged and the first data; the second key is generated based on the first identifier of the card to be recharged.

[0012] This application also provides a key filling device, deployed on a third platform, the key filling device comprising: The third receiving module is used to receive the fifth key sent by the first platform; The third generation module is used to generate a second key for the card to be recharged based on the fifth key and the first identifier of the card to be recharged; A key writing module is used to write the second key into the card to be refilled; The fifth key is generated based on the second identifier of the card to be recharged; the terminal installed on the card to be recharged is used to generate a new first key based on the second key and the first data used to generate the first key; the new first key is used to decrypt the first ciphertext recharged by the second platform to obtain the third key of the card to be recharged generated by the first platform.

[0013] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement any of the key injection methods described above.

[0014] This application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the key injection method as described above.

[0015] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the key injection methods described above.

[0016] The key injection method, apparatus, electronic device, storage medium, and program product provided in this application include a first platform that receives a key injection request. When a new first key needs to be generated, a new first key is generated based on a second key of the card to be injected and first data used to generate the first key. The second key is generated based on a first identifier of the card to be injected, thus avoiding the use of the same first key for encrypting the third key each time, thereby improving the security of key injection. Based on the new first key, the third key of the card to be injected generated by the first platform is encrypted to obtain a first ciphertext. The first ciphertext and the first data are sent to a second platform, thus preventing the second platform from also possessing the third key, thereby improving the security of the third key, i.e., improving the security of key injection. The second platform is used to inject the first ciphertext and the first data into the card to be injected installed in the terminal, so that the card to be injected can decrypt based on the first data to obtain the third key, ensuring that the third key is successfully injected into the card to be injected, thereby improving the security of the business system. Attached Figure Description

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

[0018] Figure 1 This is one of the flowcharts illustrating the key filling method provided in this application.

[0019] Figure 2 This is the second flowchart of the key filling method provided in this application.

[0020] Figure 3 This is the third flowchart of the key filling method provided in this application.

[0021] Figure 4 This is the fourth flowchart of the key filling method provided in this application.

[0022] Figure 5 This is the fifth flowchart of the key filling method provided in this application.

[0023] Figure 6 This is one of the structural schematic diagrams of the key filling device provided in this application.

[0024] Figure 7 This is the second schematic diagram of the key filling device provided in this application.

[0025] Figure 8 This is the third schematic diagram of the key filling device provided in this application.

[0026] Figure 9 This is the fourth schematic diagram of the key filling device provided in this application.

[0027] Figure 10 This is a schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] Currently, keys on terminals are primarily obtained through a key-granting method, where they are granted offline in a single transaction to the secure area of ​​the UE (User Equipment) to construct a key resource pool. Business applications then retrieve and use keys from this pool. This secure area can be a SIM (Subscriber Identity Module) card, a USIM (Universal Subscriber Identity Module) card, a Super SIM card, or an SD (Secure Digital) card, etc.

[0030] In related technologies, the security zone of a UE is illustrated using a USIM card as an example. To ensure the security of keys (such as quantum keys), keys are generally managed in layers. Specifically, the cryptographic service platform (such as the quantum cryptographic service level 1 platform, QCSC-L1) is responsible for generating secure keys, and the cryptographic service platform sends the keys in batches to the filling platform, which then fills them onto the USIM cards through a filling system. Based on this, during business use, the cryptographic service platform distributes the keys to the level 2 cryptographic service platform (such as the level 2 quantum cryptographic service platform) or the business platform for use.

[0031] However, existing technologies have two main problems: First, multiple parties possess all the keys. These keys are distributed in batches by the cryptographic service platform to the recharge platform, which then recharges the USIM cards. This means the recharge platform can obtain the same keys for all USIM cards across the network as the cryptographic service platform. Second, different operators may affect key security. Since the cryptographic service platform and the recharge platform may have different operators and responsibilities, key security is compromised. In short, existing technologies cannot guarantee the security of the key recharge process.

[0032] To address the above problems, this application proposes the following embodiments. The following is a detailed explanation... Figures 1-5 This application describes the key filling method.

[0033] This application provides a key filling method applied to a first platform. Figure 1 This is one of the flowcharts illustrating the key filling method provided in this application, such as... Figure 1 As shown, the key filling method applied to the first platform includes the following steps 110, 120, 130 and 140.

[0034] Step 110: Receive key filling request.

[0035] Here, the first platform can be a cryptographic service platform. In one embodiment, the cryptographic service platform can be a quantum cryptographic service platform (such as a quantum cryptographic service level 1 platform, QCSC-L1). This first platform is responsible for generating and managing the sixth key of the first platform and deriving the fifth key of the SIM card. For example, the quantum cryptographic service level 1 platform is responsible for generating and managing the root key (QSRK) of the quantum cryptographic service level 1 platform and deriving the card vendor key (QCVK) of the quantum SIM card.

[0036] The key recharge request is used to request the recharge of a third key for the card to be recharged, and the key recharge request includes the first identifier of the card to be recharged.

[0037] Here, the card to be recharged is the card for which a key is to be recharged. This card is the UE's secure area and can be a SIM card, USIM card, Super SIM card, or SD card, etc.

[0038] Here, the first identifier is used to uniquely identify the card to be refilled. In one specific embodiment, the first identifier is SEID (Secure Element Identifier).

[0039] In one embodiment, the key charging request may further include at least one of the following: the number of cards produced, a second identifier, a first set of identifiers for the cards to be charged (such as a SEID list), the number of keys charged per card, key grouping rules, etc.

[0040] In one embodiment, a key filling request sent by a second platform is received.

[0041] Step 120: If a new first key needs to be generated, a new first key is generated based on the second key of the card to be refilled and the first data used to generate the first key.

[0042] The second key is generated based on the first identifier. Therefore, different cards have different second keys, ensuring that different cards have different first keys, thus preventing the same key from being written into multiple cards for initialization, thereby improving the security of key filling. Specifically, the second key of the card to be filled is derived based on the first identifier. For example, the second key is derived using a key derivation function.

[0043] In one embodiment, the first key is a card refill encryption key.

[0044] In one embodiment, the second key is the QCRK key.

[0045] Here, the first data is used to generate the first key. This first data may include, but is not limited to, random data randomly generated by the first platform and first parameters, etc.; the first parameter is an incrementing parameter. The first parameter may be a sequence number (SQN); the sequence number is incrementing.

[0046] Considering that using the same first key to encrypt the third key each time could pose a security risk, the first data includes a random number. This increases the randomness of the third key, thereby improving the security of key injection. Furthermore, the first data includes a first parameter, which is an incrementing parameter. This prevents the second platform from replaying old injection data, thus avoiding the risk of updating the key to an old first key and ensuring the updating of the new first key, thereby enhancing the security of key injection.

[0047] In one specific embodiment, a new first key is derived based on the second key and the first data. More specifically, the hash value of the first data is calculated based on the second key, and the new first key is generated based on this hash value. Further, the new first key is derived based on the second key, the first data, the first identifier, and a first string used to identify the first key. Exemplarily, the new first key is derived based on a key derivation function; for example, the formula for generating the first key is as follows: QCFKenc=KDF(QCRK,SEID,RAND,SQN,“enc”); In the formula, QCFKenc represents the first key, KDF() represents the key derivation function, QCRK represents the second key, SEID represents the first identifier, RAND represents random data, SQN represents the first parameter, and "enc" represents the first string. In one embodiment, KDF=HMAC(K, S), where S is the input parameter and K is the key used. The specific algorithm can be HMAC-SHA-256, etc., and is not specifically limited here.

[0048] It should be noted that situations requiring the generation of a new first key include: the first platform does not have a local first key and / or the first key of the card to be recharged needs to be updated according to the security policy.

[0049] Step 130: Based on the new first key, encrypt the third key of the card to be recharged generated by the first platform to obtain the first ciphertext.

[0050] Here, the third key is the key to be injected generated by the first platform, and this third key is the key that needs to be encrypted and protected. For example, the third key is a quantum key, meaning the first platform is a first-level platform for quantum cryptography services. The first ciphertext is the encrypted third key, such as the injection key ciphertext.

[0051] In one embodiment, the third key is the card base key (QCBK).

[0052] To enhance the security of business systems, a third key can be a quantum key. Based on the principles of quantum mechanics, quantum keys utilize the non-cloning and non-measurable properties of quantum states to achieve a novel encrypted communication method. By employing quantum keys, business systems can achieve unconditionally secure communication, significantly improving system security. Simultaneously, quantum keys are distributed rapidly, enabling real-time encrypted communication and enhancing communication efficiency. Using quantum keys is an effective means of improving the security of business systems, ensuring both information security and communication efficiency.

[0053] In one specific embodiment, the third key is symmetrically encrypted based on the new first key to obtain the first ciphertext.

[0054] For example, the first platform generates a specified number of third keys for each card to be recharged according to the card production order, and uses the first key corresponding to each card to encrypt the third keys to generate first ciphertext, and uses the fourth key to perform integrity security protection on the first ciphertext to generate the integrity digest value of the first ciphertext (i.e. the first message authentication code).

[0055] Step 140: Send the first ciphertext and the first data to the second platform.

[0056] The second platform is used to inject the first encrypted text and first data into the SIM card installed in the terminal. This second platform receives injection tasks from the first platform, either individually or in batches, and injects the first encrypted text into the key service card application of the SIM card through an injection system, thus completing the key injection. This injection system (such as a SIM card injection system) is mainly responsible for writing data into the card to complete the key injection. Specifically, the second platform (such as a SIM card injection platform) is responsible for generating and managing the ninth key of the SIM card, deriving the eighth key, and batch injecting injection data containing the third key into the SIM card.

[0057] The terminal is used to install the card to be recharged, for example, the terminal is a UE. In one specific embodiment, the terminal has a key service card application (such as a quantum key service card application); the quantum key service card application is a card application (applet) on the quantum SIM card, which can support recharging and storing a certain number of third keys offline or online.

[0058] For example, the first platform returns a key recharge response message to the second platform, which includes a specified number of first ciphertexts and a first message authentication code. If the first key or fourth key of a card to be recharged needs to be updated, the key recharge response message should also include the first data corresponding to the card to be recharged.

[0059] For the second platform, the second platform receives the first ciphertext and the first data sent by the first platform, and fills the first ciphertext and the first data into the card to be filled installed in the terminal.

[0060] For the terminal, the terminal receives the charging data from the second platform. The charging data includes the first ciphertext generated by the first platform. If the charging data also includes the first data, a new first key is generated based on the second key and the first data. The new first key is used to decrypt the first ciphertext to obtain the third key generated by the first platform.

[0061] It should be understood that the first data also needs to be sent to the second platform so that the second platform can fill the card to be filled with the first data, so that it can generate a new first key in the same way, and then decrypt it to obtain the third key.

[0062] The key injection method provided in this application receives a key injection request. When a new first key needs to be generated, a new first key is generated based on the second key of the card to be injected and the first data used to generate the first key. The second key is generated based on the first identifier of the card to be injected, thereby avoiding the first key being the same each time the third key is encrypted, thus improving the security of key injection. Based on the new first key, the third key of the card to be injected generated by the first platform is encrypted to obtain a first ciphertext. The first ciphertext and the first data are sent to the second platform, thereby preventing the second platform from also possessing the third key, thus improving the security of the third key, i.e., improving the security of key injection. The second platform is used to inject the first ciphertext and the first data into the card to be injected installed on the terminal, so that the card to be injected can decrypt based on the first data to obtain the third key, ensuring that the third key is successfully injected into the card to be injected, thereby improving the security of the business system.

[0063] Based on any of the above embodiments, in this method, the first data includes random data and / or a first parameter; the first parameter is an incrementing parameter.

[0064] Here, the random data is randomly generated by the first platform, which increases the randomness of the first key and thus improves the security of key injection.

[0065] The first parameter is an incrementing parameter, for example, incrementing by 1 each time. This avoids the risk of a second platform replaying old second data, causing the key to be updated to an old first key, thus ensuring the update of the new first key and improving the security of key injection.

[0066] In one embodiment, the first parameter can be a serial number; the serial number is incremented.

[0067] In one embodiment, the first parameter can be sent from the third platform to the first platform. Furthermore, the first parameter can be a parameter corresponding to the card to be recharged; that is, the third platform pre-stores the first parameter of the card to be recharged, for example, the third platform initializes the first parameter of the card to be recharged to 0.

[0068] In one embodiment, a new first key is derived based on a second key and random data. More specifically, a hash value of the random data is calculated based on the second key, and a new first key is generated based on that hash value.

[0069] In another embodiment, a new first key is derived based on the second key and the first parameter. More specifically, a hash value of the first parameter is calculated based on the second key, and the new first key is generated based on that hash value.

[0070] In another embodiment, concatenated data is obtained by splicing random data and a first parameter. A new first key is derived based on a second key and the concatenated data. More specifically, a hash value of the concatenated data is calculated based on the second key, and a new first key is generated based on this hash value.

[0071] The key filling method provided in this application generates random data, and the first data includes random data, thereby increasing the randomness of the first key and improving the security of key filling; and the first data includes a first parameter, and the first parameter is an incrementing parameter, which avoids the risk that the second platform will update the key to the old first key by replaying the old filling data, ensuring that the new first key is updated, thereby improving the security of key filling.

[0072] Based on any of the above embodiments, the new first key is generated based on the first identifier, the second key, the first data, and the first string used to identify the first key.

[0073] In one embodiment, the new first key is derived based on a key derivation function. For example, the formula for generating the first key is as follows: QCFKenc=KDF(QCRK,SEID,RAND,SQN,“enc”); In the formula, QCFKenc represents the first key, KDF() represents the key derivation function, QCRK represents the second key, SEID represents the first identifier, RAND represents random data, SQN represents the first parameter, and "enc" represents the first string.

[0074] In another embodiment, a first identifier, first data, and a first string are concatenated to obtain first concatenated data; a first hash value of the first concatenated data is calculated based on a second key; and a new first key is generated based on the first hash value. The concatenation order of the data can be set according to actual needs, as long as the generation method of the terminal is the same as that of the first platform. The algorithm for calculating the first hash value can be HMAC-SHA-256, etc., and is not specifically limited here.

[0075] The key filling method provided in this application generates a new first key based on a first identifier to ensure that the first keys of different cards are different, thereby improving the accuracy of key filling; and generates a new first key based on a first string used to identify the first key to identify the first key.

[0076] Based on any of the above embodiments, after step 130, the method further includes: Based on the fourth key of the card to be refilled, the first ciphertext is protected for integrity, and a first message authentication code is generated. Send the first message authentication code to the second platform.

[0077] In one embodiment, the fourth key is the card filling integrity protection key (QCFKint).

[0078] Here, the first ciphertext is the data requiring integrity protection. A corresponding first message authentication code is generated based on it, thereby achieving integrity protection for the first ciphertext. More specifically, the first message authentication code is derived based on the fourth key and the first ciphertext.

[0079] In one specific embodiment, a hash value of the first ciphertext is calculated based on the fourth key, and a first message authentication code is generated based on this hash value. Exemplarily, the first message authentication code is calculated using an integrity calculation function.

[0080] The second platform is also used to send the first message authentication code to the terminal. Based on this, the terminal needs to generate a first message verification code based on the first ciphertext using the method for generating the first message authentication code. Only when the first message verification code matches the first message authentication code is the first ciphertext considered complete, thus ensuring that the third key used by the terminal for decryption is accurate. This, in turn, ensures successful decryption and the acquisition of the third key. Ultimately, while ensuring successful key injection, the integrity of the first ciphertext is also protected, thereby improving the security and accuracy of key injection.

[0081] The key injection method provided in this application generates a first message authentication code based on a first ciphertext, thereby achieving integrity protection of the first ciphertext and improving the security of key injection; the first message authentication code is sent to a second platform, and the second platform is also used to send the first message authentication code to a terminal, thereby ensuring that the third key decrypted by the terminal is accurate, thereby improving the security and accuracy of key injection.

[0082] Based on any of the above embodiments, in this method, the fourth key is generated in the following manner: The fourth key is generated based on the second key and the first data.

[0083] The second key is generated based on the first identifier. Therefore, different cards have different second keys, ensuring that different cards have different fourth keys. This prevents the same key from being written into multiple cards for initialization, thereby improving the security of key filling.

[0084] Here, the first data is used to generate the fourth key, and the first data may include, but is not limited to, random data randomly generated by the first platform and the first parameters, etc.

[0085] In one specific embodiment, a fourth key is derived based on the second key and the first data. More specifically, a hash value of the first data is calculated based on the second key, and the fourth key is generated based on this hash value. Further, the fourth key is derived based on the second key, the first data, the first identifier, and a second string used to identify the fourth key. Exemplarily, the fourth key is derived based on a key derivation function.

[0086] In one embodiment, the first data includes random data and / or a first parameter; the first parameter is an incrementing parameter. The fourth key is generated based on the first identifier, the first data, the second key, and a second string used to identify the fourth key.

[0087] For example, the formula for generating the fourth key is as follows: QCFKint=KDF(QCRK,SEID,RAND,SQN,“int”); In the formula, QCFKint represents the fourth key, KDF() represents the key derivation function, QCRK represents the second key, SEID represents the first identifier, RAND represents random data, SQN represents the first parameter, and "int" represents the second string.

[0088] In one embodiment, when a new fourth key needs to be generated, a fourth key is generated based on the second key of the card to be recharged and the first data used to generate the fourth key. It should be noted that situations requiring the generation of a new first key include: the first platform does not have a local fourth key and / or the fourth key of the card to be recharged needs to be updated according to a security policy.

[0089] It should be understood that a fourth key is generated based on the first identifier to ensure that the fourth key is different for different cards, thereby improving the accuracy of key filling; and a fourth key is generated based on the second string used to identify the fourth key, so as to identify the fourth key and distinguish it from the first key.

[0090] The key injection method provided in this application accurately generates a fourth key through the above-described manner, thereby better protecting the integrity of the first ciphertext and improving the security of key injection.

[0091] Based on any of the above embodiments, in this method, the second key is generated in the following manner: The second key is generated based on the fifth key of the card to be refilled and the first identifier.

[0092] The fifth key is generated based on the second identifier of the card to be refilled.

[0093] In one embodiment, the fifth key is the card vendor key (QCVK).

[0094] Here, the second identifier is used to uniquely identify the card vendor. The card vendor is the manufacturer of the cards to be refilled, primarily responsible for producing blank cards, which can support the writing of card application and personalized data. Based on this, different card vendors have different fifth keys. In one embodiment, the second identifier is the card vendor identification information of the card to be refilled, such as the card vendor ID (VID).

[0095] In one specific embodiment, the first platform derives a second key for the card to be recharged based on the fifth key and the first identifier. Exemplarily, the second key is generated based on a key derivation function; for example, the second key is generated in the following manner: QCRK = KDF(QCVK, SEID); In the formula, QCRK represents the second key, KDF() represents the key derivation function, QCVK represents the fifth key, and SEID represents the first identifier.

[0096] The key filling method provided in this application generates a second key based on the fifth key and the first identifier of the card to be filled. The fifth key is generated based on the second identifier of the card to be filled, thereby avoiding the second key of different cards being the same, and thus avoiding the first key of different cards being the same, ultimately improving the security of key filling.

[0097] Based on any of the above embodiments, the method further includes: After the fifth key is generated, it is sent to the third platform.

[0098] The third platform is used to generate the second key based on the fifth key and the first identifier, and to write the second key into the card to be refilled.

[0099] In one embodiment, the third platform is a key management system. Further, the third platform is the platform identified by the second identifier, for example, the third platform is a card vendor platform. The card vendor referred to in the card vendor platform is the manufacturer of the cards to be recharged, which is primarily responsible for producing the cards to be recharged.

[0100] It should be understood that the second key is written into the card to be recharged so that it can generate a new first key based on the second key of the card to be recharged and the first data, and then the first ciphertext can be decrypted based on the new first key.

[0101] Furthermore, the fifth key is sent to the third platform through a secure channel to ensure the security of the fifth key, thereby improving the security of key filling.

[0102] Furthermore, for the first platform, it can send the fifth keys of each card vendor to each third platform in batches.

[0103] Furthermore, after the third platform receives the fifth key, the third platform returns the initialization result of the fifth key to the first platform offline, that is, the first platform receives the card vendor key configuration result.

[0104] The key filling method provided in this application embodiment generates a fifth key on the first platform and then sends the fifth key to the third platform. The third platform can then use the fifth key and the first identifier to generate a second key and write the second key into the card to be filled, ensuring that the fifth key is also generated on the first platform, thereby improving the security of key filling.

[0105] Based on any of the above embodiments, in this method, sending the fifth key to the third platform includes: Based on the public key of the third platform, the fifth key is encrypted to obtain the second ciphertext; The second ciphertext is sent to the third platform.

[0106] Here, each third platform possesses its own unique public-private key pair (digital certificate), meaning each card vendor has its own unique public-private key pair (digital certificate) used to protect confidential information during the initialization of the first platform's related key processes in the preparation phase. The first platform can obtain the third platform's public key from secure channels. For example, the third platform's public key is the card vendor's digital certificate public key (VPK), which is used to encrypt and protect data such as the fifth key and the eighth key. This public key can be provided offline by the third platform.

[0107] For the third platform, based on its private key, it can decrypt the second ciphertext to obtain the fifth key, and this private key is kept secret by the third platform, thereby improving the security of the fifth key.

[0108] The second ciphertext is the encrypted fifth key. For example, the second ciphertext is generated based on the following method: EMK = Epub(VPK, QCVK); In the formula, EMK represents the second ciphertext, Epub() represents the public-key encryption algorithm, VPK represents the public key of the third platform, and QCVK represents the fifth key.

[0109] The key injection method provided in this application embodiment encrypts the fifth key based on the public key of the third platform to obtain the second ciphertext, and sends the second ciphertext to the third platform so that the third platform can decrypt the second ciphertext based on its secretly stored private key, thereby improving the security of the fifth key and thus improving the security of key injection.

[0110] Based on any of the above embodiments, in this method, sending the second ciphertext to the third platform includes: The second ciphertext is digitally signed based on the private key of the first platform; The digitally signed second ciphertext is sent to the third platform.

[0111] In one embodiment, the private key of the first platform is the quantum cryptography service level one platform private key (QSSK), which corresponds to the public key of the quantum cryptography service level one platform digital certificate (QSPK), and is used to digitally sign the fifth key, etc. The public key of the first platform is used to digitally sign and verify the data such as the fifth key.

[0112] Here, the first platform possesses its own unique public-private key pair (digital certificate). The third platform can obtain the first platform's public key through secure channels.

[0113] Furthermore, the second ciphertext after digital signature is encapsulated into a key file (such as a card vendor key file), and the key file is then securely sent to a third platform offline.

[0114] For the third platform, after obtaining the second ciphertext, it performs digital signature verification on the second ciphertext based on the public key of the first platform. After successful verification, it decrypts the second ciphertext using the private key of the third platform and securely stores the fifth key.

[0115] The key filling method provided in this application embodiment digitally signs the second ciphertext based on the private key of the first platform, and sends the digitally signed second ciphertext to the third platform so that the third platform can digitally verify the second ciphertext based on the public key of the first platform, thereby improving the accuracy and security of the fifth key, and thus improving the accuracy and security of key filling.

[0116] Based on any of the above embodiments, in this method, the fifth key is generated in the following manner: The fifth key is generated based on the sixth key of the first platform and the second identifier.

[0117] The sixth key is a key secretly stored by the first platform. This ensures the security of the generated fifth key. This sixth key can be used to derive the fifth key for each card vendor. In one embodiment, the sixth key is a root key (QSRK).

[0118] In one specific embodiment, a fifth key is derived based on the sixth key and the second identifier of the first platform. Exemplarily, the fifth key is generated based on a key derivation function; for example, the fifth key is generated in the following manner: QCVK = KDF(QSRK, VID); In the formula, QCVK represents the fifth key, KDF() represents the key derivation function, QSRK represents the sixth key, and VID represents the second identifier.

[0119] It should be understood that both the fifth and sixth keys are stored securely.

[0120] The key injection method provided in this application generates a fifth key based on the sixth key and the second identifier of the first platform. The sixth key is a key secretly stored by the first platform, thereby improving the security of the fifth key and thus improving the security of key injection.

[0121] Based on any of the above embodiments, this application also provides a key filling method applied to a terminal with a card to be filled installed. Figure 2 This is the second flowchart illustrating the key filling method provided in this application, as shown below. Figure 2 As shown, the key charging method applied to a terminal with a card to be charged includes the following steps 210 and 220.

[0122] Step 210: Receive the second data charged by the second platform.

[0123] Here, the terminal is used to install the card to be recharged, for example, the terminal is a UE. In one specific embodiment, the terminal has a key service card application (such as a quantum key service card application); the quantum key service card application is a card application (applet) on the quantum SIM card, which can support recharging and storing a certain number of third keys offline or online.

[0124] Here, the second platform is used to inject the ciphertext of the injection key and the card key generation data into the SIM card installed in the terminal. This second platform receives injection tasks from the first platform, either individually or in batches, and injects the first ciphertext into the key service card application of the SIM card through a filling system, thus completing the key injection. This filling system (such as a SIM card filling system) is mainly responsible for writing data into the card to complete the key injection. That is, the second platform (such as a SIM card injection platform) is responsible for generating and managing the ninth key of the SIM card, deriving the eighth key, and batch filling the injection data containing the third key into the SIM card. In one embodiment, the second platform can be an injection platform.

[0125] For the second platform, the second platform receives the first ciphertext and the first data sent by the first platform, and fills the first ciphertext and the first data into the card to be filled installed in the terminal.

[0126] The second data includes first ciphertext generated by the first platform. For the first platform, based on the second key of the card to be recharged and the first data used to generate the first key, a new first key is generated. Based on the new first key, the third key generated by the first platform is encrypted to obtain the first ciphertext. In one embodiment, the second data is recharge data.

[0127] Here, the card to be recharged is the card for which a key is to be recharged. This card is the UE's secure area and can be a SIM card, USIM card, Super SIM card, or SD card, etc.

[0128] Furthermore, the system receives the second data from the filling platform, i.e., the second platform sends the second data to the filling platform. This filling platform can perform batch filling of the cards to be filled. Correspondingly, after successfully decrypting and obtaining the third key, it can return a key filling result response to the filling platform; the filling platform returns a key filling result response to the second platform; and the second platform returns a key filling result response to the first platform.

[0129] Furthermore, the second data is encapsulated using APDU (Application Protocol Data Unit).

[0130] Step 220: If the second data also includes first data for generating the first key, a new first key is generated based on the second key of the card to be refilled and the first data.

[0131] Here, the first data is used to generate the first key, and the first data may include, but is not limited to, random data randomly generated by the first platform and a first parameter, etc.; the first parameter is an incrementing parameter. The first parameter may be a sequence number; the sequence number is incrementing.

[0132] The second key is generated based on the first identifier of the card to be recharged. Therefore, different cards have different second keys, ensuring that the first keys of different cards are also different, thereby preventing the same key from being written into multiple cards for initialization, and thus improving the security of key recharge. The first identifier is used to uniquely identify the card to be recharged. In one embodiment, the second key is the card root key (QCRK).

[0133] In one specific embodiment, a new first key is derived based on the second key and the first data. More specifically, the hash value of the first data is calculated based on the second key, and the new first key is generated based on this hash value. Further, the new first key is derived based on the second key, the first data, the first identifier, and a first string used to identify the first key. Exemplarily, the new first key is derived based on a key derivation function; for example, the formula for generating the first key is as follows: QCFKenc=KDF(QCRK,SEID,RAND,SQN,“enc”); In the formula, QCFKenc represents the first key, KDF() represents the key derivation function, QCRK represents the second key, SEID represents the first identifier, RAND represents random data, SQN represents the first parameter, and "enc" represents the first string. The new card key is used to decrypt the ciphertext of the recharge key to obtain the recharge key generated by the cryptographic service platform. Specifically, based on the new card key, the ciphertext of the recharge key is decrypted to obtain the recharge key.

[0134] The new first key is used to decrypt the first ciphertext to obtain the third key of the card to be recharged generated by the first platform.

[0135] In one specific embodiment, the first ciphertext is symmetrically decrypted based on the new first key to obtain the third key.

[0136] Here, the third key is the key that needs to be encrypted. For example, the third key is a quantum key, meaning the first platform is a quantum cryptography service platform. The first ciphertext is the encrypted third key.

[0137] The key injection method provided in this application embodiment receives second data injected by a second platform. When the second data also includes first data for generating a first key, a new first key is generated based on the second key of the card to be injected and the first data. The second key is generated based on the first identifier of the card to be injected, thereby avoiding the first key used for encryption and decryption of the third key being the same each time, thus improving the security of key injection. The second data includes first ciphertext generated by the first platform, thereby preventing the second platform from also possessing the third key, thus improving the security of the third key, i.e., improving the security of key injection. The new first key is used to decrypt the first ciphertext to obtain the third key generated by the first platform, thereby ensuring that the third key is successfully injected into the card to be injected, thereby improving the security of the business system.

[0138] Based on any of the above embodiments, in this method, the first data includes random data randomly generated by the first platform and / or a first parameter, wherein the first parameter is an incrementing parameter.

[0139] Here, the random data is randomly generated by the first platform, which increases the randomness of the first key and thus improves the security of key injection.

[0140] The first parameter is an incrementing parameter; based on this, the risk of the second platform updating the key to the old first key by replaying the old filling data is avoided, ensuring the update of the new first key, thereby improving the security of key filling.

[0141] In one embodiment, the first parameter can be a serial number; the serial number is incremented.

[0142] Considering that using the same first key for encryption with the third key could pose a security risk, the first data includes a random number. This increases the randomness of the first key, thereby improving the security of key injection. Furthermore, the first data includes a first parameter, which is an incrementing parameter. This prevents the second platform from replaying old second data, thus avoiding the risk of updating the key to an old first key and ensuring the updating of the new first key, thereby enhancing the security of key injection.

[0143] In one embodiment, a new first key is derived based on a second key and random data. More specifically, a hash value of the random data is calculated based on the second key, and a new first key is generated based on that hash value.

[0144] In another embodiment, a new first key is derived based on the second key and the first parameter. More specifically, a hash value of the first parameter is calculated based on the second key, and the new first key is generated based on that hash value.

[0145] In another embodiment, concatenated data is obtained by splicing random data and a first parameter. A new first key is derived based on a second key and the concatenated data. More specifically, a hash value of the concatenated data is calculated based on the second key, and a new first key is generated based on this hash value.

[0146] The key injection method provided in this application includes first data that includes random data, thereby increasing the randomness of the first key and improving the security of key injection; and the first data includes a first parameter, which is an incrementing parameter, avoiding the risk that the second platform might update the key to the old first key by replaying the old second data, thus ensuring the update of the new first key and improving the security of key injection.

[0147] Based on any of the above embodiments, when the first data includes the first parameter, step 220 includes: If the first parameter is greater than the locally stored second parameter, a new first key is generated based on the second key and the first data.

[0148] The second parameter is an incrementing parameter. It is a previously saved parameter. In one embodiment, the second parameter is a historical sequence number, which is a previously saved sequence number. A new first key is generated only if the first parameter is greater than the locally saved second parameter, ensuring that the first platform and the terminal synchronously generate the same first key.

[0149] Furthermore, if the first parameter is not greater than the locally stored second parameter, a new first key is not generated. Additionally, an error message is returned to the second platform.

[0150] In one specific embodiment, the security overlay stores the new first key and the first data.

[0151] The key injection method provided in this application generates a new first key only when the first parameter is greater than the locally stored second parameter. That is, by incrementing the parameter, the risk of the second platform updating the key to the old first key by replaying the old second data is avoided, ensuring that the new first key is updated, thereby improving the security of key injection; and ensuring that the first platform and the terminal generate the same first key synchronously.

[0152] Based on any of the above embodiments, the second data further includes a first message authentication code; after step 210 above, the method further includes: If the second data also includes first data for generating the first key, the first ciphertext is verified for integrity based on the fourth key of the card to be refilled using the method for generating the first message authentication code, and a first message verification code is generated. If the first message verification code matches the first message authentication code, the first ciphertext can be decrypted based on the new first key.

[0153] In one embodiment, the fourth key is the card filling integrity protection key (QCFKint).

[0154] Here, the first ciphertext is the data that requires integrity protection. A corresponding first message verification code is generated based on it, thereby achieving integrity protection for the first ciphertext. More specifically, the first message verification code is derived based on the fourth key and the first ciphertext.

[0155] In one specific embodiment, a hash value of the first ciphertext is calculated based on a fourth key, and a first message verification code is generated based on this hash value. Exemplarily, the first message verification code is calculated using an integrity calculation function.

[0156] The key injection method provided in this application embodiment utilizes the generation method of the first message authentication code to generate a first message verification code based on the first ciphertext. Only when the first message verification code matches the first message authentication code is the first ciphertext determined to be complete, thereby ensuring that the third key for terminal decryption is accurate, and thus ensuring successful decryption to obtain the third key. Finally, while ensuring successful injection of the third key, it also achieves integrity protection of the first ciphertext, thereby improving the security and accuracy of key injection.

[0157] Based on any of the above embodiments, in this method, the fourth key is generated in the following manner: The fourth key is generated based on the second key and the first data.

[0158] The second key is generated based on the first identifier. Therefore, different cards have different second keys, ensuring that different cards have different fourth keys. This prevents the same key from being written into multiple cards for initialization, thereby improving the security of key filling.

[0159] Here, the first data is used to generate the fourth key, and the first data may include, but is not limited to, random data randomly generated by the first platform and the first parameters, etc.

[0160] In one specific embodiment, a fourth key is derived based on the second key and the first data. More specifically, a hash value of the first data is calculated based on the second key, and the fourth key is generated based on this hash value. Further, the fourth key is derived based on the second key, the first data, the first identifier, and a second string used to identify the fourth key. Exemplarily, the fourth key is derived based on a key derivation function.

[0161] In one embodiment, the first data includes random data and / or a first parameter; the first parameter is an incrementing parameter. The fourth key is generated based on the first identifier, the first data, the second key, and a second string used to identify the fourth key.

[0162] For example, the formula for generating the fourth key is as follows: QCFKint=KDF(QCRK,SEID,RAND,SQN,“int”); In the formula, QCFKint represents the fourth key, KDF() represents the key derivation function, QCRK represents the second key, SEID represents the first identifier, RAND represents random data, SQN represents the first parameter, and "int" represents the second string.

[0163] It should be understood that a fourth key is generated based on the first identifier to ensure that the fourth key is different for different cards, thereby improving the accuracy of key filling; and a fourth key is generated based on the second string used to identify the fourth key, so as to identify the fourth key and distinguish it from the first key.

[0164] The key injection method provided in this application accurately generates a fourth key through the above-described manner, thereby better protecting the integrity of the first ciphertext and improving the security of key injection.

[0165] Based on any of the above embodiments, in this method, the second key is written to the card to be recharged by the third platform; the second key is generated based on the first identifier and the fifth key of the card to be recharged.

[0166] In one embodiment, the fifth key is the card vendor key (QCVK).

[0167] Here, the third platform refers to the card vendor, which is the manufacturer of the cards to be recharged. It is mainly responsible for making blank cards and can support writing card application and personalized data into the cards.

[0168] The third platform is used to generate a second key based on the fifth key and the first identifier, and to write the second key into the card to be refilled.

[0169] The key filling method provided in this application embodiment generates a fifth key on the first platform and then sends the fifth key to the third platform. The third platform can then use the fifth key and the first identifier to generate a second key and write the second key into the card to be filled, ensuring that the fifth key is also generated on the first platform, thereby improving the security of key filling.

[0170] Based on any of the above embodiments, the second data further includes a second message authentication code; after step 210 above, the method further includes: Using the method for generating the second message authentication code, based on the seventh key of the card to be recharged, the integrity of the second data is verified, and a second message verification code is generated; If the second message verification code matches the second message authentication code, determine whether the second data includes the first data.

[0171] In one embodiment, the seventh key is the recharge card key (FCK).

[0172] Here, the second data refers to the data requiring integrity protection. A corresponding second message verification code is generated based on this data to achieve integrity protection. More specifically, a second message verification code is derived based on the second data. For example, the second message verification code is calculated using an integrity calculation function.

[0173] In one specific embodiment, the hash value of the second data is calculated based on the seventh key, and a second message verification code is generated based on the hash value.

[0174] The second platform is also used to generate a second message authentication code based on the second data and send the second message authentication code to the terminal. This ensures that the third key used by the terminal for decryption is accurate, thereby ensuring successful decryption and obtaining the third key. Ultimately, while ensuring successful key injection, it also protects the integrity of the second data, thus improving the security and accuracy of key injection.

[0175] The key injection method provided in this application utilizes the generation method of the second message authentication code to generate a second message verification code based on the second data, thereby achieving integrity protection of the second data and improving the security and accuracy of key injection. If the second message verification code matches the second message authentication code, the second data is determined to be complete. Subsequent steps, i.e., decryption to obtain the third key, are only performed if the second data is complete, thereby ensuring that the third key decrypted by the terminal is accurate, and thus improving the security and accuracy of key injection.

[0176] Based on any of the above embodiments, in this method, the seventh key is written to the card to be recharged by the third platform; the seventh key is generated based on the first identifier and the eighth key of the card to be recharged; the eighth key is generated based on the second identifier of the card to be recharged.

[0177] The seventh key is generated based on the first identifier, so the seventh key is different for different cards, thereby avoiding the use of the same key for initialization in multiple cards, and thus improving the security of key filling.

[0178] In one embodiment, the eighth key is the recharge card vendor key (FVK).

[0179] The third platform is used to generate the seventh key based on the eighth key and the first identifier, and to write the seventh key into the card to be refilled.

[0180] The key filling method provided in this application embodiment generates the seventh key by a third platform, thereby eliminating the need for terminal generation and reducing terminal processing requirements; and the eighth key is generated based on the second identifier of the card to be filled, so that the eighth key is different for different card vendors, thereby improving the security of key filling.

[0181] Based on any of the above embodiments, this application also provides a key filling method applied to a second platform. Figure 3 This is the third flowchart of the key filling method provided in this application, as shown below. Figure 3 As shown, the key filling method applied to the second platform includes the following steps 310 and 320.

[0182] Step 310: Receive the first ciphertext and the first data for generating the first key sent by the first platform.

[0183] In one embodiment, the second platform is a refilling platform. The second platform (such as a SIM card refilling platform) is responsible for generating and managing the ninth key of the SIM card, deriving the eighth key, and batch filling the SIM card with refilling data containing the third key.

[0184] In one specific embodiment, the second platform receives charging tasks from the first platform in a single instance or in batches, and charges the first ciphertext into the key service card application of the card to be charged through a filling system, thus completing the key charging. This filling system (such as a SIM card filling system) is primarily responsible for writing data into the card to complete the key charging.

[0185] Wherein, the first ciphertext is obtained by encrypting the third key of the card to be recharged generated by the first platform based on the new first key; the new first key is generated based on the second key of the card to be recharged and the first data; the second key is generated based on the first identifier of the card to be recharged.

[0186] The second key is generated based on the first identifier. Therefore, different cards have different second keys, ensuring that different cards have different first keys. This prevents the same key from being written into multiple cards for initialization, thereby improving the security of key refilling. The first identifier is used to uniquely identify the card to be refilled.

[0187] In one embodiment, the second key is the QCRK key.

[0188] Here, the first data is used to generate the first key, and the first data may include, but is not limited to, random data randomly generated by the first platform and a first parameter, etc.; the first parameter is an incrementing parameter. The first parameter may be a sequence number; the sequence number is incrementing.

[0189] Considering that using the same first key to encrypt the third key each time could pose a security risk, the first data includes a random number. This increases the randomness of the third key, thereby improving the security of key injection. Furthermore, the first data includes a first parameter, which is an incrementing parameter. This prevents the second platform from replaying old injection data, thus avoiding the risk of updating the key to an old first key and ensuring the updating of the new first key, thereby enhancing the security of key injection.

[0190] Here, the third key is the key to be injected generated by the first platform, and this third key is the key that needs to be encrypted and protected. For example, the third key is a quantum key, meaning the first platform is a first-level platform for quantum cryptography services. The first ciphertext is the encrypted third key, such as the injection key ciphertext.

[0191] In one embodiment, the third key is the card base key (QCBK).

[0192] For ease of understanding, an embodiment is described here. An operator logs into the SIM card unified portal system, enters an order number, and uploads card production information. This card production information may include, but is not limited to, at least one of the following: order number, number of cards produced, address of the return file, etc. The SIM card unified portal pushes card production request information to a second platform through a secure channel to provide card production information. The second platform requests a return file from the SIM card unified portal based on the order information. The SIM card unified portal responds to the request and sends the return file to the second platform. The second platform analyzes the order information to obtain a first identifier and the number of cards produced. The second platform sends a key replenishment request to the first platform, which includes the first identifier and the number of cards produced.

[0193] Step 320: Fill the first ciphertext and the first data into the card to be filled installed on the terminal.

[0194] Here, the card to be recharged is the card for which a key is to be recharged. This card is the UE's secure area and can be a SIM card, USIM card, Super SIM card, or SD card, etc.

[0195] Here, the terminal is used to install the card to be charged, for example, the terminal is a UE. For the terminal, the terminal receives the second data charged by the second platform. The second data includes the first ciphertext generated by the first platform. If the second data also includes the first data, a new first key is generated based on the second key and the first data. The new first key is used to decrypt the first ciphertext to obtain the third key generated by the first platform.

[0196] It should be understood that the first data also needs to be injected into the card to be injected so that it can generate a new first key in the same way, and then decrypt it to obtain the third key.

[0197] The key injection method provided in this application embodiment uses a first ciphertext obtained by encrypting a third key generated by a first platform based on a new first key. This avoids the first key used to encrypt the third key being the same each time, thereby improving the security of key injection. Furthermore, the new first key is generated based on a second key and first data of the card to be injected, and the second key is generated based on a first identifier of the card to be injected. This avoids the first key being the same for different cards, further improving the security of key injection. The method receives a first ciphertext and first data used to generate the first key from the first platform, and injects the first ciphertext and first data into the card to be injected installed in the terminal. This avoids the second platform also possessing the third key, thereby improving the security of the third key, i.e., improving the security of key injection. The second platform injects the first ciphertext and first data into the card to be injected installed in the terminal, allowing the card to be injected to decrypt based on the first data to obtain the third key, ensuring successful injection of the third key into the card to be injected, thus improving the security of the business system.

[0198] Based on any of the above embodiments, after step 310, the method further includes: Based on the seventh key of the card to be recharged, the second data to be recharged to the card is protected for integrity, and a second message authentication code is generated. The second message authentication code is sent to the terminal.

[0199] In one embodiment, the seventh key is the recharge card key (FCK).

[0200] Here, the second data refers to the data requiring integrity protection. A corresponding second message authentication code is generated based on this data to achieve integrity protection. More specifically, the second message authentication code is derived from the second data. For example, the second message authentication code is calculated based on an integrity calculation function.

[0201] In one specific embodiment, a hash value of the second data is calculated based on the seventh key, and a second message authentication code is generated based on the hash value.

[0202] The seventh key is generated based on the first identifier, so the seventh key is different for different cards, thereby avoiding the use of the same key for initialization in multiple cards, and thus improving the security of key filling.

[0203] The key injection method provided in this application generates a second message authentication code based on a seventh key and second data, and sends the second message authentication code to the terminal, thereby achieving integrity protection of the second data, thus improving the security of key injection, and ensuring that the third key decrypted by the terminal is accurate, that is, ensuring successful decryption to obtain the third key, thereby improving the security and accuracy of key injection.

[0204] Based on any of the above embodiments, in this method, the seventh key is generated in the following manner: The seventh key is generated based on the eighth key and the first identifier.

[0205] In one embodiment, the eighth key is the recharge card vendor key (FVK).

[0206] The eighth key is generated based on the second identifier of the card to be refilled. Therefore, different card vendors have different eighth keys. This second identifier is used to uniquely identify the card vendor. The card vendor is the manufacturer of the cards to be refilled, primarily responsible for producing blank cards and supporting data writing to the cards.

[0207] In one specific embodiment, a seventh key is derived based on the eighth key and the first identifier. Exemplarily, the seventh key is generated based on a key derivation function; for example, the seventh key is generated in the following manner: FCK = KDF(FVK, SEID); In the formula, FCK represents the seventh key, KDF() represents the key derivation function, FVK represents the eighth key, and SEID represents the first identifier.

[0208] For example, the second platform generates a seventh key for each card to be filled based on the eighth key and the first identifier, and uses the seventh key to protect the integrity of the second data to be filled into the card, assembling it into APDU data. The second platform then sends the APDU data to the filling platform through a secure channel.

[0209] The key filling method provided in this application generates a seventh key based on an eighth key and a first identifier. The eighth key is generated based on the second identifier of the card to be filled, thereby avoiding the seventh key being the same for different cards, and thus avoiding the second message authentication code being the same for different cards, ultimately improving the security of key filling.

[0210] Based on any of the above embodiments, in this method, the eighth key is generated in the following manner: The eighth key is generated based on the ninth key of the second platform and the second identifier.

[0211] The ninth key is a key secretly stored by the second platform. In one embodiment, the ninth key is a recharge root key (FRK). This ensures the security of the generated eighth key. This ninth key can be used to derive the eighth key for each card vendor.

[0212] In one specific embodiment, an eighth key is derived based on the ninth key and the second identifier of the second platform. Exemplarily, the eighth key is generated based on a key derivation function; for example, the eighth key is generated in the following manner: FVK=KDF(FRK, VID); In the formula, FVK represents the eighth key, KDF() represents the key derivation function, FRK represents the ninth key, and VID represents the second identifier.

[0213] Furthermore, the eighth key is generated and then securely stored.

[0214] The key injection method provided in this application generates an eighth key based on the ninth key and the second identifier of the second platform. The ninth key is a key secretly stored by the second platform, thereby improving the security of the eighth key and thus improving the security of key injection.

[0215] Based on any of the above embodiments, the method further includes: After generating the eighth key, the eighth key is sent to the third platform.

[0216] The third platform is used to generate the seventh key based on the eighth key and the first identifier, and to write the seventh key into the card to be refilled.

[0217] In one embodiment, the third platform is a key management system. Further, the third platform is the platform identified by the second identifier, for example, the third platform is a card vendor platform. The card vendor referred to in the card vendor platform is the manufacturer of the cards to be recharged, which is primarily responsible for producing the cards to be recharged.

[0218] It should be understood that the seventh key is written into the card to be recharged so that it can generate a second message verification code based on the seventh key and the second data, and then determine whether the second data is complete based on the second message verification code.

[0219] Furthermore, the eighth key is sent to the third platform through a secure channel to ensure the security of the eighth key, thereby improving the security of key filling.

[0220] Furthermore, after the third platform receives the eighth key, the third platform returns the initialization result of the eighth key to the second platform offline, that is, the second platform receives the key configuration result of the recharge card merchant.

[0221] The key filling method provided in this application embodiment generates an eighth key on the second platform and then sends the eighth key to the third platform, so that the third platform can use it to generate a seventh key based on the eighth key and the first identifier, and to write the seventh key into the card to be filled, ensuring that the seventh key is also generated on the third platform, thereby improving the processing efficiency of the terminal.

[0222] Based on any of the above embodiments, in this method, sending the eighth key to the third platform includes: The eighth key is encrypted using the public key of the third platform to obtain the third ciphertext; The third ciphertext is sent to the third platform.

[0223] Here, each third platform possesses its own unique public-private key pair (digital certificate), meaning each card vendor has its own unique public-private key pair (digital certificate) used to protect confidential information during the initialization of the first platform's key processes in the preparation phase. The second platform can obtain the third platform's public key from secure channels. For example, the third platform's public key is the card vendor's digital certificate public key (VPK), which is used to encrypt and protect data such as the fifth key and the eighth key. This public key can be provided offline by the third platform.

[0224] For the third platform, based on the third platform's private key, it can decrypt the third ciphertext to obtain the eighth key, and this private key is secretly kept by the third platform, thereby improving the security of the eighth key.

[0225] The third ciphertext is the encrypted eighth key. For example, the third ciphertext is generated as follows: ECMK = Epub(VPK, FVK); In the formula, ECMK represents the third ciphertext, Epub() represents the public-key encryption algorithm, VPK represents the public key of the third platform, and FVK represents the eighth key.

[0226] The key injection method provided in this application embodiment encrypts the eighth key based on the public key of the third platform to obtain the third ciphertext, and sends the third ciphertext to the third platform so that the third platform can decrypt the third ciphertext based on its secretly stored private key, thereby improving the security of the eighth key and thus improving the security of key injection.

[0227] Based on any of the above embodiments, in this method, sending the third ciphertext to the third platform includes: The third ciphertext is digitally signed based on the private key of the second platform; The digitally signed third ciphertext is sent to the third platform.

[0228] In one embodiment, the private key of the second platform is the SIM card recharge platform private key (FSK), which corresponds to the public key of the second platform and is used to digitally sign data such as the eighth key. The public key of the second platform is used to digitally sign and verify the data such as the eighth key.

[0229] Here, the second platform possesses its own unique public-private key pair (digital certificate). The third platform can obtain the second platform's public key through secure channels.

[0230] Furthermore, the third ciphertext after digital signature is encapsulated into a key file (such as a card vendor key file), and the key file is then securely sent to a third platform offline.

[0231] For the third platform, after obtaining the third ciphertext, it performs digital signature verification on the third ciphertext based on the public key of the second platform. After successful verification, it decrypts the third ciphertext using the private key of the third platform and securely stores the eighth key.

[0232] The key filling method provided in this application embodiment digitally signs the third ciphertext based on the private key of the second platform, and sends the digitally signed third ciphertext to the third platform so that the third platform can digitally verify the third ciphertext based on the public key of the second platform, thereby improving the accuracy and security of the eighth key, and thus improving the accuracy and security of key filling.

[0233] Based on any of the above embodiments, the method further includes: Receive the first message authentication code sent by the first platform; Send the first message authentication code to the terminal.

[0234] The first message authentication code is generated by protecting the integrity of the first ciphertext based on the fourth key of the card to be recharged.

[0235] In one embodiment, the fourth key is the card filling integrity protection key (QCFKint).

[0236] Here, the first ciphertext is the data that needs integrity protection. A corresponding first message authentication code is generated based on it, thereby achieving integrity protection for the first ciphertext.

[0237] For the terminal, it needs to use the method of generating the first message authentication code to generate the first message verification code based on the first ciphertext. Only when the first message verification code matches the first message authentication code is the first ciphertext considered complete, thus ensuring that the third key decrypted by the terminal is accurate, thereby ensuring successful decryption and obtaining the third key. Ultimately, while ensuring the successful injection of the third key, the integrity of the first ciphertext is also protected, thereby improving the security and accuracy of key injection.

[0238] The key injection method provided in this application generates a first message authentication code based on a first ciphertext, thereby achieving integrity protection of the first ciphertext and improving the security of key injection; the first message authentication code is sent to a second platform, and the second platform is also used to send the first message authentication code to a terminal, thereby ensuring that the third key decrypted by the terminal is accurate, thereby improving the security and accuracy of key injection.

[0239] Based on any of the above embodiments, this application also provides a key filling method applied to a third platform. Figure 4 This is the fourth flowchart illustrating the key filling method provided in this application, as shown below. Figure 4 As shown, the key filling method applied to the third platform includes the following steps 410, 420 and 430.

[0240] Step 410: Receive the fifth key sent by the first platform.

[0241] In one embodiment, the third platform is a key management system. For example, the third platform is a card vendor platform. The card vendor, as referred to in the card vendor platform, is the manufacturer of the cards to be recharged, and is mainly responsible for producing the cards. The third platform is responsible for managing the fifth key and the eighth key, and writing these two keys into the cards to be recharged.

[0242] The fifth key is generated based on the second identifier of the card to be recharged. Therefore, different card vendors have different fifth keys. The second identifier is used to uniquely identify the card vendor. The card vendor is the manufacturer of the card to be recharged, primarily responsible for producing blank cards, and can support writing card application and personalized data onto the card. In one embodiment, the fifth key is the card vendor key (QCVK).

[0243] Furthermore, after the third platform receives the fifth key, the third platform returns the initialization result of the fifth key to the first platform, that is, the first platform receives the initialization result of the fifth key.

[0244] It should be understood that receiving the fifth key sent by the first platform ensures that the fifth key was also generated on the first platform, thereby improving the security of key filling.

[0245] Further, prior to step 410 above, the SIM unified portal obtains the order requirements and, based on these requirements, sends a card production order to the third platform via a secure channel. These order requirements may include, but are not limited to, at least one of the following: card production quantity, pre-installed content, a first identifier set (such as a SEID list), etc. Correspondingly, the third platform sends the return file to the SIM unified portal via a secure channel; the SIM unified portal then returns the return file reception result to the third platform.

[0246] Step 420: Generate a second key for the card to be recharged based on the fifth key and the first identifier of the card to be recharged.

[0247] In one specific embodiment, a second key for the card to be recharged is derived based on the fifth key and the first identifier. Exemplarily, the second key is generated based on a key derivation function; for example, the second key is generated in the following manner: QCRK = KDF(QCVK, SEID); In the formula, QCRK represents the second key, KDF() represents the key derivation function, QCVK represents the fifth key, and SEID represents the first identifier.

[0248] It should be understood that a second key is generated based on the fifth key and the first identifier of the card to be recharged, and the fifth key is generated based on the second identifier of the card to be recharged, thereby avoiding the second key of different cards being the same, and thus avoiding the first key of different cards being the same, ultimately improving the security of key recharge.

[0249] Step 430: Write the second key into the card to be refilled.

[0250] It should be understood that the second key is written into the card to be recharged so that it can generate a new first key based on the second key of the card to be recharged and the first data, and then the first ciphertext can be decrypted based on the new first key.

[0251] The terminal installed on the card to be recharged is used to generate a new first key based on the second key and the first data used to generate the first key; the new first key is used to decrypt the first ciphertext recharged by the second platform to obtain the third key of the card to be recharged generated by the first platform.

[0252] Here, the first data is used to generate the first key, and the first data may include, but is not limited to, random data randomly generated by the first platform and a first parameter, etc.; the first parameter is an incrementing parameter. The first parameter may be a sequence number; the sequence number is incrementing.

[0253] Here, the third key is the key to be injected generated by the first platform, and this third key is the key that needs to be encrypted and protected. For example, the third key is a quantum key, meaning the first platform is a first-level platform for quantum cryptography services. The first ciphertext is the encrypted third key, such as the injection key ciphertext.

[0254] Furthermore, the third platform writes the card application and the second key in batches to the cards to be recharged. For example, the third platform writes the card application, the first identifier, the second key, the seventh key, and the first parameter to the cards to be recharged, wherein the initial value of the first parameter is 0.

[0255] The key injection method provided in this application embodiment involves a terminal installed on the card to be injected generating a new first key based on a second key and first data used to generate the first key. This avoids the first key being the same for each encryption and decryption of the third key, thereby improving the security of key injection. Furthermore, a second key for the card to be injected is generated based on a fifth key and a first identifier, preventing different cards from having the same first key, thus improving the security of key injection. The new first key is used to decrypt the first ciphertext injected by the second platform to obtain the third key generated by the first platform, preventing the second platform from also possessing the third key, thereby improving the security of the third key, i.e., improving the security of key injection. Finally, the new first key is used to decrypt the first ciphertext to obtain the third key generated by the first platform, ensuring that the third key is successfully injected into the card to be injected, thereby improving the security of the business system.

[0256] Based on any of the above embodiments, in this method, step 410 includes: Receive the second encrypted message sent by the first platform; Based on the private key of the third platform, the second ciphertext is decrypted to obtain the fifth key.

[0257] Here, each third platform possesses its own unique public-private key pair (digital certificate), meaning each card vendor has its own unique public-private key pair (digital certificate) used to protect confidential information during the initialization of the first platform's related key processes in the preparation phase. The first platform can obtain the third platform's public key from secure channels. For example, the third platform's public key is the card vendor's digital certificate public key (VPK), which is used to encrypt and protect data such as the fifth key and the eighth key. This public key can be provided offline by the third platform.

[0258] For the first platform, the fifth key is encrypted based on the public key of the third platform to obtain the second ciphertext; the second ciphertext is then sent to the third platform.

[0259] The private key is secretly stored by the third platform, thereby improving the security of the fifth key.

[0260] For example, the fifth key is generated in the following manner: QCVK = Dpub(FSK, EMK); In the formula, QCVK represents the fifth key, Dpub() represents the private key decryption algorithm, FSK represents the private key of the third platform, and EMK represents the second ciphertext.

[0261] The key injection method provided in this application embodiment receives a second ciphertext sent by a first platform, decrypts the second ciphertext based on the private key of a third platform, and obtains a fifth key, thereby improving the security of the fifth key and thus improving the security of key injection.

[0262] Based on any of the above embodiments, in this method, the step of decrypting the second ciphertext based on the private key of the third platform to obtain the fifth key includes: Based on the public key of the first platform, the second ciphertext is digitally signed and verified. If the signature verification is successful, the second ciphertext is decrypted based on the private key of the third platform to obtain the fifth key.

[0263] In one embodiment, the private key of the first platform is the quantum cryptography service level one platform private key (QSSK), which corresponds to the public key of the quantum cryptography service level one platform digital certificate (QSPK), and is used to digitally sign the fifth key, etc. The public key of the first platform is used to digitally sign and verify the data such as the fifth key.

[0264] Here, the first platform possesses its own unique public-private key pair (digital certificate). The third platform can obtain the first platform's public key through secure channels.

[0265] Furthermore, the fifth key is securely stored.

[0266] The key filling method provided in this application embodiment uses the public key of the first platform to digitally verify the second ciphertext, thereby improving the accuracy and security of the fifth key, and thus improving the accuracy and security of key filling.

[0267] Based on any of the above embodiments, the method further includes: Receive the eighth key sent by the second platform; Based on the eighth key and the first identifier, a seventh key is generated; Write the seventh key into the card to be refilled.

[0268] In one embodiment, the eighth key is the recharge card vendor key (FVK).

[0269] It should be understood that receiving the eighth key sent by the second platform ensures that the eighth key was also generated on the second platform, thereby improving the security of key filling.

[0270] Furthermore, after the third platform receives the eighth key, the third platform returns the initialization result of the eighth key to the second platform, that is, the second platform receives the initialization result.

[0271] The eighth key is generated based on the second identifier. Therefore, different card vendors use different eighth keys. This prevents different cards from having the same seventh key, and consequently prevents different cards from having the same second message authentication code, ultimately improving the security of key filling.

[0272] In one embodiment, the seventh key is the recharge card key (FCK).

[0273] In one specific embodiment, a seventh key is derived based on the eighth key and the first identifier. Exemplarily, the seventh key is generated based on a key derivation function; for example, the seventh key is generated in the following manner: FCK = KDF(FVK, SEID); In the formula, FCK represents the seventh key, KDF() represents the key derivation function, FVK represents the eighth key, and SEID represents the first identifier.

[0274] It should be understood that the seventh key is written into the card to be recharged so that it can generate a second message verification code based on the seventh key and the second data, and then determine whether the second data is complete based on the second message verification code.

[0275] The terminal is used to perform integrity verification on the second data injected into the card to be injected based on the seventh key, and generate a second message verification code.

[0276] The key filling method provided in this application embodiment generates the seventh key by a third platform, thereby eliminating the need for terminal generation and reducing terminal processing requirements; and the eighth key is generated based on the second identifier of the card to be filled, so that the eighth key is different for different card vendors, thereby improving the security of key filling.

[0277] Based on any of the above embodiments, in this method, receiving the eighth key sent by the second platform includes: Receive the third ciphertext sent by the second platform; Based on the private key of the third platform, the third ciphertext is decrypted to obtain the eighth key.

[0278] Here, each third platform possesses its own unique public-private key pair (digital certificate), meaning each card vendor has its own unique public-private key pair (digital certificate) used to protect confidential information during the initialization of the first platform's key processes in the preparation phase. The second platform can obtain the third platform's public key from secure channels. For example, the third platform's public key is the card vendor's digital certificate public key (VPK), which is used to encrypt and protect data such as the fifth key and the eighth key. This public key can be provided offline by the third platform.

[0279] For the second platform, the eighth key is encrypted based on the public key of the third platform to obtain the third ciphertext, which is then sent to the third platform.

[0280] The private key is secretly stored by a third platform, thereby improving the security of the eighth key.

[0281] For example, the eighth key is generated in the following manner: FVK=Dpub(FSK, ECMK); In the formula, FVK represents the eighth key, Dpub() represents the private key decryption algorithm, FSK represents the private key of the third platform, and ECMK represents the third ciphertext.

[0282] The key injection method provided in this application embodiment receives a third ciphertext sent by a second platform, decrypts the third ciphertext based on the private key of the third platform, and obtains an eighth key, thereby improving the security of the eighth key and thus improving the security of key injection.

[0283] Based on any of the above embodiments, in this method, the step of decrypting the third ciphertext based on the private key of the third platform to obtain the eighth key includes: Based on the public key of the second platform, the third ciphertext is digitally signed and verified. If the signature verification is successful, the third ciphertext is decrypted using the private key of the third platform to obtain the eighth key. In one embodiment, the private key of the second platform is the SIM card recharge platform private key (FSK), which corresponds to the public key of the second platform and is used to digitally sign data such as the eighth key. The public key of the second platform is used to digitally sign and verify the data such as the eighth key.

[0284] Here, the second platform possesses its own unique public-private key pair (digital certificate). The third platform can obtain the second platform's public key through secure channels.

[0285] The key injection method provided in this application embodiment uses the public key of the second platform to digitally sign and verify the third ciphertext, thereby improving the accuracy and security of determining the eighth key, and thus improving the accuracy and security of key injection.

[0286] To facilitate understanding of the above embodiments, a specific embodiment will be described here. For example... Figure 5 As shown, the key filling system includes a key management system (third platform) (not shown), a quantum SIM card (card to be filled), a SIM card filling system, a unified SIM card portal, a SIM card filling platform (second platform), and a quantum cryptography service primary platform (first platform).

[0287] The cryptographic service platform's relevant keys are shown below: The quantum cryptography service primary platform root key (QSRK) is generated and managed by the quantum cryptography service primary platform and is used to derive the quantum SIM card vendor key QCVK. Quantum SIM Card Vendor Key (QCVK): Derived by the Quantum Cryptography Service Level 1 Platform based on the Quantum Cryptography Service Level 1 Platform Root Key (QSRK) + Vendor ID (VID), and distributed to the vendors for use in deriving the Quantum SIM Card Root Key QCRK; The quantum SIM card root key (QCRK) is derived by the quantum cryptography service platform and key management system based on the quantum SIM card vendor key + SEID. It is used to derive the quantum SIM card recharge protection key, including QCFKenc and QCFKint. The quantum SIM card charging encryption key (QCFKenc) is derived by the quantum cryptography service platform and card application based on the quantum SIM card root key + SEID + RAND + SQN + "enc". It is used to encrypt and protect the quantum SIM card's basic key during the offline quantum key charging process. Quantum SIM Card Recharge Integrity Protection Key (QCFKint): Derived by the quantum cryptography service primary platform and card application based on the quantum SIM card root key + SEID + RAND + SQN + "int", it is used to protect the integrity of the quantum SIM card's basic key during the offline quantum key recharge process; The quantum SIM card base key (QCBK) is generated by the quantum cryptography service platform, protected by QCFKenc and QCFKint, and then offline injected into the quantum SIM card through the SIM card filling system. Quantum Cryptography Service Level 1 Platform Digital Certificate Public Key (QSPK): The digital certificate public key is used to digitally sign and verify data information such as QCVK; The first-level platform private key (QSSK) of quantum cryptography services is the private key corresponding to the QSPK and is used to digitally sign data information such as QCVK.

[0288] The relevant keys for the recharge platform are as follows: SIM Card Recharge Root Key (FRK): Generated and managed by the SIM Card Recharge Platform (CFP), used to derive the SIM card recharge vendor key FVK; SIM card recharge vendor key (FVK): Derived by CFP based on FRK + vendor ID and distributed to vendors for use in deriving the SIM card recharge key FCK; SIM card recharge key (FCK): Generated by the SIM card recharge platform and key management system, derived from FVK+SEID, and used to protect the integrity of the recharged data. SIM card recharge platform digital certificate public key (FPK): The digital certificate public key is used to digitally sign and verify data information such as FVK; SIM card recharge platform private key (FSK): The private key corresponding to FPK, used to digitally sign data information such as FVK.

[0289] like Figure 5 As shown, the complete key filling process is as follows.

[0290] 1. The operator logs into the unified SIM card portal, enters the order number, and uploads the card production information, including: order number, number of cards produced, and disk backup file address, etc. 2. The unified SIM card portal sends a card production request message to the SIM card recharge platform through a secure channel, providing card production information; 3. The SIM card recharge platform sends an SFTP request for a return file to the unified SIM card portal based on the order information; 4. The unified SIM card portal responds to the request and sends the return file to the SIM card recharge platform; 5. The SIM card recharge platform analyzes the card production files to obtain the SEID and the number of cards produced; 6. The SIM card recharge platform sends a key recharge request to the quantum cryptography service primary platform. The request message includes information such as the number of cards produced, card vendor ID, SEID list of SIM cards to be recharged, number of keys to be recharged for each card, and key grouping rules. 7. Quantum cryptography service primary platform generates keys: a) The quantum cryptography service platform generates QCRK based on QCVK and SEID, where QCRK = KDF(QCVK, SEID); b) Generate QCFKenc and QCFKint as needed; c) Generate and securely protect the QCBK based on the filling request (key filling request); 8. The quantum cryptography service platform returns a key recharge response to the SIM card recharge platform. The key recharge response message includes: the QCBK encryption value and QCBK integrity digest value of the specified number of QCBKs generated. If the QCFKenc and QCFKint of a certain card need to be updated, the key recharge response message should also include the RAND and SQN corresponding to the card. 9. The SIM card recharge platform is based on FVK and SEID to derive FCK, where FCK = KDF(FVK, SEID). The FCK is used to protect the integrity of the QCBK ciphertext and assemble it into APDU data. 10. The SIM card filling platform sends the APDU data to the SIM card filling system through a secure channel; 11. The SIM card filling system fills the quantum SIM cards with APDU data in batches; 12. The quantum SIM card undergoes the following processing: a) Perform integrity verification on the received data based on FCK; b) After successful integrity verification, generate QCFKint and QCFKenc as needed; c) Perform integrity verification and decryption on the QCBK ciphertext to obtain QCBK.

[0291] Based on the above embodiments, the first platform is the only entity possessing all the keys. Neither the third nor the second platform can obtain the third key, thus achieving dual separation management of card access permissions (second platform) and key management permissions (first platform), improving the security of the key imprinting process. Furthermore, during the key imprinting process, the third key is generated and securely encapsulated by the first platform and written to the card by the second platform. Third parties cannot obtain the plaintext key, which helps protect and enhance the security of the third key. Furthermore, the first platform can update the first key at any time according to security policy requirements, preventing security risks that may arise from the long-term use of the first key, which helps protect and enhance the security of the third key.

[0292] The key filling device provided in this application is described below. The key filling device described below can be referred to in correspondence with the key filling method described above.

[0293] Figure 6This is one of the structural schematic diagrams of the key filling device provided in this application, such as... Figure 6 As shown, the key filling device deployed on the first platform includes a request receiving module 610, a first generation module 620, a key encryption module 630, and a ciphertext sending module 640.

[0294] The request receiving module 610 is used to receive a key charging request; the key charging request is used to request the charging of a third key for the card to be charged, and the key charging request includes the first identifier of the card to be charged.

[0295] The first generation module 620 is used to generate a new first key based on the second key of the card to be refilled and the first data used to generate the first key when a new first key needs to be generated; the second key is generated based on the first identifier.

[0296] The key encryption module 630 is used to encrypt the third key of the card to be recharged generated by the first platform based on the new first key to obtain the first ciphertext.

[0297] The ciphertext sending module 640 is used to send the first ciphertext and the first data to the second platform.

[0298] Figure 7 This is the second schematic diagram of the key filling device provided in this application, as shown below. Figure 7 As shown, the key filling device deployed on a terminal with a card to be filled includes a first receiving module 710 and a second generating module 720.

[0299] The first receiving module 710 is used to receive the second data charged by the second platform; the second data includes the first ciphertext generated by the first platform.

[0300] The second generation module 720 is used to generate a new first key based on the second key of the card to be recharged and the first data, when the second data further includes first data for generating the first key; the second key is generated based on the first identifier of the card to be recharged.

[0301] The new first key is used to decrypt the first ciphertext to obtain the third key of the card to be recharged generated by the first platform.

[0302] Figure 8 This is the third schematic diagram of the key filling device provided in this application, as shown below. Figure 8 As shown, the key filling device deployed on the second platform includes a second receiving module 810 and a data filling module 820.

[0303] The second receiving module 810 is used to receive the first ciphertext sent by the first platform and the first data used to generate the first key.

[0304] The data filling module 820 is used to fill the first ciphertext and the first data into the card to be filled installed in the terminal.

[0305] Wherein, the first ciphertext is obtained by encrypting the third key of the card to be recharged generated by the first platform based on the new first key; the new first key is generated based on the second key of the card to be recharged and the first data; the second key is generated based on the first identifier of the card to be recharged.

[0306] Figure 9 This is the fourth schematic diagram of the key filling device provided in this application, as shown below. Figure 9 As shown, the key filling device deployed on the third platform includes a third receiving module 910, a third generating module 920, and a key writing module 930.

[0307] The third receiving module 910 is used to receive the fifth key sent by the first platform.

[0308] The third generation module 920 is used to generate a second key for the card to be recharged based on the fifth key and the first identifier of the card to be recharged.

[0309] The key writing module 930 is used to write the second key into the card to be refilled.

[0310] The fifth key is generated based on the second identifier of the card to be recharged; the terminal installed on the card to be recharged is used to generate a new first key based on the second key and the first data used to generate the first key; the new first key is used to decrypt the first ciphertext recharged by the second platform to obtain the third key of the card to be recharged generated by the first platform.

[0311] Figure 10 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 10 As shown, the electronic device may include a processor 1010, a communications interface 1020, a memory 1030, and a communication bus 1040, wherein the processor 1010, the communications interface 1020, and the memory 1030 communicate with each other via the communication bus 1040. The processor 1010 may call logical instructions in the memory 1030 to execute the key filling method of any of the above embodiments.

[0312] Furthermore, the logical instructions in the aforementioned memory 1030 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0313] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to execute the key injection method provided by the above methods.

[0314] In another aspect, this application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the key injection methods provided by the above methods.

[0315] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0316] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0317] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method of key loading, characterized by, The key charging method applied to the first platform comprises: receiving a key charging request; the key charging request is used to request charging a third key for a to-be-charged card, and the key charging request comprises a first identifier of the to-be-charged card; in the case where a new first key needs to be generated, generating a new first key based on a second key of the to-be-charged card and first data used to generate the first key; the second key is generated based on the first identifier; encrypting the third key of the to-be-charged card generated by the first platform based on the new first key to obtain first ciphertext; sending the first ciphertext and the first data to a second platform.

2. The key loading method of claim 1, wherein, The first data comprises random data and / or a first parameter; the first parameter is an incremental parameter.

3. The key loading method of claim 2, wherein, The new first key is generated based on the first identifier, the second key, the first data and a first string used to identify the first key.

4. The key loading method of claim 1, wherein, After the step of encrypting the third key of the to-be-charged card generated by the first platform based on the new first key to obtain first ciphertext, the method further comprises performing integrity protection on the first ciphertext based on a fourth key of the to-be-charged card to generate a first message authentication code; sending the first message authentication code to the second platform.

5. The key loading method of claim 4, wherein, The fourth key is generated based on the following manner: generating the fourth key based on the second key and the first data.

6. The key loading method of claim 5, wherein, The first data comprises random data and / or a first parameter; the first parameter is an incremental parameter; The fourth key is generated based on the first identifier, the first data, the second key and a second string used to identify the fourth key.

7. The key loading method according to any one of claims 1 to 6, wherein, The second key is generated based on the following manner: generating the second key based on a fifth key of the to-be-charged card and the first identifier; wherein the fifth key is generated based on a second identifier of the to-be-charged card.

8. The key loading method of claim 7, wherein, The method further comprises: after generating the fifth key, sending the fifth key to a third platform; wherein the third platform is used to generate the second key based on the fifth key and the first identifier, and is used to write the second key into the to-be-charged card.

9. The key loading method of claim 8, wherein, The step of sending the fifth key to the third platform comprises: encrypting the fifth key based on a public key of the third platform to obtain second ciphertext; sending the second ciphertext to the third platform.

10. The key loading method of claim 9, wherein, The step of sending the second ciphertext to the third platform comprises: digitally signing the second ciphertext based on a private key of the first platform; sending the second ciphertext after digital signature to the third platform.

11. The key loading method of claim 7, wherein, The fifth key is generated based on the following manner: generating the fifth key based on a sixth key of the first platform and the second identifier; wherein the sixth key is a key secretly kept by the first platform.

12. A method of key loading, characterized by, The key charging method applied to a terminal in which a to-be-charged card is installed comprises: receiving second data charged by a second platform; the second data comprises first ciphertext generated by a first platform; In a case where the second data further comprises first data used for generating the first key, a new first key is generated based on the second key of the card to be refilled and the first data; the second key is generated based on the first identification of the card to be refilled; The new first key is used to decrypt the first ciphertext to obtain the third key of the card to be refilled generated by the first platform.

13. The key infusion method of claim 12, wherein, The first data comprises random data randomly generated by the first platform and / or a first parameter, and the first parameter is an incremental parameter.

14. The key loading method of claim 13, wherein, In a case where the first data comprises the first parameter, the generation of the new first key based on the second key of the card to be refilled and the first data comprises: In a case where the first parameter is greater than a locally saved second parameter, the new first key is generated based on the second key and the first data; the second parameter is an incremental parameter.

15. The key loading method of claim 12, wherein, The second data further comprises a first message authentication code; After receiving the second data refilled by the second platform, the method further comprises: In a case where the second data further comprises first data used for generating the first key, the first ciphertext is integrity-verified based on a fourth key of the card to be refilled by using a generation mode of the first message authentication code to generate a first message authentication code; In a case where the first message authentication code matches the first message authentication code, the first ciphertext is allowed to be decrypted based on the new first key.

16. The key loading method of claim 15, wherein, The fourth key is generated based on the second key and the first data. The first data comprises random data and / or a first parameter; and the first parameter is an incremental parameter.

17. The key loading method of claim 16, wherein, The fourth key is generated based on the first identification, the first data, the second key and a second string used for identifying the fourth key. The second key is written into the card to be refilled by a third platform; 18. The key provisioning method of any of claims 12-17, wherein, The second key is generated based on the first identification and a fifth key of the card to be refilled. The second data further comprises a second message authentication code; 19. The key provisioning method of any one of claims 12-17, wherein, After receiving the second data refilled by the second platform, the method further comprises: The second data is integrity-verified based on a seventh key of the card to be refilled by using a generation mode of the second message authentication code to generate a second message authentication code; In a case where the second message authentication code matches the second message authentication code, it is determined whether the second data comprises the first data. The seventh key is written into the card to be refilled by a third platform; 20. The key loading method of claim 19, wherein, The seventh key is generated based on the first identification and an eighth key of the card to be refilled; and the eighth key is generated based on a second identification of the card to be refilled. The key refilling method is applied to a second platform, and the method comprises:

21. A method of key loading, the method comprising: Receiving a first ciphertext and first data used for generating a first key sent by a first platform; Refilling the first ciphertext and the first data to a card to be refilled installed in a terminal; ​ The first ciphertext is obtained by encrypting the third key of the card to be topped up generated by the first platform based on a new first key; the new first key is generated based on a second key of the card to be topped up and the first data; and the second key is generated based on a first identifier of the card to be topped up.

22. The key loading method of claim 21, wherein, After receiving the first ciphertext and the first data for generating the first key sent by the first platform, the method further comprises: performing integrity protection on second data to be topped up to the card to be topped up based on a seventh key of the card to be topped up, to generate a second message authentication code; the seventh key is generated based on the first identifier; sending the second message authentication code to the terminal.

23. The key loading method of claim 22, wherein, The seventh key is generated based on the following manner: generating the seventh key based on an eighth key and the first identifier; wherein the eighth key is generated based on a second identifier of the card to be topped up.

24. The key loading method of claim 23, wherein, The eighth key is generated based on the following manner: generating the eighth key based on a ninth key of the second platform and the second identifier; wherein the ninth key is a secret key of the second platform.

25. The key loading method of claim 23, wherein, The method further comprises: after generating the eighth key, sending the eighth key to a third platform; wherein the third platform is configured to generate the seventh key based on the eighth key and the first identifier, and to write the seventh key into the card to be topped up.

26. The key loading method of claim 25, wherein, The sending of the eighth key to the third platform comprises: encrypting the eighth key based on a public key of the third platform to obtain a third ciphertext; sending the third ciphertext to the third platform.

27. The key loading method of claim 26, wherein, The sending of the third ciphertext to the third platform comprises: digitally signing the third ciphertext based on a private key of the second platform; sending the third ciphertext after digital signature to the third platform.

28. The key provisioning method of any of claims 21-27, wherein, The method further comprises: receiving a first message authentication code sent by the first platform; the first message authentication code is generated based on integrity protection of the first ciphertext by a fourth key of the card to be topped up; sending the first message authentication code to the terminal.

29. A method of key loading, the method comprising: The key topping-up method applied to the third platform comprises: receiving a fifth key sent by the first platform; generating a second key of the card to be topped up based on the fifth key and a first identifier of the card to be topped up; writing the second key into the card to be topped up; wherein the fifth key is generated based on a second identifier of the card to be topped up; a terminal installed with the card to be topped up is configured to generate a new first key based on the second key and first data for generating the first key; and the new first key is used to decrypt a first ciphertext topped up by the second platform to obtain the third key of the card to be topped up generated by the first platform.

30. The key loading method of claim 29, wherein, The receiving of the fifth key sent by the first platform comprises: receiving a second ciphertext sent by the first platform; decrypting the second ciphertext based on a private key of the third platform to obtain the fifth key.

31. The key loading method of claim 30, wherein, The decrypting of the second ciphertext based on the private key of the third platform to obtain the fifth key comprises: digitally signing and verifying the second ciphertext based on a public key of the first platform; In case of signature verification passing, the second ciphertext is decrypted based on the private key of the third platform to obtain a fifth key.

32. The key provisioning method of any of claims 29-31, wherein, Further comprising: receiving the eighth key sent by the second platform; generating a seventh key based on the eighth key and the first identifier; writing the seventh key into the card to be refilled; wherein the eighth key is generated based on the second identifier; and the terminal is configured to perform integrity verification on second data refilled to the card to be refilled based on the seventh key, and generate a second message authentication code.

33. The key loading method of claim 32, wherein, The receiving the eighth key sent by the second platform comprises: receiving third ciphertext sent by the second platform; decrypting the third ciphertext based on the private key of the third platform to obtain the eighth key.

34. The key loading method of claim 33, wherein, The decrypting the third ciphertext based on the private key of the third platform to obtain the eighth key comprises: performing digital signature verification on the third ciphertext based on the public key of the second platform; in case of signature verification passing, decrypting the third ciphertext based on the private key of the third platform to obtain the eighth key.

35. A key loading device, comprising: The key refilling device is deployed on the first platform, and comprises: a request receiving module configured to receive a key refilling request; the key refilling request is configured to request to refill a third key for a card to be refilled, and the key refilling request comprises a first identifier of the card to be refilled; a first generating module configured to, in case of needing to generate a new first key, generate the new first key based on a second key of the card to be refilled and first data used to generate the first key; the second key is generated based on the first identifier; a key encrypting module configured to encrypt the third key of the card to be refilled generated by the first platform based on the new first key to obtain first ciphertext; a ciphertext sending module configured to send the first ciphertext and the first data to a second platform.

36. A key loading device, comprising: The key refilling device is deployed on a terminal on which the card to be refilled is installed, and comprises: a first receiving module configured to receive second data refilled by the second platform; the second data comprises first ciphertext generated by the first platform; a second generating module configured to, in case that the second data further comprises the first data used to generate the first key, generate a new first key based on a second key of the card to be refilled and the first data; the second key is generated based on a first identifier of the card to be refilled; wherein the new first key is used to decrypt the first ciphertext to obtain the third key of the card to be refilled generated by the first platform.

37. A key loading device, comprising: The key refilling device is deployed on the second platform, and comprises: a second receiving module configured to receive first ciphertext and first data used to generate a first key sent by the first platform; a data refilling module configured to refill the first ciphertext and the first data to a card to be refilled installed on a terminal; wherein the first ciphertext is obtained by encrypting the third key of the card to be refilled generated by the first platform based on a new first key; the new first key is generated based on a second key of the card to be refilled and the first data; and the second key is generated based on a first identifier of the card to be refilled.

38. A key loading device, comprising: The key charging device is deployed on a third platform, and the key charging device comprises: a third receiving module configured to receive a fifth key sent by the first platform; a third generating module configured to generate a second key of the card to be charged based on the fifth key and a first identifier of the card to be charged; a key writing module configured to write the second key into the card to be charged; wherein the fifth key is generated based on a second identifier of the card to be charged; a terminal installed with the card to be charged is configured to generate a new first key based on the second key and first data used to generate the first key; and the new first key is used to decrypt a first ciphertext charged by a second platform to obtain a third key of the card to be charged generated by the first platform.

39. An electronic device comprising a memory, a processor, and a computer program stored on the memory and running on the processor, wherein, The processor executes the computer program to implement the key charging method according to any one of claims 1 to 34.

40. A non-transitory computer-readable storage medium having stored thereon a computer program, wherein, The computer program is executed by the processor to implement the key charging method according to any one of claims 1 to 34.

41. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the key charging method according to any one of claims 1 to 34. The computer program is executed by the processor to implement the key charging method according to any one of claims 1 to 34.

Images