Implementation method and apparatus for key import and key usage

Abstract

Disclosed in the present disclosure are an implementation method and apparatus for key import and key usage. When a key import interface of an SDK is invoked by an upper-layer application, a certificate chain generated by KeyStore is sent to a push service; and a first encryption result, a first random number, a second encryption result and tag data which are returned by the push service are sent to KeyStore for verification, and if the verification is passed, a main key identifier and a main key which is obtained by means of KeyStore decrypting the second encryption result are correspondingly stored in KeyStore. When a key encryption interface of the SDK is invoked by the upper-layer application, a first working key returned by KeyStore is used to encrypt data to be processed, so as to obtain a first ciphertext of the data to be processed, which is then sent to the push service together with preset data and a second random number; a processing result ciphertext and a third random number which are returned by the push service are received; and a fourth working key returned by KeyStore is used to decrypt the processing result ciphertext, and on the basis of a processing result obtained by means of successful decryption, subsequent operations are performed.

Description

A method and apparatus for key import and key usage Cross-referencing

[0001] This application claims priority to Chinese patent application No. 202411774048.8, filed on December 5, 2024, entitled “A method and apparatus for implementing key import and key use”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of information security, and in particular to a method and apparatus for implementing key import and key use. Background Technology

[0003] SoftPOS (Software POS) refers to a technology that uses software applications and mobile devices (such as smartphones and tablets) to complete retail transaction processing. A SoftPOS system typically includes an application that accepts credit and debit card payments by connecting to a payment service provider's network. Compared to traditional POS devices, SoftPOS lacks a Safe Module (SM) secure area, and the PCI MPoC specification requires that the master key cannot appear in memory. Therefore, ensuring the security of keys within a SoftPOS system is a critical issue that needs to be addressed. Summary of the Invention

[0004] The purpose of this disclosure is to overcome the shortcomings of the prior art and provide a method and apparatus for implementing key import and key use.

[0005] In a first aspect, embodiments of this disclosure provide a method for implementing key import and key usage, applicable to mobile devices including SoftPOS and Keystore. The SoftPOS includes an upper-layer application and an SDK, wherein the SDK is integrated into the upper-layer application or set up independently of the upper-layer application. The method includes a key import process and a key usage process. The key import process includes:

[0006] 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;

[0007] Step S2: The SDK receives the first encryption result, the first random number, the second encryption result, and the tag data returned by the push service forwarding HSM; the first encryption result is obtained by the HSM encrypting the first key generated by using the encapsulated public key in the first certificate of the certificate chain; the second encryption result and the tag data are obtained by the HSM processing the first random number and the master key generated by using the first key.

[0008] 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.

[0009] The key usage process includes:

[0010] 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 built-in preset data and the second random number using the master key corresponding to the master key identifier;

[0011] Step T2: The SDK uses the first working key to encrypt the data to be processed to obtain the 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;

[0012] Step T3: The SDK receives the encrypted processing result returned by the HSM and the third random number forwarded by the push service;

[0013] 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, and uses the fourth working key to decrypt the ciphertext of the processing result. If the decryption is successful, the processing result is obtained. Subsequent operations are performed based on the processing result, and the first working key and the fourth working key are cleared.

[0014] Secondly, this disclosure provides a key import and key usage implementation apparatus, applied in a mobile device including SoftPOS and Keystore. The apparatus is specifically configured within the SoftPOS, integrated into an upper-layer application within the SoftPOS, or configured independently of the upper-layer application. The apparatus includes a key import module and a key usage module. The key import module includes:

[0015] The first receiving and forwarding unit is used to call the first interface of 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.

[0016] The first receiving unit is configured to receive a first encryption result, a first random number, a second encryption result, and tag data returned by the push service forwarding the HSM; the first encryption result is obtained by the HSM encrypting a first key generated by using the encapsulated public key in the first certificate of the certificate chain, and the second encryption result and tag data are obtained by the HSM processing the first random number and master key generated by using the first key;

[0017] The first sending unit is used 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 is successful, the generated master key identifier and the master key obtained by decrypting the second encryption result through the Keystore are stored in the Keystore.

[0018] The key usage module includes:

[0019] The first sending and receiving unit is used to send the master key identifier, built-in preset data and generated second random number to the Keystore when the key encryption interface is called by the upper layer application, and to receive the first working key returned by the Keystore, which is obtained by encrypting the built-in preset data and the second random number using the master key corresponding to the master key identifier.

[0020] The first encryption sending unit is used to encrypt the data to be processed using the first working key to obtain the 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;

[0021] The second receiving and forwarding unit is used to receive the ciphertext of the processing result returned by the HSM and the third random number forwarded by the push service;

[0022] The sending, receiving, and decryption unit is used to send the third random number and the built-in preset data to the Keystore, receive 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, decrypt the ciphertext of the processing result using the fourth working key, 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.

