Implementation method and device for key import and key use

Abstract

The invention discloses a method and a device for realizing key import and key use. When a secret key import interface of the SDK is called by an upper-layer application, a certificate chain generated by the secret key library is sent to the push service, and a first encryption result, a first random number, a second encryption result and label data returned by the push service are sent to the secret key library for verification; if the verification is passed, the master key identifier and a master key obtained by decrypting the second encryption result through the key library are correspondingly stored in the key library; when a key encryption interface of the SDK is called by an upper-layer application, encrypting data to be processed by using a first working key returned by a key library to obtain a first data ciphertext to be processed, and sending the first data ciphertext to be processed, preset data and a second random number to a push service; receiving a processing result ciphertext and a third random number returned by the push service; and decrypting the processing result ciphertext by using a fourth working key returned by the key library, and performing subsequent operation according to a processing result obtained by successful decryption.

Description

Technical Field

[0001] The present invention relates to the field of information security, and in particular to a method and device for implementing key import and key use. Background Art

[0002] SoftPOS (Software POS) refers to technology that utilizes software applications and mobile devices (such as smartphones and tablets) to process retail transactions. SoftPOS systems typically include an application that connects to a payment provider's network to accept credit and debit card payments. Compared to traditional POS devices, SoftPOS lacks a secure SM (Safe Module) area. Furthermore, the PCI MPoC specification requires that master keys cannot be stored in memory. Therefore, ensuring the security of keys within SoftPOS is a pressing issue. Summary of the Invention

[0003] The purpose of the present invention is to overcome the deficiencies of the prior art and to provide a method and device for implementing key import and key use.

[0004] In a first aspect, an embodiment of the present invention provides a method for implementing key import and key usage, which is applicable to a mobile device including a SoftPOS and a Keystore, wherein the SoftPOS includes an upper-layer application and an SDK, wherein the SDK is integrated with the upper-layer application or is independently provided with the upper-layer application. The method includes a key import process and a key usage process, wherein the key import process includes: Step S1: When the key import interface of the SDK is called by the upper-layer application, the SDK calls the first interface of the Keystore and forwards the certificate chain returned by the first interface to the push service; Step S2: The SDK receives the first encryption result, the first random number, the second encryption result, and the label data returned by the HSM forwarded by the push service; the first encryption result is obtained by encrypting the first key generated by the HSM using the encapsulated public key in the first certificate of the certificate chain, and the second encryption result and the label data are obtained by processing the first random number and the master key generated by the HSM using the first key; Step S3: The SDK sends the first encryption result, the first random number, the second encryption result, and the tag data to the Keystore for verification. If the verification is successful, the SDK stores the generated master key identifier and the master key obtained by decrypting the second encryption result through the Keystore in the Keystore. The key usage process includes: Step T1: When the key encryption interface of the SDK is called by the upper-layer application, the SDK sends the master key identifier, the built-in preset data, and the generated second random number to the Keystore, and receives from the Keystore a first working key obtained by encrypting the built-in preset data and the second random number using the master key corresponding to the master key identifier; Step T2: The SDK uses the first working key to encrypt the data to be processed to obtain a first ciphertext of the data to be processed, and sends the built-in preset data, the second random number, and the first ciphertext of the data to be processed to the push service; Step T3: The SDK receives the ciphertext of the processing result and the third random number returned by the HSM and forwarded by the push service; Step T4: The SDK sends the third random number and the built-in preset data to the Keystore, receives the fourth working key returned by the Keystore, which is obtained by encrypting the built-in preset data and the third random number using the master key corresponding to the master key identifier, uses the fourth working key to decrypt the processing result ciphertext, obtains the processing result after successful decryption, performs subsequent operations based on the processing result, and clears the first working key and the fourth working key.

[0005] In a second aspect, an embodiment of the present invention further provides a device for implementing key import and key usage, which is applied to a mobile device including a SoftPOS and a Keystore. The device is specifically provided in the SoftPOS and integrated into an upper-layer application in the SoftPOS or independently provided from the upper-layer application. The device includes a key import module and a key usage module. The key import module includes: A first receiving and forwarding unit is configured to call a first interface of the Keystore when the key import interface is called by the upper-layer application, and forward the certificate chain returned by the first interface to the push service; a first receiving unit, configured to receive a first encryption result, a first random number, a second encryption result, and label data returned by the HSM forwarded by the push service; the first encryption result being obtained by encrypting a first key generated by the HSM using the encapsulated public key in the first certificate of the certificate chain; and the second encryption result and label data being obtained by processing a first random number and a master key generated by the HSM using the first key; a first sending unit, configured to send the first encryption result, the first random number, the second encryption result, and the tag data to the Keystore for verification, and if the verification passes, store the generated master key identifier and the master key obtained by decrypting the second encryption result by the Keystore in the Keystore in correspondence with each other; The key usage module includes: a first sending and receiving unit, configured to, when the key encryption interface is called by the upper-layer application, send the master key identifier, the built-in preset data, and the generated second random number to the Keystore, and receive, returned by the Keystore, a first working key obtained by encrypting the built-in preset data and the second random number using a master key corresponding to the master key identifier; a first encryption and sending unit, configured to encrypt the data to be processed using the first working key to obtain a first ciphertext of the data to be processed, and send the built-in preset data, the second random number, and the first ciphertext of the data to be processed to the push service; a second receiving and forwarding unit, configured to receive the ciphertext of the processing result and the third random number returned by the HSM and forwarded by the push service; a sending and receiving decryption unit, configured to send the third random number and the built-in preset data to the Keystore, receive a fourth working key returned by the Keystore, which is obtained by encrypting the built-in preset data and the third random number using the master key corresponding to the master key identifier, decrypt the processing result ciphertext using the fourth working key, obtain a processing result upon successful decryption, perform subsequent operations based on the processing result, and clear the first working key and the fourth working key.

