A method and system for implementing key delivery
By using key management methods for Android devices and background service systems, the problems of untimely key distribution and insufficient security are solved, enabling high-concurrency and dynamically updated key distribution, and improving the security and response speed of key distribution.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- FEITIAN TECHNOLOGIES CO LTD
- Filing Date
- 2026-01-14
- Publication Date
- 2026-05-12
AI Technical Summary
The existing key distribution and update mechanism has problems such as untimely distribution, lack of key pool management, inability to achieve high concurrency, and inability to achieve random or policy-based allocation, dynamic updates and notifications, which leads to abnormal device communication.
It uses Android devices and a backend service system, and works in collaboration with the SDK and cryptographic machine to generate and manage key pairs. It uses a cache pool to back up keys, realizes dynamic updates and high-concurrency key distribution, and ensures the security and timeliness of keys.
It improves the security and response speed of key distribution, reduces latency, supports dynamic updates and key requests in high-concurrency scenarios, and enhances the security of data transmission.
Smart Images
Figure CN121547175B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of information security, and in particular to a method and system for key distribution. Background Technology
[0002] With technological advancements and the development of the computer industry, users are increasingly concerned about the security of their personal information, thus encrypting it with keys before transmission. However, the keys used in encryption are typically fixed and relatively simple, lacking sufficient security. Therefore, key updates are necessary. Traditional key distribution and update mechanisms often rely on scheduled tasks, manual updates, or static key files, which have the following problems: untimely distribution, leading to communication failures; lack of key pool management, unable to meet the high concurrency of key requests from a large number of devices; inability to implement random or policy-based key allocation, resulting in predictable risks; and lack of support for dynamic updates and notifications, especially failing to notify devices immediately when keys are about to expire or be revoked. Therefore, there is an urgent need for a flexible and secure key distribution solution. Summary of the Invention
[0003] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method and system for key distribution.
[0004] In a first aspect, embodiments of the present invention provide a method for key distribution, applicable to a system including an Android device and a background service, wherein an application is installed on the Android device, the application has a built-in SDK, and the method includes the workflow of the background service and the workflow of the SDK, the workflow of the SDK including:
[0005] Step S1: When the application calls the key generation interface of the SDK, a first key pair is generated and saved, and the first public key in the first key pair is uploaded to the background service.
[0006] Step S2: When the SDK receives the first certificate returned by the backend service, it saves the first certificate, generates a key acquisition request according to the first preset number, and sends it to the backend service;
[0007] Step S3: When the SDK receives the second ciphertext of TPK, the first signature result, the second ciphertext of DEK, the second signature result, the index value, and the second certificate, it uses the second ciphertext of TPK and the second certificate, and the second ciphertext of DEK and the second certificate to verify the first signature result and the second signature result. If the verification is successful, the first private key in the first key pair is used to decrypt the second ciphertext of TPK and the second ciphertext of DEK to obtain TPK and DEK respectively, and the TPK and DEK and the corresponding index value are saved. If the verification fails, an error is reported.
[0008] The workflow of the backend service includes:
[0009] Step T1: When the background service receives the first public key sent by the SDK, it generates a first certificate based on the first public key and returns it to the SDK. It generates a second certificate based on the second public key in the generated second key pair and saves it. Based on the first public key, the first certificate, the second private key in the second key pair, and the second certificate, it uses the built-in cryptographic machine to generate a second preset number of TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, and second signature result, and saves them in the database with the corresponding index values and the number of times they can be used. It backs up all the TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, second signature result, and corresponding index values in the database to the cache pool.
[0010] Step T2: When the background service receives the key acquisition request sent by the SDK, it retrieves the corresponding number of TPK second ciphertext, first signature result, DEK second ciphertext, second signature result and corresponding index value from the cache pool according to the number of keys required in the key acquisition request, and returns them to the SDK together with the second certificate.
[0011] Secondly, embodiments of the present invention provide a key distribution implementation system, including an SDK and a background service. The SDK is set in an application of an Android device, and the background service contains a cryptographic machine. The SDK and the background service work together to implement the aforementioned method.
[0012] Thirdly, embodiments of the present invention provide an electronic device, the electronic device including at least one processor, a memory, and instructions stored in the memory and executable by the at least one processor, the at least one processor executing the instructions to implement the aforementioned method.
[0013] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, the computer-readable storage medium including a computer program, which, when run on an electronic device, causes the electronic device to perform the aforementioned method.
[0014] Fifthly, embodiments of the present invention provide a chip system including a chip coupled to a memory for executing a computer program stored in the memory to perform the aforementioned method.
[0015] Compared with the prior art, the present invention has the following advantages: The background service of the present invention uses a cryptographic machine to encrypt the first ciphertext of the terminal PIN key (TPK) and the first ciphertext of the data encryption key (DEK) obtained by encrypting the first random number and the second random number using an LMK (Local Master Key), and uses a first public key to encrypt the second ciphertext of the TPK and the second ciphertext of the DEK obtained by encrypting the first random number and the second random number, respectively. These are stored in the database with corresponding index values. According to the number of times they can be used, the first ciphertext of the TPK, the second ciphertext of the TPK, the first ciphertext of the DEK, the second ciphertext of the DEK, and the corresponding index values in the database are backed up to the cache pool (Redis). Part of the second ciphertext of the TPK, the second ciphertext of the DEK, and the corresponding index values are sent to the SDK (Software Development Kit). The SDK decrypts the received second ciphertext of the TPK and the second ciphertext of the DEK to obtain the TPK and DEK and saves them with the corresponding index values. Both TPK and DEK are stored in encrypted form in the background service, and the encryption and decryption processes are performed in the cryptographic machine, which can improve the security of keys and user data. Using a cache pool to back up multiple sets of TPK first ciphertext, TPK second ciphertext, DEK first ciphertext, DEK second ciphertext, and index value can improve the key issuance response speed in high-concurrency scenarios and reduce key issuance delay. Attached Figure Description
[0016] Figure 1 and Figure 2 A flowchart illustrating a key distribution method provided in Embodiment 1 of the present invention;
[0017] Figure 3 A flowchart illustrating a key distribution method provided in Embodiment 2 of the present invention;
[0018] Figure 4 This is a flowchart of a key usage process provided in Embodiment 2 of the present invention. Detailed Implementation
[0019] This application proposes a method and system for key distribution. The specific implementation methods of this application will be described in detail below with reference to the accompanying drawings. Examples of the embodiments are shown in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.
[0020] Those skilled in the art will understand that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.
[0021] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings. Example 1
[0022] Embodiment 1 of this invention provides a method for key distribution, applicable to systems including Android devices and background services. The Android device has an application installed, the application has a built-in SDK, and the background service has a built-in cryptographic machine. This embodiment's method includes: the background service's workflow and the SDK's workflow. The SDK's workflow is as follows: Figure 1 As shown, it includes:
[0023] Step S1: When the SDK's key generation interface is called by the application, the first key pair is generated and saved, and the first public key in the first key pair is uploaded to the background service.
[0024] Optionally, in this embodiment, the process further includes the following steps before generating the first key pair:
[0025] Step Y1: When the SDK's key generation interface is called by the application, a verification request is sent to the background service;
[0026] The verification request includes the device serial number and device license;
[0027] Step Y2: The background service verifies the Android device. If the verification is successful, it returns a verification success message to the SDK and executes step Y3. If the verification fails, it returns a verification failure message to the SDK and executes step Y3.
[0028] Specifically, the background service verifies the Android device, including: the background service parses the verification request to obtain the device serial number and device license, determines whether the device serial number belongs to the preset manufacturer and whether the validity period of the device license is greater than the current date. If both are true, the verification is successful; otherwise, the verification fails.
[0029] Step Y3: When the SDK receives the information returned by the backend service, it determines whether it is a successful verification message. If so, it generates the first key pair; otherwise, it reports an error and ends.
[0030] Step S2: When the SDK receives the first certificate returned by the backend service, it saves the first certificate, generates a key acquisition request according to the first preset number, and sends it to the backend service;
[0031] Optionally, to improve data transmission rate, the SDK stores multiple sets of TPK and DEK. The SDK periodically checks the stored and available TPK and DEK. If the number of available TPK and DEK is insufficient, it requests a key from the backend. That is, when the SDK periodically detects that the number of stored and available TPK and DEK is less than a first value, it generates a key acquisition request based on the difference between the first value and the number of available TPK and DEK and sends it to the backend service.
[0032] For example, the first preset quantity is 10, and the first value is 5;
[0033] Step S3: When the SDK receives the second ciphertext of TPK, the first signature result, the second ciphertext of DEK and the second signature result, the index value and the second certificate, it uses the second ciphertext of TPK and the second certificate, and the second ciphertext of DEK and the second certificate to verify the first signature result and the second signature result. If the verification is successful, the first private key in the first key pair is used to decrypt the second ciphertext of TPK and the second ciphertext of DEK to obtain TPK and DEK respectively, and saves TPK and DEK and the corresponding index value. If the verification fails, an error is reported.
[0034] In this embodiment, the TPK second ciphertext, the first signature result, the DEK second ciphertext and the second signature result, and the index value correspond one-to-one. If the SDK receives multiple sets of TPK second ciphertext, the first signature result, the DEK second ciphertext and the second signature result, and the index value, it needs to perform multiple verification and decryption operations to obtain multiple sets of TPK, DEK and the corresponding index value.
[0035] The workflow of the backend service is as follows Figure 2 As shown, it includes:
[0036] Step T1: When the backend service receives the first public key sent by the SDK, it generates the first certificate based on the first public key and returns it to the SDK. It generates the second certificate based on the second public key in the generated second key pair and saves it. Based on the first public key, the first certificate, the second private key in the second key pair, and the second certificate, it uses the built-in cryptographic machine to generate a second preset number of TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, and second signature result, and saves them in the database along with the corresponding index values and the number of times they can be used. It backs up all TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, second signature result, and corresponding index values in the database to the cache pool.
[0037] Optionally, step T1 may also include: updating the corresponding number of uses based on the backup data;
[0038] Specifically, in this embodiment, step T1 includes:
[0039] Step T11: When the backend service receives the first public key sent by the SDK, it generates the first certificate based on the first public key and returns it to the SDK, generates the second key pair, generates the second certificate based on the second public key in the second key pair, and saves it.
[0040] Step T12: The background service transmits the first public key, the first certificate, the second private key from the second key pair, and the second certificate to the built-in cryptographic machine;
[0041] Step T13: The cryptographic machine uses the first certificate to verify the validity of the first public key. If the verification is successful, it generates a first random number and a second random number. It uses the built-in LMK to encrypt the first random number and the second random number to obtain the first ciphertext TPK and the first ciphertext DEK respectively. It uses the first public key to encrypt the first random number and the second random number to obtain the second ciphertext TPK and the second ciphertext DEK respectively. It obtains the trust information in the second certificate. It uses the second private key to sign the second ciphertext TPK and the trust information to obtain the first signature result. It uses the second private key to sign the second ciphertext DEK and the trust information to obtain the second signature result. Based on the first ciphertext TPK, the second ciphertext TPK, the first signature result, the first ciphertext DEK, the second ciphertext DEK, and the second signature result, it generates data in a preset format and returns it to the background service.
[0042] Step T14: The background service parses the data returned by the cryptographic machine to obtain the first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, and the second signature result. It then stores these ciphertexts along with their corresponding index values and the number of times they can be used in the database. The service then checks whether the number of index values is equal to the second preset number. If so, it backs up all the first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, the second signature result, and the index values in the database to the cache pool. Otherwise, it returns to step T12.
[0043] In this embodiment, the first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, the second signature result, and the index value correspond one-to-one. Storing a large number of data groups in the cache pool can improve the key distribution rate. The second preset number is greater than the first preset number.
[0044] Step T2: When the backend service receives the key retrieval request sent by the SDK, it retrieves the corresponding number of TPK second ciphertext, first signature result, DEK second ciphertext, second signature result and corresponding index value from the cache pool according to the number of keys required in the key retrieval request, and returns the TPK second ciphertext, first signature result, DEK second ciphertext, second signature result and corresponding index value, and second certificate to the SDK together;
[0045] In this embodiment, if it is the first time a key is issued, the number of keys required in the key acquisition request is a first preset number; otherwise, the number of keys required in the key acquisition request is the difference between the first preset number and the number of available TPKs and DEKs stored in the SDK.
[0046] In this embodiment, the database and cache pool of the backend service can store a certain number of key lists, meaning that the workflow of the backend service also includes:
[0047] Step T3: When the background service periodically detects that the number of available TPK second ciphertexts and DEK second ciphertexts stored in the cache pool is less than the second value, it retrieves all available usage counts from the database and determines whether the retrieved number of available usage counts is less than the difference between the second value and the number of available index values stored in the cache pool. If yes, proceed to step T4; otherwise, back up the corresponding number of available TPK first ciphertexts, TPK second ciphertexts, first signature results, DEK first ciphertexts, DEK second ciphertexts, second signature results, and index values from the database to the cache pool based on the difference, and update the corresponding available usage counts based on the backed-up data.
[0048] Step T4: The background service uses the built-in cryptographic machine to generate TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, and second signature result based on the first public key, first certificate, second private key in the second key pair, and second certificate. It saves these results and corresponding index values and usable counts in the database until the number of usable counts in the database reaches the second preset number. Based on the difference, it backs up the corresponding number of usable TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, second signature result, and index values in the database to the cache pool, and updates the corresponding usable counts based on the backup data.
[0049] In this embodiment, to further improve the security of key generation, when the background service periodically detects that the data in the database is insufficient and a new second key needs to be generated, step T4 specifically includes: generating a new second certificate based on the second public key in the newly generated second key pair and saving it; using the built-in cryptographic machine, generating TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, and second signature result based on the first public key, the first certificate, the second private key in the second key pair, and the newly generated second certificate, and saving them in the database with the corresponding index values and the number of times they can be used, until the number of times they can be used in the database reaches a second preset number; backing up the corresponding number of TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, second signature result, and index values in the database to the cache pool according to the difference; and updating the corresponding number of times they can be used according to the backup data.
[0050] In this embodiment, after the TPK and DEK are sent to the SDK, the SDK uses the TPK and DEK to encrypt the user's privacy information. Therefore, the SDK's workflow in this embodiment also includes:
[0051] Step S4: When the SDK's encryption interface is called by the application, it receives the user's input payment password and reads the card data in the card. It encrypts the card data and payment password using the saved DEK and TPK respectively to obtain the ciphertext of the card data and the ciphertext of the payment password. It sends the ciphertext of the payment password, the ciphertext of the card data, and the index values corresponding to the used DEK and TPK to the background service through the application. It destroys the used DEK, TPK, and the corresponding index values.
[0052] Specifically, before step S4 in this embodiment, the method further includes: when the application receives the amount set by the merchant, reminding the user to swipe the card and enter the payment password; when the application establishes a connection with the card, calling the SDK's encryption interface to receive the payment password entered by the user and read the card data in the card shown.
[0053] Optionally, before encryption in step S4, the following steps are also included: the SDK obtains the Android device information and device serial number and sends them to the disc-type station for verification; receives the verification result returned by the disc-type station; determines whether the verification result is successful; if so, the card data and payment password are encrypted using the saved DEK and TPK respectively to obtain the card data ciphertext and payment password ciphertext; otherwise, an error is reported.
[0054] Specifically, the SDK will destroy the used DEK, TPK and their corresponding index values. The SDK will clear or mark the used TPK, DEK and their corresponding index values as used.
[0055] Correspondingly, the workflow of the backend service also includes:
[0056] Step T5: When the backend service receives the payment password ciphertext, card data ciphertext, and index value sent by the SDK, it retrieves the corresponding TPK first ciphertext and DEK first ciphertext from the cache pool based on the index value. It then uses a cryptographic machine to decrypt the payment password ciphertext and card data ciphertext based on the TPK first ciphertext and DEK first ciphertext to obtain the payment password and card data. It then uses the saved acquiring bank key to encrypt the card data and payment password to obtain the first encryption result and sends it to the acquiring bank for verification. Finally, it returns the transaction result returned by the acquiring bank to the application and destroys all corresponding data in the cache pool based on the index value.
[0057] In this embodiment, if the data sent by the SDK to the background service in step T5 also includes the device serial number, then before retrieving the corresponding TPK first ciphertext and DEK first ciphertext from the cache pool according to the index value in step T5, the following steps are included: the background service retrieves the corresponding Android device information from the disc-shaped platform according to the device serial number, checks the security of the Android device according to the Android device information, and if the check passes, retrieves the corresponding TPK first ciphertext and DEK first ciphertext from the cache pool according to the index value; if the check fails, an error is reported to the application.
[0058] Specifically, based on the first ciphertext of TPK and the first ciphertext of DEK, the cryptographic machine decrypts the payment password ciphertext and card data ciphertext to obtain the payment password and card data. This includes: the backend service sends the first ciphertext of TPK, the first ciphertext of DEK, the payment password ciphertext, and the card data ciphertext to the cryptographic machine; the cryptographic machine uses its built-in LMK to decrypt the first ciphertext of TPK and the first ciphertext of DEK to obtain TPK and DEK respectively; it uses TPK to decrypt the payment password ciphertext to obtain the payment password; it uses DEK to decrypt the card data ciphertext to obtain the card data; and it returns the payment password and card data to the backend service.
[0059] Specifically, in step T5, destroying all corresponding data in the cache pool based on the index value involves the background service clearing or marking the index value, the corresponding TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, and second signature result in the Redis cache pool as used.
[0060] In this embodiment, the backend service generates a large number of TPK first ciphertexts, TPK second ciphertexts, first signature results, DEK first ciphertexts, DEK second ciphertexts, and second signature results through a cryptographic machine, and stores them in the database in a one-to-one correspondence with the number of uses and index values. The data in each data group in the database, except for the number of uses, is backed up to the cache pool Redis, and the corresponding number of uses is updated. A portion of the TPK second ciphertext, first signature results, DEK second ciphertext, second signature results, and second certificate in the cache pool are returned to the SDK. After the SDK successfully verifies the signature results using the certificate, it decrypts the TPK second ciphertext and DEK second ciphertext to obtain TPK and DEK, and stores them in a one-to-one correspondence with the index values. Both TPK and DEK are stored in encrypted form in the background service, and the encryption and decryption processes are performed in a cryptographic machine, which can improve the security of keys and user data. The data groups in the database can be reused according to the number of times they can be used. The encrypted TPK and DEK to be distributed are cached in the cache pool and can be quickly queried and read, which is suitable for high-concurrency key distribution scenarios. A certain number of TPK and DEK are stored in the SDK and background service, so that different keys are used for each data transmission, improving the security of data transmission. Example 2
[0061] Embodiment 2 of the present invention provides a method for key distribution, applicable to systems including Android devices and background services. The Android device has an application installed, and the application includes a built-in SDK, such as... Figure 3 As shown, it includes:
[0062] Step 201: After the application starts, it calls the SDK's key generation interface to send a verification request to the background service;
[0063] The verification request in this embodiment includes the device serial number and the device license;
[0064] Step 202: The background service verifies the Android device. If the verification is successful, it returns a verification success message to the SDK and proceeds to step 203. If the verification fails, it returns a verification failure message to the SDK and proceeds to step 203.
[0065] Specifically, in this embodiment, the background service verifies the Android device by: determining whether the device serial number belongs to a preset manufacturer and whether the validity period of the device license is greater than the current date; if so, the verification is successful, otherwise the verification fails.
[0066] Step 203: When the SDK receives the information returned by the backend service, it determines whether it is a successful verification message. If yes, it proceeds to step 204; otherwise, it reports an error and ends.
[0067] Step 204: The SDK generates and saves the first key pair, and uploads the first public key in the first key pair to the backend service;
[0068] Preferably, in this embodiment, the SDK generates a first key pair according to the RSA algorithm, the first key pair including a first public key and a first private key;
[0069] Step 205: The backend service receives and saves the first public key, generates the first certificate based on the first public key, returns the first certificate to the SDK, generates the second key pair, generates the second certificate based on the second public key in the second key pair, and saves it.
[0070] Preferably, in this embodiment, the background service generates a second key pair according to the RSA algorithm, the second key pair including a second public key and a second private key;
[0071] Step 206: The background service transmits the first public key, the first certificate, the second private key, and the second certificate to the built-in cryptographic machine, and receives the first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, and the second signature result returned by the cryptographic machine;
[0072] In this embodiment, the cryptographic machine uses a first certificate to verify the validity of the first public key. If the verification is successful, it generates a first random number and a second random number. It then uses the built-in LMK to encrypt the first random number and the second random number to obtain the first ciphertext TPK and the first ciphertext DEK, respectively. It then uses the first public key to encrypt the first random number and the second random number to obtain the second ciphertext TPK and the second ciphertext DEK, respectively. It obtains the trust information from the second certificate, and uses the second private key to sign the second ciphertext TPK and the trust information to obtain the first signature result. It then uses the second private key to sign the second ciphertext DEK and the trust information to obtain the second signature result. Based on the first ciphertext TPK, the second ciphertext TPK, the first signature result, the first ciphertext DEK, the second ciphertext DEK, and the second signature result, it generates data in a preset format and returns it to the background service. The background service receives the data returned by the cryptographic machine and parses it to obtain the first ciphertext TPK, the second ciphertext TPK, the first signature result, the first ciphertext DEK, the second ciphertext DEK, and the second signature result.
[0073] The default format is TR34;
[0074] Step 207: The background service stores the first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, the second signature result, and the corresponding index values and usage counts in the database. It determines whether the number of index values is equal to the second preset number. If so, it backs up all the first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, the second signature result, and the index values in the database to the cache pool Redis. It updates the corresponding usage counts according to the backed-up data and executes step 208. Otherwise, it returns to step 206.
[0075] In this embodiment, the first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, the second signature result, the number of times it can be used, and the index value correspond one-to-one;
[0076] For example, the second preset quantity is 100;
[0077] Optionally, the number of times usable can be updated based on the backed-up data is as follows: the number of times usable for the backed-up data can be decremented by 1.
[0078] Step 208: The SDK sends a key acquisition request to the backend service;
[0079] Optionally, the SDK generates a key acquisition request based on a first preset number and sends it to the backend service;
[0080] For example, the first preset quantity is 10;
[0081] Step 209: The background service receives the key acquisition request, retrieves the first preset number of TPK second ciphertext, first signature result, DEK second ciphertext, second signature result and index value from the cache pool Redis, and returns the retrieved TPK second ciphertext, first signature result, DEK second ciphertext, second signature result and index value, and second certificate to the SDK;
[0082] Step 210: The SDK receives the obtained TPK second ciphertext, first signature result, DEK second ciphertext, second signature result, index value, and second certificate. It verifies the first signature result using the TPK second ciphertext and the second certificate, and verifies the second signature result using the DEK second ciphertext and the second certificate. If both verifications are successful, proceed to step 211; otherwise, report an error.
[0083] Step 211: The SDK uses the first private key to decrypt the second ciphertext of TPK and the second ciphertext of DEK respectively to obtain TPK and DEK, and saves TPK and DEK with their corresponding index values;
[0084] In this embodiment, after step 211, the SDK can use the saved TPK and DEK to encrypt the user's privacy information before sending it to the backend service. That is, the method in this embodiment also includes a key usage process, the specific process of which is as follows: Figure 4 As shown, it includes:
[0085] Step 212: When the application receives the amount set by the merchant, it prompts the user to swipe the card and enter the payment password;
[0086] For example, in this embodiment, the payment password is a PIN code;
[0087] Step 213: When the application establishes a connection with the card, it calls the SDK's encryption interface to receive the user's input payment password and read the card data from the card.
[0088] In this embodiment, the card data includes the transaction amount and the card number;
[0089] Step 214: The SDK obtains the Android device information and device serial number and sends them to the disc-shaped platform for verification;
[0090] In this embodiment, the Android device information includes: Android system version number and security patch date;
[0091] The disc-shaped platform in this embodiment is a platform focused on mobile application security protection and threat protection, provided as a service (SaaS). By injecting a security protection SDK into the App, it can detect device, environment and behavior anomalies in real time during runtime, and report device information to the cloud for analysis and response.
[0092] Step 215: The SDK receives the verification result returned by the disc-type platform, determines whether the verification result is successful, and if so, proceeds to step 216; otherwise, it reports an error.
[0093] Step 216: The SDK uses TPK to encrypt the payment password to obtain the payment password ciphertext, and uses DEK to encrypt the card data to obtain the card data ciphertext. The SDK returns the payment password ciphertext, card data ciphertext, the index value corresponding to the TPK and DEK used, and the device serial number to the application, and destroys the used TPK and DEK and their corresponding index values.
[0094] Optionally, destroying used TPK and DEK and their corresponding index values specifically involves the SDK clearing or marking used TPK, DEK and their corresponding index values as used.
[0095] Step 217: The application assembles the device serial number, payment password ciphertext, card data ciphertext, and index value to obtain transaction data, and uploads the transaction data to the background service;
[0096] Step 218: The background service parses the received transaction data to obtain the device serial number, payment password ciphertext, card data ciphertext and index value. Based on the device serial number, it retrieves the corresponding Android device information from the disc-shaped station and checks the security of the Android device based on the Android device information. If the check passes, it proceeds to step 219; if the check fails, it reports an error to the application.
[0097] Step 219: The backend service retrieves the corresponding TPK first ciphertext and DEK first ciphertext from the Redis cache pool based on the index value, passes the TPK first ciphertext, DEK first ciphertext, payment password ciphertext, and card data ciphertext to the cryptographic machine, and obtains the payment password and card data returned by the cryptographic machine. It then uses the saved acquiring bank key to encrypt the card data and payment password to obtain the first encryption result, sends the first encryption result to the acquiring bank for verification, and destroys all corresponding data in the cache pool based on the index value.
[0098] Specifically, the cryptographic machine uses its built-in LMK to decrypt the first ciphertext of TPK and the first ciphertext of DEK to obtain TPK and DEK respectively. It uses TPK to decrypt the payment password ciphertext to obtain the payment password, and uses DEK to decrypt the card data ciphertext to obtain the card data. It then returns the payment password and card data.
[0099] In this embodiment, the acquiring bank verifies the first encryption result. If the verification is successful, it returns a successful transaction result to the back-end service; if the verification fails, it returns a failed transaction result to the back-end service.
[0100] Optionally, the acquiring bank's verification of the first encrypted result includes: the acquiring bank decrypting the first encrypted result using the stored acquiring bank key, determining whether the user password corresponding to the card number in the decrypted card data is consistent with the decrypted payment password; if so, the acquiring bank further refines the user balance based on the transaction amount in the decrypted card data and returns a transaction success result to the back-end service; otherwise, it returns a transaction failure result to the back-end service.
[0101] In this embodiment, optionally, all data destroyed includes: the index value in the cache pool that is the same as the received index value and its corresponding TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, and second signature result. Specifically, the background service clears or marks the same index value, corresponding TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, and second signature result in the cache pool Redis according to the received index value.
[0102] Step 220: The back-end service receives the transaction result returned by the acquiring bank and forwards it to the application.
[0103] Preferably, in this embodiment, the number of TPKs and DEKs stored in the SDK satisfies a first value (e.g., 5), and the number of available TPKs stored in the Redis cache pool of the backend service satisfies a second value (e.g., 50). The method of this embodiment further includes:
[0104] Step A1: The SDK periodically checks the saved and available TPKs and DEKs. When the number of available TPKs and DEKs is less than a first value, it generates a key acquisition request based on the difference between the first value and the number of available TPKs and DEKs and sends it to the background service.
[0105] For example, the first value is 5;
[0106] Step A2: After receiving the key retrieval request, the backend service retrieves the corresponding number of TPK second ciphertext, first signature result, DEK second ciphertext, second signature result, and index value from the Redis cache pool based on the difference in the key retrieval request. The retrieved TPK second ciphertext, first signature result, DEK second ciphertext, second signature result, index value, and corresponding second certificate are then returned to the SDK.
[0107] Step A3: The SDK receives the second ciphertext of TPK, the first signature result, the second ciphertext of DEK, the second signature result, the index value, and the second certificate. It verifies the first signature result using the second ciphertext of TPK and the second certificate, and verifies the second signature result using the second ciphertext of DEK and the second certificate. If both verifications are successful, proceed to step A4; otherwise, report an error.
[0108] Step A4: The SDK uses the first private key to decrypt the second ciphertext of TPK and the second ciphertext of DEK respectively to obtain TPK and DEK, and saves TPK and DEK with their corresponding index values.
[0109] Accordingly, to ensure that the number of TPK and DEK ciphertexts stored in the Redis cache pool meets the second value, step 219 is followed by:
[0110] Step B1: When the background service periodically detects whether the number of available TPK second ciphertexts and DEK second ciphertexts stored and available in the Redis cache pool is less than the second value, step B2 is executed;
[0111] For example, the second value is 50;
[0112] Step B2: The background service retrieves all available usage counts from the database and determines whether the number of available usage counts is less than the difference between the second value and the number of available TPK first ciphertexts and DEK first ciphertexts stored in the cache pool Redis. If yes, proceed to step B3; otherwise, back up the corresponding number of available TPK first ciphertexts, TPK second ciphertexts, first signature results, DEK first ciphertexts, DEK second ciphertexts, second signature results, and index values to the cache pool Redis based on the difference, and update the corresponding available usage counts based on the backed-up data.
[0113] Optionally, the data stored in the database also includes the generation time and validity period of each pair of TPK ciphertext and DEK ciphertext, and the available first TPK ciphertext, second TPK ciphertext, first signature result, first DEK ciphertext, second DEK ciphertext, second signature result, and index value. Specifically, the number of times each of the first TPK ciphertext, second TPK ciphertext, first signature result, first DEK ciphertext, second DEK ciphertext, second signature result, and index value can be used is non-zero and within the validity period (i.e., the current time minus the generation time is less than the validity period).
[0114] Step B3: The background service transmits the first public key, the first certificate, the second private key, and the second certificate to the built-in cryptographic machine, and receives the first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, and the second signature result returned by the cryptographic machine;
[0115] Optionally, before step B3, the following steps are also included: the background service generates a new second key pair, generates a new second certificate based on the second public key in the second key pair, and saves it; correspondingly, the newly generated second certificate is passed into the cryptographic machine in step B3.
[0116] Step B4: The background service stores the first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, the second signature result, the number of uses, and the corresponding index values in the database. It determines whether the number of the first ciphertext of TPK and the first ciphertext of DEK is equal to the second preset number. If so, based on the difference between the second value and the number of the first ciphertext of TPK and the first ciphertext of DEK stored in the cache pool Redis, it backs up the corresponding number of index values of the first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, and the second signature result in the database to the cache pool Redis. It updates the corresponding number of uses based on the backed-up data. Otherwise, it returns to step B3.
[0117] In this embodiment, the first signature result and the second signature result are used in correspondence with the second certificate.
[0118] The background service in this embodiment of the invention uses a cryptographic machine that employs LMK (Local Master Key). The first public key is used to encrypt the first random number and the second random number to obtain the first ciphertext of TPK and the first ciphertext of DEK. The first public key is used to encrypt the first random number and the second random number to obtain the second ciphertext of TPK and the second ciphertext of DEK. The second private key is used to sign the second ciphertext of TPK and the trust information in the first certificate to obtain the first signature result. The second private key is used to sign the second ciphertext of DEK and the trust information in the first certificate to obtain the second signature result. The data returned by the cryptographic machine is stored in the database along with the index value and the number of times it can be used. There are multiple sets of data in the database. The first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, the second signature result, and the corresponding index value are synchronized to the cache pool (Redis) and the corresponding number of times it can be used is updated according to the backup data. Part of the second ciphertext of TPK, the first signature result, the second ciphertext of DEK, the second signature result, and the corresponding index value are sent to the SDK. After the SDK successfully verifies the received signature result, it decrypts the second ciphertext of TPK and the second ciphertext of DEK to obtain TPK and DEK and saves them along with the corresponding index value. The key is successfully issued. The SDK then uses TPK and DEK to encrypt user data, transmitting the encryption result along with the corresponding index value to the backend service. The backend service uses the index value to find the corresponding first ciphertext of TPK and first ciphertext of DEK, and sends them along with the encrypted user data to the cryptographic machine for decryption to obtain the user data. TPK and DEK are stored in ciphertext form in the backend service, and both encryption and decryption are performed in the cryptographic machine, improving the security of keys and user data. Furthermore, the TPK and DEK in the SDK and the TPK and DEK in the backend service's cache pool are monitored and updated in real time, and a large number of pre-generated TPK and DEK ciphertexts are generated to improve data processing speed. Using the cache pool to back up multiple sets of TPK and DEK ciphertexts improves the key issuance response speed in high-concurrency scenarios, reduces issuance delays, and uses different keys for encryption in each transmission to further enhance data transmission security.
[0119] Optionally, embodiments of this application also provide a key distribution implementation system, including an SDK and a background service. The SDK is set in an application on an Android device, and the background service contains a cryptographic machine. The SDK and the background service work together to implement the key distribution method in the above embodiments.
[0120] Optionally, embodiments of this application also provide an electronic device, which includes at least one processor, a memory, and instructions stored in the memory and executable by the at least one processor. The at least one processor executes the instructions to implement the key distribution method in the above embodiments. When the electronic device is a chip system, it can be composed of chips or may include chips and other discrete devices; embodiments of this application do not specifically limit this. The chip is coupled to the memory and is used to execute the computer program stored in the memory to execute the key distribution method disclosed in the above embodiments.
[0121] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be entirely or partially in the form of a computer program product. This computer program product includes one or more computer programs. When the computer program is loaded and executed on an electronic device, all or part of the processes or functions described in the embodiments of this application are generated. The computer program can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one base station, electronic device, server, or data center to another via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to the electronic device or a data storage device including one or more servers, data centers, etc., that can be integrated using media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)). In the embodiments of this application, the electronic device may include the system described above.
[0122] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.
[0123] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.
Claims
1. A method for implementing key distribution, characterized in that, The method is applicable to systems containing Android devices and background services. An application is installed on the Android device, and the application has a built-in SDK. The method includes the workflow of the background service and the workflow of the SDK. The SDK workflow includes: Step S1: When the application calls the key generation interface of the SDK, a first key pair is generated and saved, and the first public key in the first key pair is uploaded to the background service. Step S2: When the SDK receives the first certificate returned by the backend service, it saves the first certificate, generates a key acquisition request according to the first preset number, and sends it to the backend service. If it is the first time the key is issued, the number of keys required in the key acquisition request is the first preset number. Step S3: When the SDK receives the second ciphertext of the terminal PIN key TPK, the first signature result, the second ciphertext of the data encryption key DEK, the second signature result, the index value, and the second certificate, it uses the second ciphertext of TPK and the second certificate, and the second ciphertext of DEK and the second certificate to verify the first signature result and the second signature result. If the verification is successful, the first private key in the first key pair is used to decrypt the second ciphertext of TPK and the second ciphertext of DEK to obtain TPK and DEK respectively, and the TPK and DEK and the corresponding index value are saved. If the verification fails, an error is reported. The workflow of the backend service includes: Step T1: When the background service receives the first public key sent by the SDK, it generates a first certificate based on the first public key and returns it to the SDK. It generates a second certificate based on the second public key in the generated second key pair and saves it. Based on the first public key, the first certificate, the second private key in the second key pair, and the second certificate, it uses the built-in cryptographic machine to generate a second preset number of TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, and second signature result, and saves them in the database with the corresponding index values and the number of times they can be used. It backs up all the TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, second signature result, and corresponding index values in the database to the cache pool. Step T2: When the background service receives the key acquisition request sent by the SDK, it retrieves the corresponding number of TPK second ciphertext, first signature result, DEK second ciphertext, second signature result and corresponding index value from the cache pool according to the number of keys required in the key acquisition request, and returns them to the SDK together with the second certificate.
2. The method as described in claim 1, characterized in that, The SDK's workflow also includes: when the SDK periodically detects that the number of saved and available TPKs and DEKs is less than a first value, it generates a key acquisition request based on the difference between the first preset number and the number of available TPKs and DEKs and sends it to the background service, and executes step S3. If it is not the first time a key is issued, the number of keys required in the key acquisition request is the difference between the first preset number and the number of available TPKs and DEKs saved in the SDK.
3. The method as described in claim 1, characterized in that, Step T1 further includes: updating the corresponding number of usable uses based on the backup data; The workflow of the backend service also includes: Step T3: When the background service periodically detects that the number of available TPK second ciphertexts and DEK second ciphertexts stored in the cache pool is less than the second value, it obtains all the available usage counts in the database and determines whether the number of available usage counts obtained is less than the difference between the second value and the number of available index values stored in the cache pool. If yes, it executes step T4; otherwise, it backs up the corresponding number of available TPK first ciphertexts, TPK second ciphertexts, first signature results, DEK first ciphertexts, DEK second ciphertexts, second signature results, and index values in the database to the cache pool according to the difference, and updates the corresponding available usage counts according to the backed-up data. Step T4: The background service uses the built-in cryptographic machine to generate TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, and second signature result based on the first public key, the first certificate, the second private key in the second key pair, and the second certificate. These are then stored in the database along with the corresponding index values and the number of times they can be used. This process continues until the number of times ...
4. The method as described in claim 1, characterized in that, Step T1 includes: Step T11: When the background service receives the first public key sent by the SDK, it generates a first certificate based on the first public key and returns it to the SDK, generates a second key pair, generates a second certificate based on the second public key in the second key pair, and saves it. Step T12: The background service transmits the first public key, the first certificate, the second private key from the second key pair, and the second certificate to the built-in cryptographic machine; Step T13: The cryptographic machine uses the first certificate to verify the validity of the first public key. If the verification is successful, it generates a first random number and a second random number. It uses the built-in local master key LMK to encrypt the first random number and the second random number to obtain the first ciphertext TPK and the first ciphertext DEK. It uses the first public key to encrypt the first random number and the second random number to obtain the second ciphertext TPK and the second ciphertext DEK. It obtains the trust information in the second certificate. It uses the second private key to sign the second ciphertext TPK and the trust information to obtain a first signature result. It uses the second private key to sign the second ciphertext DEK and the trust information to obtain a second signature result. It generates data in a preset format based on the first ciphertext TPK, the second ciphertext TPK, the first signature result, the first ciphertext DEK, the second ciphertext DEK, and the second signature result, and returns it to the background service. Step T14: The background service parses the data returned by the cryptographic machine to obtain the first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, and the second signature result, and stores them in the database along with the corresponding index values and the number of times they can be used. It then determines whether the number of index values is equal to the second preset number. If so, it backs up all the first ciphertext of TPK, the second ciphertext of TPK, the first signature result, the first ciphertext of DEK, the second ciphertext of DEK, the second signature result, and the index values in the database to the cache pool. Otherwise, it returns to step T12.
5. The method as described in claim 3, characterized in that, Step T4 includes: the background service generates and saves a new second certificate based on the second public key in the newly generated second key pair; it uses the built-in cryptographic machine to generate TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, and second signature result based on the first public key, the first certificate, the second private key in the second key pair, and the newly generated second certificate, and saves them in the database with the corresponding index values and usage counts until the number of usage counts in the database reaches a second preset number; based on the difference, it backs up the corresponding number of TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, second signature result, and index values in the database to the cache pool, and updates the corresponding usage counts based on the backup data.
6. The method as described in claim 1, characterized in that, The SDK's workflow also includes: Step S4: When the encryption interface of the SDK is called by the application, the user's input payment password is received and the card data in the card is read. The card data and payment password are encrypted using the saved DEK and TPK respectively to obtain the card data ciphertext and payment password ciphertext. The payment password ciphertext, the card data ciphertext, and the index value corresponding to the used DEK and TPK are sent to the background service through the application. The used DEK, TPK and the corresponding index value are destroyed. The workflow of the backend service also includes: Step T5: When the background service receives the payment password ciphertext, the card data ciphertext, and the index value sent by the SDK, it retrieves the corresponding TPK first ciphertext and DEK first ciphertext from the cache pool according to the index value. Based on the TPK first ciphertext and the DEK first ciphertext, it uses the cryptographic machine to decrypt the payment password ciphertext and the card data ciphertext to obtain the payment password and card data. It uses the saved acquiring bank key to encrypt the card data and the payment password to obtain the first encryption result and sends it to the acquiring bank for verification. It returns the transaction result returned by the acquiring bank to the application and destroys all corresponding data in the cache pool according to the index value.
7. The method as described in claim 6, characterized in that, The destruction of the used DEK, TPK and corresponding index value specifically involves the SDK clearing or marking the used TPK, DEK and corresponding index value as used. Destroy all corresponding data in the cache pool according to the index value. Specifically, the background service clears or marks the same index value and its corresponding TPK first ciphertext, TPK second ciphertext, first signature result, DEK first ciphertext, DEK second ciphertext, and second signature result in the cache pool according to the received index value.
8. The method as described in claim 6, characterized in that, The step T5, which involves using the cryptographic machine to decrypt the payment password ciphertext and the card data ciphertext based on the first ciphertext of TPK and the first ciphertext of DEK to obtain the payment password and card data, includes: the background service transmitting the first ciphertext of TPK, the first ciphertext of DEK, the payment password ciphertext, and the card data ciphertext to the cryptographic machine; The cryptographic machine uses its built-in LMK to decrypt the first ciphertext of the TPK and the first ciphertext of the DEK to obtain the TPK and DEK respectively. It then uses the TPK to decrypt the ciphertext of the payment password to obtain the payment password, and uses the DEK to decrypt the ciphertext of the card data to obtain the card data. Finally, it returns the payment password and the card data to the background service.
9. A key distribution implementation system, characterized in that, The method includes an SDK and a background service. The SDK is set in an application on an Android device, and the background service contains a cryptographic machine. The SDK and the background service work together to implement the method described in any one of claims 1-8.
10. An electronic device, characterized in that, The electronic device includes at least one processor, a memory, and instructions stored in the memory and executable by the at least one processor, the at least one processor executing the instructions to implement the method according to any one of claims 1 to 8.
11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 8.
12. A chip system, characterized in that, The device includes a chip coupled to a memory for executing a computer program stored in the memory to perform the method according to any one of claims 1-8.