[0023] Thirdly, embodiments of this disclosure also 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.

[0024] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium comprising a computer program that, when executed on an electronic device, causes the electronic device to perform any of the methods described above.

[0025] Fifthly, embodiments of this disclosure also provide a chip system, including a chip coupled to a memory for executing a computer program stored in the memory to perform the method described in any of the preceding embodiments.

[0026] Compared with the prior art, this disclosure has the following advantages: The technical solution of this disclosure uses a Keystore to store the master key, and the master key exists in encrypted form during transmission and when it is entered into the Keystore. A working key is generated based on the master key in the Keystore, and the working key is used to perform data processing. After processing, the working key is cleared. The working key is different for each processing process, which achieves simplicity and security. Attached Figure Description

[0027] Figure 1 is a flowchart of a method for implementing key import and key usage according to Embodiment 1 of this disclosure;

[0028] Figure 2 is a schematic diagram of the system framework applicable to the implementation method of key import and key use provided in Embodiment 2 of this disclosure;

[0029] Figure 3 is a flowchart of the key import process of a key import and key usage implementation method provided in Embodiment 2 of this disclosure;

[0030] Figure 4 is a flowchart of the key usage process of a key import and key usage implementation method provided in Embodiment 2 of this disclosure. Detailed Implementation

[0031] This application proposes a method and apparatus for key import and key usage. The specific embodiments 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.

[0032] 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.

[0033] To make the objectives, technical solutions, and advantages of this disclosure clearer, the embodiments of this disclosure will be described in further detail below with reference to the accompanying drawings.

[0034] In this embodiment, the Keystore is a secure container specifically designed to store keys. The keys in the Keystore are permanent (i.e., they persist even after the application is closed or the device is restarted). These keys are suitable for sensitive information processing such as data encryption, signing, and authentication. The validity period, usage scope, and application restrictions of the keys in the Keystore can be set, ensuring that keys can be securely deleted when no longer needed, making key use safe and reliable. Hardware acceleration and a physical security module (TPM or HSM) are used to protect the keys in the Keystore, preventing key extraction or exposure and enhancing key security.

[0035] Example 1

[0036] Embodiment 1 of this disclosure provides a method for implementing key import and key usage, applicable to mobile devices including Keystore and SoftPOS. 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 set up separately.

[0037] As shown in Figure 1, the method in this embodiment includes a key import process and a key usage process. The key import process includes:

[0038] Step S1: When the SDK's key import interface is called by the upper-layer application, the SDK calls the Keystore's first interface and forwards the certificate chain returned by the first interface to the push service;

[0039] In this embodiment, after the SDK calls the first interface of Keystore, the process further includes: when the first interface of Keystore is called, Keystore generates and saves a sealed key pair, generates a first certificate based on the sealed public key in the sealed key pair, generates a certificate chain based on the first certificate, and returns the certificate chain to the SDK.

[0040] In this embodiment, the step S1 and step S2 are further supplemented by:

[0041] Step B1: The push service uses the verification certificate to verify the received certificate chain. If the verification is successful, 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, the verification failure information is returned to the SDK.

[0042] The certificate chain includes a first certificate, a second certificate, a third certificate, and a fourth certificate. Step B1 includes:

[0043] Step B11: The push service uses the public key in the fourth certificate to verify the third certificate. If the verification is successful, proceed to step B12; if the verification fails, return a verification failure message to the SDK.

[0044] Step B12: The push service uses the public key in the third certificate to verify the second certificate. If the verification is successful, proceed to step B13; if the verification fails, return a verification failure message to the SDK.

[0045] Step B13: The push service uses the public key in the second certificate to verify the first certificate. If the verification is successful, proceed to step B14; if the verification fails, return a verification failure message to the SDK.

[0046] Step B14: The push service determines whether the certificate status is valid. If it is, proceed to step B15; otherwise, return a verification failure message to the SDK.

[0047] Optionally, in this embodiment, before step B14, the method further includes: the push service obtains the status of the verification certificate according to a preset specified URL every preset time interval and updates it;

[0048] Optionally, before step B14, the following steps are also included: the push service obtains the certificate revocation list based on a preset specified URL, determines whether the fourth certificate is in the certificate revocation list, and if so, returns a verification failure message to the SDK; otherwise, steps B14 are executed; and / or before step B15, the following steps are also included: determining whether the fourth certificate is within its validity period, and if so, steps B15 are executed; otherwise, an error is reported.

[0049] 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 they are consistent, the public key in the first certificate is imported into the HSM. If the verification fails, the verification failure information is returned to the SDK.

[0050] Optionally, in this embodiment, before step B1, the push service downloads a verification certificate according to a preset specified URL.