[0006] In a third aspect, an embodiment of the present invention further provides 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, and the at least one processor executes the instructions to implement the aforementioned method.

[0007] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium includes a computer program, and when the computer program runs on an electronic device, the electronic device executes any one of the methods described above.

[0008] In a fifth aspect, an embodiment of the present invention further provides a chip system, comprising a chip, wherein the chip is coupled to a memory and is configured to execute a computer program stored in the memory to execute any of the methods described above.

[0009] Compared with the prior art, the present invention has the following advantages: the technical solution of the present invention uses Keystore (Chinese name: key library) to store the master key, and the master key exists in ciphertext form during the transmission process and when it is passed to Keystore. A working key is generated based on the master key in Keystroe, and the working key is used for data processing. The working key is cleared after the processing is completed. The working key for each processing process is different, which is simple and safe. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A flowchart of a method for implementing key import and key use provided in Example 1 of the present invention; Figure 2 A schematic diagram of a system framework applicable to a method for implementing key import and key use provided in Embodiment 2 of the present invention; Figure 3 A flowchart of a key import process for a method for implementing key import and key use provided in Embodiment 2 of the present invention; Figure 4 This is a flowchart of a key usage process of a method for implementing key import and key usage provided in embodiment 2 of the present invention. DETAILED DESCRIPTION

[0011] This application proposes a method and apparatus for implementing key import and key usage. The following describes specific implementations of this application in detail 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 illustrative and intended only to explain this application, and are not to be construed as limiting this application.

[0012] Those skilled in the art will understand that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those skilled in the art to which this application belongs. It should also be understood that terms such as those defined in common dictionaries should be understood to have meanings consistent with their meanings in the context of the prior art and, unless specifically defined as such, will not be interpreted in an idealized or overly formal sense.

[0013] To make the objectives, technical solutions and advantages of the present invention more clear, the embodiments of the present invention are described in further detail below with reference to the accompanying drawings.

[0014] In this embodiment, the Keystore is a secure container specifically designed for storing keys. Keys in the Keystore persist (i.e., they persist even after applications are closed or the device is restarted). These keys are suitable for sensitive information processing, such as data encryption, signing, and authentication. Keys in the Keystore can also be configured with expiration dates, usage scopes, and usage restrictions, ensuring they can be securely deleted when no longer needed and ensuring reliable key usage. Keys in the Keystore are protected by hardware acceleration and a physical security module (TPM or HSM) to prevent key extraction or exposure, enhancing key security.

[0015] Example 1 Embodiment 1 of the present invention provides a method for implementing key import and key use, which is applicable to a mobile device including a Keystore and a SoftPOS. The SoftPOS includes an upper-layer application and an SDK (Software Development Kit). The SDK is integrated into the upper-layer application, or the SDK and the upper-layer application are independently set.

[0016] like Figure 1 As shown, the method of this embodiment includes a key import process and a key usage process. The key import process includes: Step S1: When the SDK's key import interface is called by the upper-layer application, the SDK calls the first interface of the Keystore and forwards the certificate chain returned by the first interface to the push service; In this embodiment, after the SDK calls the first interface of the Keystore, it also includes: when the first interface of the Keystore is called, the Keystore generates and saves an encapsulation key pair, generates a first certificate based on the encapsulation public key in the encapsulation key pair, generates a certificate chain based on the first certificate, and returns the certificate chain to the SDK.

[0017] In this embodiment, the steps between step S1 and step S2 further include: Step B1: The push service verifies the received certificate chain using the verification certificate. If the verification succeeds, the service imports the encapsulated public key in the first certificate in the certificate chain into the HSM and executes step B2. If the verification fails, the service returns a verification failure message to the SDK. The certificate chain includes a first certificate, a second certificate, a third certificate, and a fourth certificate. Step B1 includes: Step B11: The push service uses the public key in the fourth certificate to verify the third certificate. If the verification succeeds, step B12 is executed. If the verification fails, a verification failure message is returned to the SDK. Step B12: The push service verifies the second certificate using the public key in the third certificate. If the verification succeeds, step B13 is executed. If the verification fails, a verification failure message is returned to the SDK. Step B13: The push service verifies the first certificate using the public key in the second certificate. If the verification succeeds, step B14 is executed. If the verification fails, a verification failure message is returned to the SDK. Step B14: The push service determines whether the status of the verification certificate is valid. If so, it executes step B15; otherwise, it returns a verification failure message to the SDK. Optionally, in this embodiment, before step B14, the method further includes: the push service obtains and updates the status of the verification certificate according to a preset designated website at a preset time interval; Optionally, before step B14, it also includes: the push service obtains the verification certificate revocation list according to the preset designated URL, and determines whether the fourth certificate is in the verification certificate revocation list. If so, it returns a verification failure message to the SDK, otherwise executes step B14; and / or before step B15, it also includes: determining whether the fourth certificate is within the validity period. If so, it executes step B15, otherwise it reports an error.

[0018] Step B15: The push service determines whether the public key in the fourth certificate is consistent with the public key in the verification certificate. If so, the public key in the first certificate is imported into the HSM. If the verification fails, a verification failure message is returned to the SDK.

[0019] Optionally, in this embodiment, before step B1, the process further includes: the push service downloading the verification certificate according to a preset designated website.

[0020] Step B2: The HSM saves the encapsulated public key, generates a first key, and uses the encapsulated public key to encrypt the first key to obtain a first encryption result; Step B3: The HSM generates and stores a master key, and uses the first key to process the master key and the generated first random number according to the first preset algorithm in the preset mode to obtain the tag data and the second encryption result; Step B4: The HSM returns the first encryption result, the second encryption result, the first random number, and the tag data to the push service; Step B5: The push service receives the first encryption result, the second encryption result, the first random number, and the tag data and forwards them to the SDK; In this embodiment, step B5 includes: the push service receives the first encryption result, the first random number, the second encryption result and the tag data returned by the HSM, assembles them according to a preset format, and sends the assembled result to the SDK.