[0051] Step B2: The HSM stores the encapsulation public key, generates the first key, and uses the encapsulation public key to encrypt the first key to obtain the first encryption result;

[0052] Step B3: The HSM generates and saves the master key. According to the first preset algorithm, the first key is used to process the master key and the generated first random number in the preset mode to obtain the tag data and the second encryption result.

[0053] Step B4: HSM returns the first encryption result, the second encryption result, the first random number, and the tag data to the push service;

[0054] Step B5: The push service receives the first encrypted result, the second encrypted result, the first random number, and the tag data, and forwards them to the SDK;

[0055] In this embodiment, step B5 includes: the push service receiving the first encrypted result, the first random number, the second encrypted result, and the tag data returned by the HSM, assembling them according to a preset format, and sending the assembly result to the SDK.

[0056] Step S2: The SDK receives the first encrypted result, the first random number, the second encrypted result, and the tag data returned by the push service forwarding HSM;

[0057] In this embodiment, the first encryption result is obtained by HSM encrypting the first key generated by using the encapsulated public key in the first certificate of the certificate chain, and the second encryption result and tag data are obtained by HSM processing the first random number and master key generated by using the first key.

[0058] 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 in the Keystore along with the master key obtained by decrypting the second encryption result through the Keystore.

[0059] Specifically, in this embodiment, step S3 includes:

[0060] Step S31: The SDK generates a master key identifier and sends the master key identifier and the assembly result to the Keystore;

[0061] Step S32: The Keystore determines whether the format of the assembled result is valid. If it is, proceed to step S33; otherwise, return an error message to the SDK.

[0062] Step S33: The Keystore parses the assembly result to obtain the first encryption result, the second encryption result, the first random number and the tag data. It uses the private key in the saved encapsulation key pair to decrypt the first encryption result. If the decryption is successful, the first key is obtained. The tag data is generated according to the second encryption result and the first random number.

[0063] Step S34: The Keystore determines whether the generated tag data is the same as the parsed tag data. If yes, proceed to step S35; otherwise, return an error message to the SDK.

[0064] Step S35: Keystore uses the first key to decrypt the second encryption result and saves the decrypted master key and master key identifier accordingly.

[0065] The key usage process includes:

[0066] Step T1: When the SDK's key encryption interface 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.

[0067] In this embodiment, after sending the master key identifier, the built-in preset data and the generated second random number to the Keystore in step T1, the method further includes: the Keystore obtains the corresponding saved master key according to the received master key identifier, uses the master key to encrypt the received preset data and the second random number to obtain the first working key, and returns the first working key to the SDK.

[0068] Step T2: The SDK uses the first working key to encrypt the data to be processed 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;

[0069] In this embodiment, the step between step T2 and step T3 further includes:

[0070] Step Y1: The push service receives the preset data, the second random number, and the first encrypted data to be processed and forwards it to the HSM;

[0071] Step Y2: HSM uses the saved master key to encrypt the received preset data and the second random number to obtain the second working key. It uses the second working key to decrypt the received first data to be processed ciphertext. If the decryption is successful, the data to be processed is obtained. It uses the saved bank key to encrypt the data to be processed to obtain the second data to be processed ciphertext. The second data to be processed ciphertext is returned to the push service.

[0072] Step Y3: The push service receives the second encrypted data to be processed returned by the HSM, forwards the second encrypted data to the acquiring institution, receives the first encrypted data returned by the acquiring institution and forwards it to the HSM;

[0073] Step Y4: HSM uses the stored bank key to decrypt the received first ciphertext data. If the decryption is successful, the processing result is obtained.

[0074] 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 the third working key, uses the third working key to encrypt the processing result to obtain the ciphertext of the processing result, 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.

[0075] Step Y6: The push service receives the ciphertext of the processing result returned by the HSM and the third random number and forwards it to the SDK, clearing the second working key and the third working key.

[0076] Step T3: The SDK receives the encrypted processing result returned by the HSM forwarded by the push service and the third random number;

[0077] 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, and uses the fourth working key to decrypt the ciphertext of the processing result. If the decryption is successful, the processing result is obtained. Subsequent operations are performed based on the processing result, and the first working key and the fourth working key are cleared.

[0078] In this embodiment, between the SDK sending the third random number and preset data to the Keystore in step T4 and receiving 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, the Keystore further includes: using the stored master key to encrypt the received preset data and the third random number to obtain the fourth working key, returning the fourth working key to the SDK, and clearing the first working key and the fourth working key.

[0079] In this embodiment, the master key is stored in a keystore and is stored in encrypted form during transmission and when it is passed to the keystore. A working key is generated based on the master key in the keystore. The working key is used for data processing. After processing, the working key is cleared. The working key is different for each processing process, thus achieving simplicity and security.