[0021] Step S2: The SDK receives the first encryption result, the first random number, the second encryption result, and the label data returned by the HSM and forwarded by the push service; In this embodiment, the first encryption result is obtained by encrypting the first key generated by the HSM using the encapsulated public key in the first certificate in the certificate chain. The second encryption result and the label data are obtained by processing the first random number and the master key generated by the HSM using the first key. Step S3: The SDK sends the first encryption result, the first random number, the second encryption result, and the tag data to the Keystore for verification. If the verification is successful, the SDK stores the generated master key identifier and the master key obtained by decrypting the second encryption result through the Keystore in the Keystore. Specifically, in this embodiment, step S3 includes: Step S31: SDK generates a master key identifier and sends the master key identifier and assembly result to Keystore; Step S32: Keystore determines whether the format of the assembly result is legal. If so, it executes step S33; otherwise, it returns an error message to the SDK. Step S33: Keystore parses the assembly result to obtain the first encryption result, the second encryption result, the first random number, and the label data. The first encryption result is decrypted using the encapsulated private key in the stored encapsulation key pair. Upon successful decryption, the first key is obtained. The label data is generated based on the second encryption result and the first random number. Step S34: Keystore determines whether the generated tag data is the same as the parsed tag data. If yes, it executes step S35; otherwise, it returns an error message to the SDK. Step S35: Keystore decrypts the second encryption result using the first key, and stores the decrypted master key and the master key identifier in correspondence with each other.

[0022] The key usage process includes: Step T1: When the SDK's key encryption interface is called by the upper-layer application, the SDK sends the master key identifier, built-in preset data, and the generated second random number to the Keystore, and receives back from the Keystore the first working key obtained by encrypting the preset data and the second random number using the master key corresponding to the master key identifier. In this embodiment, after sending the master key identifier, built-in preset data and generated second random number to the Keystore in step T1, it also includes: the Keystore obtains the corresponding saved master key based on the received master key identifier, uses the master key to encrypt the received preset data and second random number to obtain a first working key, and returns the first working key to the SDK.

[0023] Step T2: The SDK encrypts the data to be processed using the first working key to obtain the first ciphertext of the data to be processed, and sends the preset data, the second random number, and the first ciphertext of the data to be processed to the push service; In this embodiment, the following steps are further included between step T2 and step T3: Step Y1: The push service receives the preset data, the second random number, and the first ciphertext of the data to be processed and forwards it to the HSM; Step Y2: The HSM uses the stored master key to encrypt the received preset data and the second random number to obtain a second working key. The HSM decrypts the received first ciphertext of the data to be processed using the second working key. Upon successful decryption, the data to be processed is obtained. The HSM then uses the stored bank key to encrypt the data to be processed to obtain a second ciphertext of the data to be processed. The second ciphertext of the data to be processed is then returned to the push service. Step Y3: The push service receives the second ciphertext data to be processed returned by the HSM, forwards the second ciphertext data to be processed to the acquirer, receives the first ciphertext data returned by the acquirer, and forwards it to the HSM; Step Y4: The HSM decrypts the received first ciphertext data using the stored bank key, and obtains a processing result if the decryption is successful; Step Y5: The HSM generates a third random number, encrypts the preset data and the third random number using the stored master key to obtain a third working key, encrypts the processing result using the third working key to obtain a processing result ciphertext, sends the processing result ciphertext and the third random number to the push service, and clears the second working key and the third working key. Step Y6: The push service receives the processing result ciphertext and the third random number returned by the HSM and forwards them to the SDK, clearing the second working key and the third working key.

[0024] Step T3: The SDK receives the ciphertext of the processing result and the third random number returned by the HSM forwarded by the push service; Step T4: The SDK sends the third random number and preset data to the Keystore, receives the fourth working key returned by the Keystore, which is obtained by encrypting the preset data and the third random number using the master key corresponding to the master key identifier, decrypts the processing result ciphertext using the fourth working key, obtains the processing result after successful decryption, performs subsequent operations based on the processing result, and clears the first working key and the fourth working key.

[0025] In this embodiment, the process between the SDK sending the third random number and preset data to the Keystore and receiving the fourth working key obtained by encrypting the preset data and the third random number with the master key returned by the Keystore in step T4 also includes: the Keystore uses the saved master key to encrypt the received preset data and the third random number to obtain the fourth working key, returns the fourth working key to the SDK, and clears the first working key and the fourth working key.

[0026] The method of this embodiment uses Keystore to save the master key, and the master key exists in ciphertext form during the transmission process and when it is passed to Keystore. A working key is generated based on the master key in Keystroe, and the working key is used for data processing. The working key is cleared after the processing is completed. The working key for each processing process is different, which is simple and secure.

[0027] Example 2 The second embodiment of the present invention provides a method for implementing key import and key use, which is applicable to systems including Keystore, SDK, push service, HSM, etc. Figure 2 As shown, the Keystore and SDK are set in the mobile phone. The SDK can be integrated into the upper-layer application in the mobile phone's SoftPOS, or it can be set independently in the SoftPOS in the mobile phone. The Keystore communicates with the SDK, and the SDK and the upper-layer application both communicate with the push service, and the push service communicates with the HSM. After the user triggers the Generate Key button of the upper-layer application, the upper-layer application calls the SDK's key import interface to perform the key import operation, or after the user triggers the Transaction Confirmation button of the upper-layer application, the upper-layer application calls the SDK's key encryption interface to use the key to complete the transaction operation. like Figure 3 As shown, the key import process in this embodiment includes: Step 101: When the SDK's key import interface is called by the upper-layer application, the SDK calls the first interface of the Keystore; The upper layer application in this embodiment can be a third-party application or an application of an SDK developer. When the upper layer application receives the user's import key trigger information, it calls the SDK; For example, the first interface in this embodiment is: KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_RSA,ANDROID_KEY_STORE); KeyGenParameterSpec build = new KeyGenParameterSpec.Builder("0BFA5C2ECE6D486BBC0FC11C9233AB1347B925137FDAAB9AB7D924F6DB616AEB", KeyProperties.PURPOSE_WRAP_KEY) .setDigests(KeyProperties.DIGEST_SHA256) .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_RSA_OAEP) .setBlockModes(KeyProperties.BLOCK_MODE_ECB) .setIsStrongBoxBacked(true) .setAttestationChallenge(challenge) .build(); keyPairGenerator.initialize(build); KeyPair keyPair = keyPairGenerator.generateKeyPair(); Step 102: When the first interface of the Keystore is called, the Keystore generates a wrapping key pair, generates a first certificate based on the wrapping public key in the wrapping key pair, generates a certificate chain based on the first certificate, and returns the certificate chain; In this embodiment, the encapsulated key pair is an RSA key pair, including an encapsulated private key and an encapsulated public key; the certificate chain includes a first certificate, a second certificate, a third certificate, and a fourth certificate; Step 103: The SDK forwards the certificate chain to the push service; Step 104: The push service verifies the received certificate chain using the verification certificate. If the verification succeeds, the encapsulated public key in the first certificate in the certificate chain is imported into the HSM. If the verification fails, a verification failure message is returned to the SDK. In this embodiment, before step 104, the process further includes: the push service downloading the verification certificate from Google according to a preset designated URL; The verification certificate in this embodiment is an x509 certificate, and the designated URL is: https: / / developer.android.google.cn / privacy-and-security / security-key-attestation; Specifically, step 104 includes: Step A1: The push service uses the public key in the fourth certificate in the certificate chain to verify the third certificate in the certificate chain. If the verification succeeds, step A2 is executed. If the verification fails, a verification failure message is returned to the SDK. Step A2: The push service uses the public key in the third certificate in the certificate chain to verify the second certificate in the certificate chain. If the verification succeeds, step A3 is executed. If the verification fails, a verification failure message is returned to the SDK. Step A3: The push service uses the public key in the second certificate in the certificate chain to verify the first certificate in the certificate chain. If the verification succeeds, step A4 is executed. If the verification fails, a verification failure message is returned to the SDK. Step A4: The push service determines whether the status of the verification certificate is valid. If so, it executes step A5. Otherwise, it returns a verification failure message to the SDK. In this embodiment, the push service obtains and updates the status of the verification certificate from Google according to a preset designated URL at a preset time interval; Optionally, in this embodiment, before step A4, the process further includes: the push service obtaining a verification certificate revocation list from Google according to a preset designated URL, determining whether the fourth certificate in the certificate chain is in the verification certificate revocation list, and if so, returning a verification failure message to the SDK; otherwise, executing step A4; Step A5: The push service determines whether the public key in the fourth certificate in the certificate chain is consistent with the public key in the verification certificate. If so, it imports the encapsulated public key in the first certificate into the HSM. Otherwise, it returns a verification failure message to the SDK. Optionally, in this embodiment, before step A5, the method further includes: determining whether the fourth certificate in the certificate chain is within the validity period, if yes, proceeding to the next step, otherwise reporting an error; Step 105: The HSM saves the encapsulated public key in the first certificate in the certificate chain, generates a first key, and encrypts the first key using the encapsulated public key in the first certificate to obtain a first encryption result; The first key in this embodiment is an AES256 key; Specifically, in this embodiment, the HSM generates a first key through a first generation interface, and encrypts the first key using the encapsulated public key in the first certificate through a first encryption interface to obtain a first encryption result; For example, the first generation interface is: genSymmKey(), and the first encryption interface is LMKToOther(); For example, the first key generated in this embodiment is: 1A312F1DF82222D6CE7CD62AC25DCB7B82BB49840DDD8308712E7E4CC6EF97A4, and the first encryption result is: 84788769C6174E5A3DAE247117FA0A663E662DB9DEC672351AF98EC0315B 92C903209D30742D7EF45E7E8CF029A03A6D1555A60F75510127E9CC96E46B4CE09E91E2F74 4A8C47FD4BC90FB63175DFBFD491F089DF7291569C40A119D4509568DB4BEF6918BF5E609AD5 D07ED9DC67548D326BEFA6B83C4AC2CFC31A2830E14573945526356C2C0227DEC1DFD6ACBAB 255050CA5AF74E9866F3038303AD1B80E7969D4FD1210B90FC8A096C736932701A1793FDD55D A59EB78160AE8BC51ECC96A64FF1B50568982FC193E6B6BB8D138EDF9693702CF032B40F07E BB57FC4479CA96D14FF7232E09421B559BD342E211795B572C8EDF002CA4644BA5CDF95ACD9; Step 106: The HSM generates a master key and a first random number, saves the master key, and encrypts the master key and the first random number using the first key according to the AES algorithm in GCM mode to obtain the tag data and the second encryption result; The master key in this embodiment is an AES128 key; Specifically, the HSM generates a master key through a first generation interface, generates a first random number through a second generation interface, and encrypts the generated master key and the first random number using the first key in GCM mode according to the AES algorithm through a first processing interface to obtain the tag data and the second encryption result; For example, the second generation interface is genRandom(), and the first processing interface is: LMKToOther(); Specifically, in this embodiment, encrypting the master key and the first random number using the first key in the GCM mode according to the AES algorithm to obtain the tag data and the second encryption result includes: segmenting the master key, performing an encryption operation on each segment of data using the first key according to the AES algorithm, concatenating all the encryption operation results to obtain the second encryption result, performing a preset operation on each encryption operation result and the first random number, concatenating the operation results to obtain verification information, and calculating the verification information using the GCM algorithm to obtain the tag data; For example, in this embodiment, the master key is: F2D9673A260747A1B24D6F9DD90559EC, the first random number is: 6540451C2812BD4C852BA319, the tag data is: F78A2939821B16EB5C9C823B11B1A474, and the second encryption result is: 9AFC544A9DF3F1F74535190A90E08F62; Step 107: The HSM returns the first encryption result, the second encryption result, the first random number, and the tag data to the push service; For example, in this embodiment, the data returned to the push service in step 107 is: Step 108: The push service assembles the received first encryption result, the first random number, the second encryption result, and the tag data according to a preset format, and sends the assembled result to the SDK; Specifically, the preset format in this embodiment is the ASN.1 format; Step 109: The SDK generates a master key identifier and sends the master key identifier and assembly result to the Keystore; In this embodiment, the master key identifier may be a key name or a key ID; Step 110: Keystore determines whether the format of the assembly result is legal. If so, it executes step 111; otherwise, it returns an error message to the SDK. Step 111: Keystore parses the assembly result to obtain the first encryption result, the second encryption result, the first random number, and the label data. The first encryption result is decrypted using the stored encapsulated private key. Upon successful decryption, the first key is obtained. The label data is generated based on the second encryption result and the first random number. In this embodiment, generating label data based on the second encryption result and the first random number includes: segmenting the second encryption result, performing operations on each segment of data and the first random number, concatenating the operation results to obtain verification information, and calculating the verification information using the GCM algorithm to obtain the label data; Step 112: Keystore determines whether the generated tag data is the same as the parsed tag data. If yes, it executes step 113; otherwise, it returns an error message to the SDK. Step 113: The Keystore decrypts the second encryption result using the first key, and stores the decrypted master key and the received master key identifier in correspondence. In this embodiment, the Keystore uses the first key to decrypt the second encryption result, including: using the first key to decrypt each segment of the second encryption result, and splicing all decrypted results to obtain a master key.