[0080] Example 2

[0081] This disclosure provides a method for implementing key import and key usage, applicable to systems including Keystore, SDK, push service, and HSM, as shown in Figure 2. The Keystore and SDK are located in the mobile phone. The SDK can be integrated into the upper-layer application of the mobile phone's SoftPOS, or it can be set up independently in the SoftPOS of the mobile phone. The Keystore communicates with the SDK, and both the SDK and the upper-layer application communicate with the push service, which in turn communicates with the HSM. Users can trigger the key generation button in the upper-layer application, after which the upper-layer application calls the SDK's key import interface to perform a key import operation. Alternatively, users can trigger the transaction confirmation button in the upper-layer application, after which the upper-layer application calls the SDK's key encryption interface to use the key to complete the transaction operation.

[0082] As shown in Figure 3, the key import process in this embodiment includes:

[0083] Step 101: When the SDK's key import interface is called by the upper-layer application, the SDK calls the Keystore's first interface;

[0084] In this embodiment, the upper-layer application can be a third-party application or an application from an SDK developer. When the upper-layer application receives the user's import key trigger information, it calls the SDK.

[0085] For example, the first interface in this embodiment is:

[0086] KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_RSA,ANDROID_KEY_STORE);

[0087] KeyGenParameterSpec build = new KeyGenParameterSpec.Builder("0BFA5C2ECE6D486BBC0FC11C9233AB1347B925137FDAAB9AB7D924F6DB616AEB",

[0088] KeyProperties.PURPOSE_WRAP_KEY)

[0089] .setDigests(KeyProperties.DIGEST_SHA256)

[0090] .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_RSA_OAEP)

[0091] .setBlockModes(KeyProperties.BLOCK_MODE_ECB)

[0092] .setIsStrongBoxBacked(true)

[0093] .setAttestationChallenge(challenge)

[0094] .build();

[0095] keyPairGenerator.initialize(build);

[0096] KeyPair keyPair = keyPairGenerator.generateKeyPair();

[0097] Step 102: When the first interface of Keystore is called, Keystore generates a sealed key pair, generates a first certificate based on the sealed public key in the sealed key pair, generates a certificate chain based on the first certificate, and returns the certificate chain;

[0098] 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;

[0099] Step 103: The SDK forwards the certificate chain to the push service;

[0100] Step 104: The push service uses the verification certificate to verify the received certificate chain. If the verification is successful, the encapsulated public key in the first certificate in the certificate chain is imported into the HSM. If the verification fails, the verification failure information is returned to the SDK.

[0101] In this embodiment, before step 104, the method further includes: the push service downloading a verification certificate from Google according to a preset specified URL;

[0102] In this embodiment, the verification certificate is an x509 certificate, and the specified URL is: https: / / developer.android.google.cn / privacy-and-security / security-key-attestation;

[0103] Specifically, step 104 includes:

[0104] 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 is successful, proceed to step A2. If the verification fails, return a verification failure message to the SDK.

[0105] 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 is successful, proceed to step A3; if the verification fails, return a verification failure message to the SDK.

[0106] 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 is successful, proceed to step A4; if the verification fails, return a verification failure message to the SDK.

[0107] Step A4: The push service determines whether the certificate status is valid. If it is, proceed to step A5; otherwise, return a verification failure message to the SDK.

[0108] In this embodiment, the push service retrieves the status of the verification certificate from Google at preset intervals according to a preset specified URL and updates it accordingly;

[0109] Optionally, in this embodiment, before step A4, the following steps are also included: the push service obtains the certificate revocation list from Google according to a preset specified URL, determines whether the fourth certificate in the certificate chain is in the certificate revocation list, and if so, returns a verification failure message to the SDK; otherwise, step A4 is executed.

[0110] 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 they are consistent, the encapsulated public key in the first certificate is imported into the HSM; otherwise, a verification failure message is returned to the SDK.

[0111] Optionally, in this embodiment, before step A5, the method further includes: determining whether the fourth certificate in the certificate chain is valid; if yes, continue to the next step; otherwise, report an error.

[0112] Step 105: The HSM saves the encapsulated public key in the first certificate in the certificate chain, generates the first key, and uses the encapsulated public key in the first certificate to encrypt the first key to obtain the first encryption result;

[0113] The first key in this embodiment is an AES256 key;

[0114] 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;

[0115] For example, the first generation interface is genSymmKey(), and the first encryption interface is LMKToOther().