[0028] The key usage process in this embodiment is as follows Figure 4 As shown, including: Step 201: When the SDK's key encryption interface is called by an upper-layer application, the SDK generates a second random number and sends the master key identifier, built-in preset data, and the second random number to the Keystore; The upper layer application in this embodiment may be a third-party application or a developer's application, and the upper layer application calls the SDK when it receives the user's data processing trigger information; For example, the preset data in this embodiment is: 6674637873616665, and the second random number is: 5f6e6ba0b5145677; Step 202: The Keystore obtains the corresponding saved master key based on the received master key identifier, uses the master key to encrypt the received preset data and the second random number to obtain a first working key, and returns the first working key to the SDK; Specifically, in this embodiment, the Keystore encrypts the received preset data and the second random number using the stored master key through the second encryption interface to obtain the first working key; For example, in this embodiment, the second encryption interface is: Cipher c = Cipher.getInstance("AES / ECB / NoPadding"); c.init(Cipher.ENCRYPT_MODE); Keystore uses the master key F2D9673A260747A1B24D6F9DD90559EC through the second encryption interface to encrypt the preset data 6674637873616665 and the second random number 5f6e6ba0b5145677 to obtain the first working key C21047EE3761BF44E3C9676C9226B7BD; Step 203: The SDK encrypts the data to be processed using the received first working key to obtain a first ciphertext of the data to be processed, and sends the preset data, the second random number, and the first ciphertext of the data to be processed to the push service; In this embodiment, the upper layer application uses the data to be processed as a parameter to call the key encryption interface of the SDK; In this embodiment, the SDK uses the first working key C21047EE3761BF44E3C9676C9226B7BD to encrypt the data to be processed 12345678901234561234567890123456 to obtain the first ciphertext of the data to be processed 2E90841D587CD596D6E0EAE368E77AE7; Step 204: The push service forwards the preset data, the second random number, and the first ciphertext of the data to be processed to the HSM; Step 205: The HSM uses the stored master key to encrypt the received preset data and the second random number to obtain a second working key, and uses the second working key to decrypt the received ciphertext of the first data to be processed. If decryption is successful, the data to be processed is obtained. Specifically, in this embodiment, the HSM encrypts the received preset data and the second random number using the stored master key through the third encryption interface to obtain the second working key, and decrypts the received ciphertext of the data to be processed using the second working key through the first decryption interface; For example, in this embodiment, the third encryption interface is: LMKToOther(), and the first decryption interface is: DataDec(); The preset data 6674637873616665 and the second random number 5f6e6ba0b5145677 are encrypted using the saved master key F2D9673A260747A1B24D6F9DD90559EC to obtain the second working key: C21047EE3761BF44E3C9676C9226B7BD; the first ciphertext of the data to be processed 2E90841D587CD596D6E0EAE368E77AE7 is decrypted using the second working key C21047EE3761BF44E3C9676C9226B7BD to obtain the data to be processed: 12345678901234561234567890123456; Step 206: The HSM encrypts the data to be processed using the stored bank key to obtain a second ciphertext of the data to be processed, and returns the second ciphertext of the data to be processed to the push service; Specifically, in this embodiment, the HSM encrypts the data to be processed using the stored bank key via the fourth encryption interface to obtain a second ciphertext of the data to be processed; For example, in this embodiment, the fourth encryption interface is: DataEnc(); The HSM uses the bank key 69A0D910B052E3C95027E630D43E16B1 to encrypt the data to be processed 12345678901234561234567890123456 to obtain the second ciphertext of the data to be processed F1515A3EFA7DAA0D4C0DBCA112147F68; Step 207: The push service forwards the received second ciphertext of the data to be processed to the acquiring institution; For example, in this embodiment, the ciphertext of the data to be processed forwarded by the push service to the acquirer is F1515A3EFA7DAA0D4C0DBCA112147F68; Step 208: The push service receives the first ciphertext data returned by the acquirer and forwards it to the HSM; For example, the first ciphertext data received by the push service in step 208 is B89E7B90F39B0C99E38F3C8280D6D2D5; Step 209: The HSM decrypts the first ciphertext data using the stored bank key, and obtains a processing result if the decryption is successful. Specifically, in this embodiment, the HSM decrypts the first ciphertext data using the stored bank key via the first decryption interface; For example, the processing result obtained by successful decryption in step 209 is 1111111111111111111111111111111111; Step 210: The HSM generates a third random number, uses the stored master key to encrypt the preset data and the third random number to obtain a third working key, and uses the third working key to encrypt the processing result to obtain a ciphertext of the processing result. Specifically, in this embodiment, the HSM generates a third random number through a fourth generation interface, encrypts the preset data and the third random number using the stored master key through a fourth encryption interface to obtain a third working key, and encrypts the processing result using the third working key through the fourth encryption interface to obtain a processing result ciphertext; for example, the fourth generation interface is: genRandom(); In this embodiment, the third random number generated in step 210 is 6012b81296344367. The HSM uses the master key F2D9673A260747A1B24D6F9DD90559EC to encrypt the preset data 6674637873616665 and the third random number 6012b81296344367 to obtain a third working key of 9AE692AD8FD2D0FA8B6D41C316417AB6. The processing result 1111111111111111111111111111111111111 using the third working key 9AE692AD8FD2D0FA8B6D41C316417AB6 is encrypted to obtain a ciphertext of the processing result 55BBBD2B9CE41AC799A4AD39F4BD8B27. Step 211: The HSM sends the ciphertext of the processing result and the third random number to the push service, and clears the second working key and the third working key; For example, in this embodiment, the ciphertext of the processing result sent by the HSM to the push service in step 211 is 55BBBD2B9CE41AC799A4AD39F4BD8B27, and the third random number is 6012b81296344367; Step 212: The push service forwards the ciphertext of the processing result and the third random number to the SDK; Step 213: The SDK sends the third random number and the preset data to the Keystore; For example, in this embodiment, the third random number sent by the SDK to the Keystore in step 213 is 6012b81296344367, and the preset data is 6674637873616665; Step 214: Keystore uses the obtained master key to encrypt the received preset data and the third random number to obtain a fourth working key, returns the fourth working key to the SDK, and clears the first working key and the fourth working key. For example, in this embodiment, in step 214, the Keystore uses the master key F2D9673A260747A1B24D6F9DD90559EC to encrypt the preset data 6674637873616665 and the third random number 6012b81296344367 to obtain the fourth working key 9AE692AD8FD2D0FA8B6D41C316417AB6; The Keystore in this embodiment uses the stored master key through the second encryption interface to encrypt the received preset data and the third random number to obtain the fourth working key; Step 215: The SDK decrypts the ciphertext of the processing result using the received fourth working key. If the decryption is successful, the SDK obtains the processing result. The SDK performs subsequent operations based on the processing result and clears the received first working key and fourth working key. The SDK in this embodiment decrypts the encrypted processing result using the received fourth working key through the second encryption interface; For example, in this embodiment, in step 215, the SDK uses the fourth working key 9AE692AD8FD2D0FA8B6D41C316417AB6 to decrypt the encrypted processing result 55BBBD2B9CE41AC799A4AD39F4BD8B27. The decryption is successful to obtain the processing result 1111111111111111111111111111111111111111; In this embodiment, the processing result includes transaction success or transaction failure.