[0116] For example, in this embodiment, the first key generated is: 1A312F1DF82222D6CE7CD62AC25DCB7B82BB49840DDD8308712E7E4CC6EF97A4, and the first encryption result is: 84788769C6174E5A3DAE247117FA0A663E662DB9DEC672351AF98EC0315B 92C903209D30742D7EF45E7E8CF029A03A6D1555A60F75510127E9CC96E46B4CE09E91E2F74 4A8C47FD4BC90FB63175DFBFD491F089DF7291569C40A119D4509568DB4BEF6918BF5E609AD5 D07ED9DC67548D326BEFA6B83C4AC2CFC31A2830E14573945526356C2C0227DEC1DFD6ACBAB 255050CA5AF74E9866F3038303AD1B80E7969D4FD1210B90FC8A096C736932701A1793FDD55D A59EB78160AE8BC51ECC96A64FF1B50568982FC193E6B6BB8D138EDF9693702CF032B40F07E BB57FC4479CA96D14FF7232E09421B559BD342E211795B572C8EDF002CA4644BA5CDF95ACD9;

[0117] Step 106: HSM generates a master key and a first random number, saves the master key, and uses the first key to encrypt the master key and the first random number in GCM mode according to the AES algorithm to obtain the tag data and the second encryption result;

[0118] In this embodiment, the master key is an AES128 key;

[0119] Specifically, 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 tag data and a second encryption result.

[0120] For example, the second generation interface is genRandom(), and the first processing interface is LMKToOther().

[0121] Specifically, in this embodiment, the tag data and the second encryption result are obtained by encrypting the master key and the first random number using the first key in GCM mode according to the AES algorithm. This includes: segmenting the master key; encrypting each segment of data using the first key according to the AES algorithm; concatenating all encryption results to obtain the second encryption result; performing a preset operation on each encryption result and the first random number and concatenating the results to obtain verification information; and calculating the verification information using the GCM algorithm to obtain the tag data.

[0122] 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;

[0123] Step 107: HSM returns the first encryption result, the second encryption result, the first random number, and the tag data to the push service;

[0124] For example, in this embodiment, the data returned to the push service in step 107 is:

[0125] Step 108: The push service assembles the received first encrypted result, first random number, second encrypted result and tag data according to a preset format, and sends the assembly result to the SDK;

[0126] Specifically, the preset format in this embodiment is ASN.1 format;

[0127] Step 109: The SDK generates a master key identifier and sends the master key identifier and the assembly result to the Keystore;

[0128] In this embodiment, the master key identifier can be a key name or a key ID;

[0129] Step 110: The Keystore checks whether the format of the assembled result is valid. If it is, it proceeds to step 111; otherwise, it returns an error message to the SDK.

[0130] Step 111: The Keystore parses the assembly result to obtain the first encrypted result, the second encrypted result, the first random number, and the tag data. It uses the saved encapsulation private key to decrypt the first encrypted result. If the decryption is successful, the first key is obtained. The tag data is generated based on the second encrypted result and the first random number.

[0131] In this embodiment, generating tag data based on the second encryption result and the first random number includes: segmenting the second encryption result, performing calculations on each segment of data with the first random number, concatenating the calculation results to obtain verification information, and using the GCM algorithm to calculate the verification information to obtain tag data;

[0132] Step 112: The Keystore determines whether the generated tag data is the same as the parsed tag data. If they are the same, proceed to step 113; otherwise, return an error message to the SDK.

[0133] Step 113: Keystore uses the first key to decrypt the second encryption result, and saves the decrypted master key and the received master key identifier accordingly;

[0134] 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 data in the second encryption result, and concatenating all the decrypted results to obtain the master key.

[0135] The key usage process in this embodiment is shown in Figure 4, including:

[0136] Step 201: When the SDK's key encryption interface is called by the 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;

[0137] In this embodiment, the upper-layer application can be a third-party application or a developer's application. When the upper-layer application receives the user's data processing trigger information, it calls the SDK.

[0138] For example, the preset data in this embodiment is: 6674637873616665, and the second random number is: 5f6e6ba0b5145677;

[0139] Step 202: 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 the first working key, and returns the first working key to SDK;

[0140] Specifically, in this embodiment, the Keystore uses the stored master key to encrypt the received preset data and the second random number through the second encryption interface to obtain the first working key;

[0141] For example, in this embodiment, the second encryption interface is: Cipher c = Cipher.getInstance("AES / ECB / NoPadding");

[0142] c.init(Cipher.ENCRYPT_MODE);

[0143] Keystore uses the master key F2D9673A260747A1B24D6F9DD90559EC to encrypt the preset data 6674637873616665 and the second random number 5f6e6ba0b5145677 through the second encryption interface to obtain the first working key C21047EE3761BF44E3C9676C9226B7BD;

[0144] Step 203: The SDK uses the received first working key to encrypt the data to be processed 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;

[0145] In this embodiment, the upper-layer application calls the SDK's key encryption interface with the data to be processed as a parameter;