[0029] Example 3 A third embodiment of the present invention provides a device for implementing key import and key usage, which is applied to a mobile device including a SoftPOS and a Keystore. The device is specifically provided in the SoftPOS and integrated into an upper-layer application in the SoftPOS or provided independently of the upper-layer application. The device includes a key import module and a key usage module. The key import module includes: The first receiving and forwarding unit is configured to call the first interface of the Keystore when the key import interface is called by the upper-layer application, and forward the certificate chain returned by the first interface to the push service; The first receiving unit is configured to receive a first encryption result, a first random number, a second encryption result, and label data returned by the HSM and forwarded by the push service; the first encryption result is obtained by encrypting a first key generated by the HSM using the encapsulated public key in the first certificate in the certificate chain; the second encryption result and label data are obtained by processing a first random number and a master key generated by the HSM using the first key; A first sending unit is configured to send the first encryption result, the first random number, the second encryption result, and the tag data to the Keystore for verification. If the verification passes, the generated master key identifier and the master key obtained by decrypting the second encryption result by the Keystore are stored in the Keystore in correspondence with each other; The key usage module includes: A first sending and receiving unit is configured to send the master key identifier, the built-in preset data, and the generated second random number to the Keystore when the key encryption interface is called by the upper-layer application, and receive a first working key returned by the Keystore, which is obtained by encrypting the preset data and the second random number using the master key corresponding to the master key identifier; A first encryption and sending unit is configured to encrypt the data to be processed using the first working key to obtain a first ciphertext of the data to be processed, and send the preset data, the second random number, and the first ciphertext of the data to be processed to the push service; A second receiving and forwarding unit is configured to receive the ciphertext of the processing result and the third random number returned by the HSM and forwarded by the push service; A sending and receiving decryption unit is used to send the third random number and preset data to the Keystore, receive the fourth working key returned by the Keystore, which is obtained by encrypting the preset data and the third random number using the master key corresponding to the master key identifier, use the fourth working key to decrypt the processing result ciphertext, obtain the processing result upon successful decryption, perform subsequent operations based on the processing result, and clear the first working key and the fourth working key.

[0030] The implementation functions of the push service, HSM and Keystore in this embodiment can refer to Example 1 and Example 2, and will not be repeated here.

[0031] Optionally, an embodiment of the present application further provides an electronic device, comprising at least one processor, a memory, and instructions stored in the memory and executable by the at least one processor, wherein the at least one processor executes the instructions to implement the key import and key use implementation methods of the above-mentioned embodiments. When the electronic device is a chip system, it may be composed of a chip, or may include a chip and other discrete devices, which is not specifically limited in the embodiments of the present application; the chip is coupled to the memory and is used to execute a computer program stored in the memory to execute the key import and key use implementation methods disclosed in the above-mentioned embodiments.