[0146] In this embodiment, the SDK uses the first working key C21047EE3761BF44E3C9676C9226B7BD to encrypt the data to be processed 12345678901234561234567890123456, and the resulting ciphertext of the first data to be processed is 2E90841D587CD596D6E0EAE368E77AE7;

[0147] Step 204: The push service forwards the preset data, the second random number, and the encrypted first data to be processed to the HSM;

[0148] Step 205: HSM uses the saved master key to encrypt the received preset data and the second random number to obtain the second working key, and uses the second working key to decrypt the received first data to be processed ciphertext. If the decryption is successful, the data to be processed is obtained.

[0149] Specifically, in this embodiment, the HSM uses the stored master key to encrypt the received preset data and the second random number through the third encryption interface to obtain the second working key, and uses the second working key to decrypt the received ciphertext of the data to be processed through the first decryption interface.

[0150] For example, in this embodiment, the third encryption interface is: LMKToOther(), and the first decryption interface is: DataDec();

[0151] The second working key is obtained by encrypting the preset data 6674637873616665 and the second random number 5f6e6ba0b5145677 using the saved master key F2D9673A260747A1B24D6F9DD90559EC. The second working key is C21047EE3761BF44E3C9676C9226B7BD. The first data to be processed, ciphertext 2E90841D587CD596D6E0EAE368E77AE7, is decrypted using the second working key C21047EE3761BF44E3C9676C9226B7BD. The resulting data to be processed is 12345678901234561234567890123456.

[0152] Step 206: HSM uses the stored bank key to encrypt the data to be processed to obtain the second ciphertext of the data to be processed, and returns the second ciphertext of the data to be processed to the push service;

[0153] Specifically, in this embodiment, the HSM uses the stored bank key to encrypt the data to be processed through the fourth encryption interface to obtain the second ciphertext of the data to be processed.

[0154] For example, in this embodiment, the fourth encryption interface is: DataEnc();

[0155] HSM uses bank key 69A0D910B052E3C95027E630D43E16B1 to encrypt the data to be processed 12345678901234561234567890123456, and the ciphertext of the second data to be processed is F1515A3EFA7DAA0D4C0DBCA112147F68;

[0156] Step 207: The push service forwards the received second encrypted data to the acquiring institution;

[0157] For example, in this embodiment, the encrypted data to be processed forwarded by the push service to the acquiring institution is F1515A3EFA7DAA0D4C0DBCA112147F68.

[0158] Step 208: The push service receives the first encrypted data returned by the acquiring institution and forwards it to the HSM;

[0159] For example, the first encrypted data received by the push service in step 208 is B89E7B90F39B0C99E38F3C8280D6D2D5;

[0160] Step 209: HSM uses the stored bank key to decrypt the first ciphertext data. If decryption is successful, the processing result is obtained.

[0161] Specifically, in this embodiment, the HSM uses the stored bank key to decrypt the first ciphertext data through the first decryption interface;

[0162] For example, the processing result obtained after successful decryption in step 209 is 111111111111111111111111111111111;

[0163] Step 210: The HSM generates a third random number, and uses the saved master key to encrypt the preset data and the third random number to obtain the third working key. The third working key is then used to encrypt the processing result to obtain the ciphertext of the processing result.

[0164] 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 the ciphertext of the processing result; for example, the fourth generation interface is: genRandom();

[0165] In this embodiment, the third random number generated in step 210 is 6012b81296344367. HSM uses the master key F2D9673A260747A1B24D6F9DD90559EC to encrypt the preset data 6674637873616665 and the third random number 6012b81296344367 to obtain the third working key: 9AE692AD8FD2D0FA8B6D41C316417AB6. The ciphertext of the processing result 1111111111111111111111111111111111 is obtained by encrypting the processing result ciphertext 55BBBD2B9CE41AC799A4AD39F4BD8B27.

[0166] 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;

[0167] For example, in this embodiment, the encrypted result of the HSM sent to the push service in step 211 is 55BBBD2B9CE41AC799A4AD39F4BD8B27, and the third random number is 6012b81296344367.

[0168] Step 212: The push service forwards the encrypted processing result and the third random number to the SDK;

[0169] Step 213: The SDK sends the third random number and preset data to the Keystore;

[0170] 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;

[0171] Step 214: Keystore uses the obtained 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 SDK, and clears the first working key and the fourth working key.

[0172] For example, in this embodiment, in step 214, 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;

[0173] In this embodiment, the Keystore 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;

[0174] Step 215: The SDK uses the received fourth working key to decrypt the ciphertext of the processing result. If the decryption is successful, the processing result is obtained. Subsequent operations are performed based on the processing result, and the received first working key and fourth working key are cleared.

[0175] In this embodiment, the SDK uses the received fourth working key through the second encryption interface to decrypt the encrypted processing result;

[0176] 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, and the processing result 11111111111111111111111111111111111111;