[0032] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented using a software program, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs. When the computer program is loaded and executed on an electronic device, the method flow or function described in the embodiment of the present application is generated in whole or in part. The computer program can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a base station, electronic device, server or data center to another base station, electronic device, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by an electronic device or a data storage device such as a server or data center that includes one or more media that can be integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)).

[0033] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art can understand and implement other changes to the disclosed embodiments by reviewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple situations. A single processor or other unit can implement several functions listed in the claims. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0034] Although the present application has been described with reference to specific features and embodiments thereof, it is apparent that various modifications and combinations may be made thereto without departing from the spirit and scope of the present application. Accordingly, this specification and the drawings are merely illustrative of the present application as defined by the appended claims and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the spirit and scope of the present application. Thus, the present application is intended to include such modifications and variations as fall within the scope of the claims of the present application and their equivalents.

Claims

1. A method for implementing key import and key use, characterized in that: Applicable to a mobile device including a SoftPOS and a Keystore, wherein the SoftPOS includes an upper layer application and an SDK, wherein the SDK is integrated into the upper layer application or is independently configured with the upper layer application, wherein the method includes a key import process and a key use process, wherein the key import process includes: Step S1: When the key import interface of the SDK is called by the upper-layer application, the SDK calls the first interface of the Keystore and forwards the certificate chain returned by the first interface to the push service; Step S2: The SDK receives the first encryption result, the first random number, the second encryption result and the label data returned by the push service forwarding HSM; the first encryption result is obtained by encrypting the first key generated by the HSM using the encapsulated public key in the first certificate of the certificate chain, and the second encryption result and the label data are obtained by processing the first random number and the master key generated by the HSM using the first key; Step S3: the SDK sends the first encryption result, the first random number, the second encryption result, and the tag data to the Keystore for verification. If the verification is successful, the SDK stores the generated master key identifier and the master key obtained by decrypting the second encryption result through the Keystore in the Keystore in correspondence. The key usage process includes: Step T1: When the key encryption interface of the SDK is called by the upper-layer application, the SDK sends the master key identifier, the built-in preset data and the generated second random number to the Keystore, and receives the first working key returned by the Keystore, which is obtained by encrypting the preset data and the second random number using the master key corresponding to the master key identifier; Step T2: the SDK uses the first working key to encrypt the data to be processed to obtain a first ciphertext of the data to be processed, and sends the preset data, the second random number and the first ciphertext of the data to be processed to the push service; Step T3: the SDK receives the processing result ciphertext and the third random number returned by the HSM and forwarded by the push service; Step T4: The SDK sends the third random number and the preset data to the Keystore, receives the fourth working key returned by the Keystore, which is obtained by encrypting the preset data and the third random number using the master key corresponding to the master key identifier, uses the fourth working key to decrypt the processing result ciphertext, obtains the processing result after successful decryption, performs subsequent operations based on the processing result, and clears the first working key and the fourth working key.

2. The method for implementing key import and key use according to claim 1, characterized in that: After the SDK calls the first interface of the Keystore, it also includes: when the first interface of the Keystore is called, the Keystore generates and saves an encapsulation key pair, generates a first certificate according to the encapsulation public key in the encapsulation key pair, generates a certificate chain according to the first certificate, and returns the certificate chain to the SDK.

3. The method for implementing key import and key use according to claim 1, characterized in that: The step S1 and the step S2 also include: Step B1: the push service verifies the received certificate chain using the verification certificate. If the verification succeeds, the encapsulated public key in the first certificate in the certificate chain is imported into the HSM, and step B2 is executed. If the verification fails, verification failure information is returned to the SDK. Step B2: the HSM saves the encapsulated public key, generates a first key, and uses the encapsulated public key to encrypt the first key to obtain a first encryption result; Step B3: the HSM generates and stores a master key, and uses the first key to process the master key and the generated first random number in a preset mode according to a first preset algorithm to obtain label data and a second encryption result; Step B4: the HSM returns the first encryption result, the second encryption result, the first random number and the label data to the push service; Step B5: The push service receives the first encryption result, the second encryption result, the first random number and the tag data and forwards them to the SDK.

4. The method for implementing key import and key use according to claim 3, characterized in that: The certificate chain includes a first certificate, a second certificate, a third certificate and a fourth certificate, and step B1 includes: Step B11: the push service verifies the third certificate using the public key in the fourth certificate. If the verification succeeds, step B12 is executed. If the verification fails, verification failure information is returned to the SDK. Step B12: the push service verifies the second certificate using the public key in the third certificate. If the verification succeeds, step B13 is executed. If the verification fails, verification failure information is returned to the SDK. Step B13: the push service verifies the first certificate using the public key in the second certificate. If the verification succeeds, step B14 is executed. If the verification fails, verification failure information is returned to the SDK. Step B14: the push service determines whether the status of the verification certificate is valid, and if so, executes step B15, otherwise returns verification failure information to the SDK; Step B15: The push service determines whether the public key in the fourth certificate is consistent with the public key in the verification certificate. If so, the public key in the first certificate is imported into the HSM. If the verification fails, verification failure information is returned to the SDK.

5. The method for implementing key import and key use according to claim 4, characterized in that: Before step B14, the method further includes: the push service obtains and updates the status of the verification certificate according to a preset designated website at a preset time interval.

6. The method for implementing key import and key use as claimed in claim 4, characterized in that: Before step B14, the push service also includes: obtaining a verification certificate revocation list according to a preset designated website, determining whether the fourth certificate is in the verification certificate revocation list, and if so, returning verification failure information to the SDK, otherwise executing step B14; and / or Before step B15, the method further includes: determining whether the fourth certificate is within the validity period, if yes, executing step B15, otherwise reporting an error.