[0177] In this embodiment, the processing result includes whether the transaction is successful or failed.

[0178] Example 3

[0179] This disclosure provides a key import and key usage implementation device, applied in a mobile device including SoftPOS and Keystore. The device is specifically set in SoftPOS, integrated into the upper-layer application of SoftPOS or set independently of the upper-layer application. The device includes a key import module and a key usage module. The key import module includes:

[0180] The first receiving and forwarding unit is used to call the first interface of 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.

[0181] The first receiving unit is used to receive the first encryption result, the first random number, the second encryption result, and the tag data returned by the push service forwarding HSM; the first encryption result is obtained by HSM encrypting the first key generated by using the encapsulated public key in the first certificate of the certificate chain; the second encryption result and the tag data are obtained by HSM processing the first random number and the master key generated by using the first key.

[0182] The first sending unit is used 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 is successful, the generated master key identifier and the master key obtained by decrypting the second encryption result through the Keystore are stored in the Keystore.

[0183] The key usage module includes:

[0184] The 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 to receive 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.

[0185] The first encryption sending unit is used to encrypt the data to be processed using the first working key to obtain the 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.

[0186] The second receiving and forwarding unit is used to receive the ciphertext of the processing result returned by the HSM forwarded by the push service and the third random number;

[0187] The send-receive-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, decrypt the ciphertext of the processing result using the fourth working key, 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.

[0188] The implementation functions of push service, HSM and Keystore in this embodiment can be referred to in Embodiment 1 and Embodiment 2, and will not be repeated here.

[0189] 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 import and key usage methods described 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 perform the key import and key usage methods disclosed in the above embodiments.

[0190] 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, it generates, in whole or in part, the method flow or function described in accordance with the embodiments of this application. 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 the medium. 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)).

[0191] 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.

[0192] 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 import and key usage, applicable to mobile devices including SoftPOS and Keystore, wherein SoftPOS includes an upper-layer application and a software development kit (SDK), the SDK being integrated into the upper-layer application or set up independently of the upper-layer application, the method including a key import process and a key usage process, the key import process including: 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 tag data returned by the push service forwarding HSM; the first encryption result is obtained by the HSM encrypting the first key generated by using the encapsulated public key in the first certificate of the certificate chain; the second encryption result and the tag data are obtained by the HSM processing the first random number and the master key generated by 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 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 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; Step T3: The SDK receives the encrypted processing result returned by the HSM and the third random number 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, and uses the fourth working key to decrypt the ciphertext of the processing result. If the decryption is successful, the processing result is obtained. Subsequent operations are performed based on the processing result, and the first working key and the fourth working key are cleared.

2. The method of Claim 1, wherein the SDK calling the first interface of the Keystore further comprises, after the SDK calling the first interface of the Keystore: When the first interface of the Keystore is called, the Keystore generates and saves a packaged key pair, generates a first certificate based on the packaged public key in the packaged key pair, generates a certificate chain based on the first certificate, and returns the certificate chain to the SDK.

3. The implementation method for key import and key use as described in claim 1, wherein the step S1 and the step S2 further include: Step B1: The push service uses the verification certificate to verify the received certificate chain. If the verification is successful, 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, the verification failure information is returned to the SDK. Step B2: The HSM stores the encapsulation public key, generates a first key, and uses the encapsulation public key to encrypt the first key to obtain a first encryption result; Step B3: The HSM generates and saves a master key, and processes the master key and the generated first random number using the first key in a preset mode according to the first preset algorithm to obtain tag 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 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.

4. The implementation method for key import and key use as described in claim 3, wherein 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 uses the public key in the fourth certificate to verify the third certificate. If the verification is successful, proceed to step B12; if the verification fails, return a verification failure message to the SDK. Step B12: The push service uses the public key in the third certificate to verify the second certificate. If the verification is successful, proceed to step B13; if the verification fails, return a verification failure message to the SDK. Step B13: The push service uses the public key in the second certificate to verify the first certificate. If the verification is successful, proceed to step B14; if the verification fails, return a verification failure message to the SDK. Step B14: The push service determines whether the status of the verification certificate is valid. If it is, it executes step B15; otherwise, it returns a verification failure message 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 they are consistent, the public key in the first certificate is imported into the HSM. If the verification fails, the verification failure information is returned to the SDK.

5. The implementation method for key import and key use as described in claim 4, wherein the method further comprises, before step B14: The push service retrieves and updates the status of the verification certificate at preset intervals based on a preset specified URL.

6. The method of claim 4, wherein the step B14 is further preceded by: The push service obtains the certificate revocation list based on a preset specified URL, determines whether the fourth certificate is in the certificate revocation list, and if so, returns a verification failure message to the SDK; otherwise, it executes step B14. and / or Before step B15, the method further includes: determining whether the fourth certificate is valid; if yes, proceeding to step B15; otherwise, reporting an error.

7. The method of claim 3, wherein the step Bl is preceded by the further step of: B0. receiving a request for a key import and key usage implementation from a user. The push service downloads the verification certificate from a preset specified URL. ​ 8. The method of claim 3, wherein the step B5 comprises: The push service receives the first encrypted result, the first random number, the second encrypted result, and the tag data returned by the HSM, assembles them according to a preset format, and sends the assembled result to the SDK.

9. The implementation method for key import and key use as described in claim 8, wherein step S3 includes: 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 valid. If it is, step S33 is executed; otherwise, an error message is returned to the SDK. Step S33: The Keystore parses the assembly result to obtain a first encrypted result, a second encrypted result, a first random number, and tag data. It uses the private key in the saved encapsulation key pair to decrypt the first encrypted result. If the decryption is successful, the first key is obtained. Tag data is generated based on the second encrypted result and the first random number. Step S34: The 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: The Keystore uses the first key to decrypt the second encryption result, and saves the decrypted master key and the master key identifier accordingly.

10. The method of claim 1, wherein the sending of the master key identification, the built-in preset data, and the generated second random number to the Keystore in the step Tl further comprises: The Keystore obtains the corresponding stored 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. ​ 11. The implementation method for key import and key use according to claim 1, wherein the step T2 and the step T3 further include: Step Y1: The push service receives the preset data, the second random number, and the first encrypted 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 the second working key, uses the second working key to decrypt the received first data to be processed ciphertext, and obtains the data to be processed after successful decryption. The HSM uses the stored bank key to encrypt the data to be processed to obtain the second data to be processed ciphertext, and returns the second data to be processed ciphertext to the push service. Step Y3: The push service receives the second encrypted data to be processed returned by the HSM, forwards the second encrypted data to be processed to the acquiring institution, receives the first encrypted data returned by the acquiring institution and forwards it to the HSM; Step Y4: The HSM uses the stored bank key to decrypt the received first ciphertext data. If the decryption is successful, the processing result is obtained. Step Y5: The HSM generates a third random number, encrypts the preset data and the third random number using the saved master key to obtain a third working key, encrypts the processing result using the third working key to obtain the ciphertext of the processing result, 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; Step Y6: The push service receives the ciphertext of the processing result returned by the HSM and the third random number and forwards it to the SDK, clearing the second working key and the third working key.

12. The method of claim 1, wherein the sending of the third random number and the preset data to the Keystore and receiving of the fourth working key encrypted with the master key from the Keystore by the SDK in step T4 further comprises: The Keystore uses the stored 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. An apparatus for implementing key import and key usage, applied in a mobile device including SoftPOS and Keystore, wherein the apparatus is specifically disposed in the SoftPOS, integrated into an upper-layer application in the SoftPOS or disposed independently of the upper-layer application, the apparatus comprising a first processor and a second processor, a memory, and instructions stored in the memory and executable by the first processor and the second processor, wherein the first processor executes the instructions to perform the following operations: When the key import interface is called by the upper-layer application, the first interface of Keystore is called, and the certificate chain returned by the first interface is forwarded to the push service; The push service forwards the HSM and receives a first encryption result, a first random number, a second encryption result, and tag data returned by the HSM. The first encryption result is obtained by the HSM encrypting a first key generated using the encapsulated public key in the first certificate of the certificate chain. The second encryption result and tag data are obtained by the HSM processing the first random number and master key generated using the first key. The first encryption result, the first random number, the second encryption result, and the tag data are sent to the Keystore for verification. If the verification is successful, the generated master key identifier and the master key obtained by decrypting the second encryption result through the Keystore are stored in the Keystore. The second processor executes the instructions to perform the following operations: When the key encryption interface is called by the upper-layer application, the master key identifier, the built-in preset data and the generated second random number are sent to the Keystore, and the first working key returned by the Keystore is obtained by encrypting the preset data and the second random number using the master key corresponding to the master key identifier. The first working key is used to encrypt the data to be processed to obtain the first ciphertext of the data to be processed, and the preset data, the second random number and the first ciphertext of the data to be processed are sent to the push service. Receive the encrypted processing result returned by the HSM and the third random number forwarded by the push service; The third random number and the preset data are sent to the Keystore. The Keystore returns a fourth working key obtained by encrypting the preset data and the third random number using the master key corresponding to the master key identifier. The fourth working key is used to decrypt the ciphertext of the processing result. If the decryption is successful, the processing result is obtained. Subsequent operations are performed based on the processing result, and the first working key and the fourth working key are cleared.

14. An electronic device, comprising: The electronic device includes 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 method according to any one of claims 1 to 12.

15. 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 12.

16. A chip system, characterized by 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-12.

Images