7. The method for implementing key import and key use according to claim 3, characterized in that: Before step B1, the method further includes: the push service downloading the verification certificate according to a preset designated website.

8. The method for implementing key import and key use as claimed in claim 3, characterized in that: The step B5 includes: the push service receives the first encryption result, the first random number, the second encryption result and the label data returned by the HSM and assembles them according to a preset format, and sends the assembled result to the SDK.

9. The method for implementing key import and key use according to claim 8, characterized in that: The step S3 comprises: Step S31: the SDK generates a master key identifier, and sends the master key identifier and the assembly result to the Keystore; Step S32: the Keystore determines whether the format of the assembly result is legal, and if so, executes step S33, otherwise, returns an error message to the SDK; Step S33: the Keystore parses the assembly result to obtain a first encryption result, a second encryption result, a first random number and label data, decrypts the first encryption result using the encapsulation private key in the stored encapsulation key pair, obtains the first key upon successful decryption, and generates label data according to the second encryption result and the first random number; Step S34: the Keystore determines whether the generated tag data is the same as the tag data obtained by parsing, and if so, executes step S35, otherwise, returns an error message to the SDK; Step S35: the Keystore uses the first key to decrypt the second encryption result, and stores the decrypted master key and the master key identifier in correspondence with each other.

10. The method for implementing key import and key use according to claim 1, characterized in that: After sending the master key identifier, built-in preset data and the generated second random number to the Keystore in step T1, the Keystore also includes: obtaining the corresponding saved master key according to the received master key identifier, using the master key to encrypt the received preset data and the second random number to obtain a first working key, and returning the first working key to the SDK.

11. The method for implementing key import and key use according to claim 1, characterized in that: The step T2 and the step T3 also include: Step Y1: the push service receives the preset data, the second random number and the first ciphertext of the data to be processed and forwards them to the HSM; Step Y2: the HSM uses the saved master key to encrypt the received preset data and the second random number to obtain a second working key, uses the second working key to decrypt the received first ciphertext of the data to be processed, decrypts successfully to obtain the data to be processed, uses the saved bank key to encrypt the data to be processed to obtain a second ciphertext of the data to be processed, and returns the second ciphertext of the data to be processed to the push service; Step Y3: the push service receives the second ciphertext of the data to be processed returned by the HSM, forwards the second ciphertext of the data to be processed to the acquirer, receives the first ciphertext data returned by the acquirer and forwards it to the HSM; Step Y4: the HSM uses the stored bank key to decrypt the received first ciphertext data, and obtains a processing result if the decryption is successful; Step Y5: the HSM generates a third random number, uses the saved master key to encrypt the preset data and the third random number to obtain a third working key, uses the third working key to encrypt the processing result to obtain a processing result ciphertext, sends the processing result ciphertext and the third random number to the push service, and clears the second working key and the third working key; Step Y6: The push service receives the processing result ciphertext and the third random number returned by the HSM and forwards them to the SDK, and clears the second working key and the third working key.

12. The method for implementing key import and key use according to claim 1, characterized in that: The step T4 in which the SDK sends the third random number and the preset data to the Keystore and receives the fourth working key returned by the Keystore by encrypting the preset data and the third random number with the master key also includes: the Keystore uses the saved master key to encrypt the received preset data and the third random number to obtain a fourth working key, returns the fourth working key to the SDK, and clears the first working key and the fourth working key.

13. A device for implementing key import and key use, characterized in that: Applied to a mobile device including a SoftPOS and a Keystore, the device is specifically arranged in the SoftPOS, integrated into an upper layer application in the SoftPOS or arranged independently from the upper layer application, the device includes a key import module and a key use module, and the key import module includes: A first receiving and forwarding unit, configured to call a first interface of the Keystore when the key import interface is called by the upper layer application, and forward the certificate chain returned by the first interface to the push service; The first receiving unit is used to receive the first encryption result, the first random number, the second encryption result and the label data returned by the push service forwarding HSM; the first encryption result is obtained by encrypting the first key generated by the HSM using the encapsulated public key in the first certificate of the certificate chain, and the second encryption result and the label data are obtained by processing the first random number and the master key generated by the HSM using the first key; A first sending unit, used for sending the first encryption result, the first random number, the second encryption result, and the label data to the Keystore for verification, and if the verification is successful, storing the generated master key identifier and the master key obtained by decrypting the second encryption result by the Keystore in the Keystore in correspondence; The key use module includes: A first sending and receiving unit is used to send the master key identifier, the built-in preset data and the generated second random number to the Keystore when the key encryption interface is called by the upper layer application, and receive a first working key returned by the Keystore that is obtained by encrypting the preset data and the second random number using the master key corresponding to the master key identifier; A first encryption and sending unit, configured to encrypt the data to be processed using the first working key to obtain a first ciphertext of the data to be processed, and send the preset data, the second random number and the first ciphertext of the data to be processed to the push service; A second receiving and forwarding unit, configured to receive the processing result ciphertext and the third random number returned by the HSM and forwarded by the push service; a sending and receiving decryption unit, used for sending the third random number and the preset data to the Keystore, receiving a fourth working key returned by the Keystore, which is obtained by encrypting the preset data and the third random number using the master key corresponding to the master key identifier, decrypting the processing result ciphertext using the fourth working key, obtaining a processing result upon successful decryption, performing subsequent operations according to the processing result, and clearing the first working key and the fourth working key.

14. 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, and the at least one processor executes the instructions to implement the method according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that: The computer-readable storage medium comprises a computer program, and when the computer program is executed on an electronic device, the electronic device is caused to execute the method according to any one of claims 1 to 12.

16. A chip system, characterized in that: The invention comprises a chip, wherein the chip is coupled to a memory and is used to execute a computer program stored in the memory to execute the method according to any one of claims 1 to 12.

Images