WO2022078367A1 - 支付密钥的加密和解密方法、支付认证方法及终端设备 - Google Patents

支付密钥的加密和解密方法、支付认证方法及终端设备 Download PDF

Info

Publication number
WO2022078367A1
WO2022078367A1 PCT/CN2021/123462 CN2021123462W WO2022078367A1 WO 2022078367 A1 WO2022078367 A1 WO 2022078367A1 CN 2021123462 W CN2021123462 W CN 2021123462W WO 2022078367 A1 WO2022078367 A1 WO 2022078367A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
payment
service system
background service
ciphertext
Prior art date
Application number
PCT/CN2021/123462
Other languages
English (en)
French (fr)
Inventor
王欢
周爱平
陈囿任
Original Assignee
深圳市百富智能新技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳市百富智能新技术有限公司 filed Critical 深圳市百富智能新技术有限公司
Priority to US18/027,962 priority Critical patent/US20230368194A1/en
Publication of WO2022078367A1 publication Critical patent/WO2022078367A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G06Q20/40145—Biometric identity checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • the present application belongs to the technical field of secret keys, and in particular relates to a payment key encryption and decryption method, a payment authentication method and a terminal device.
  • a key is a parameter that is entered in an algorithm that converts plaintext to ciphertext or converts ciphertext to plaintext. Keys are divided into symmetric keys and asymmetric keys. Symmetric key is also known as private key or session key. The sender and receiver of information use the same key to encrypt and decrypt data. Its biggest advantage is that the encryption/decryption speed is fast, and it is suitable for encrypting large amounts of data. But key management is difficult.
  • Asymmetric keys, also known as public keys need to use different keys to complete encryption and decryption operations respectively, one is publicly released, that is, the public key, and the other is kept secretly by the user, that is, the private key, which is the sender of the information.
  • the public key is used to encrypt, and the information receiver uses the private key to decrypt.
  • the asymmetric key mechanism is flexible, but the encryption and decryption speed is much slower than the symmetric key. In practical applications, symmetric keys and asymmetric keys are usually used together. Symmetric keys are used to store a large amount of data information, while asymmetric keys are used to encrypt keys. Keys are widely used in the field of electronic payment. Protecting electronic payment keys from exposure and unauthorized use is the key to ensuring the security of electronic payments.
  • the embodiments of the present application provide a payment key encryption and decryption method, a payment authentication method and a terminal device, which can encrypt and protect the payment key issued by the electronic payment system and improve the protection strength.
  • a first aspect of the embodiments of the present application provides an encryption method for a payment key, including:
  • the background service system is used to generate an SM4 white box key, an SM2 public key and an SM2 private key in response to the key generation request, and save the SM2 private key;
  • the plaintext of the payment key issued by the electronic payment system is encrypted by the SM4 white box key, the AES key and the SM2 public key, and the ciphertext of the payment key is generated and stored.
  • a second aspect of the embodiments of the present application provides a method for decrypting a payment key, which is implemented based on the method for encrypting a payment key according to the first aspect of the embodiments of the present application, and the decryption method includes:
  • the background service system is used to decrypt the payment key ciphertext for the first time through the SM2 private key
  • the ciphertext of the payment key after the first decryption is decrypted again by the AES key and the SM4 white-box key, and the plaintext of the payment key is obtained.
  • a third aspect of the embodiments of the present application provides a payment authentication method, which is implemented based on the method for decrypting a payment key according to the second aspect of the embodiments of the present application, and the payment authentication method includes:
  • Uploading the transaction information to an electronic payment system wherein, the electronic payment system is used to decrypt the transaction information, obtain the transaction data and the payment data, verify whether the payment data is legal, and then check whether the payment data is legal. Approve the transaction corresponding to the transaction data when the data is legal, reject the transaction corresponding to the transaction data when the payment data is illegal, and generate payment feedback information;
  • a fourth aspect of the embodiments of the present application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, when the processor executes the computer program.
  • a fifth aspect of the embodiments of the present application provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the first aspect to the embodiment of the present application is implemented. The steps of any one of the methods of the third aspect.
  • an AES file key and an AES key are generated by a keystore management system, a key generation request is sent to a background service system, and a key is responded to by the background service system Generate request Generate SM4 white box key, SM2 public key and SM2 private key and save the SM2 private key, receive the SM4 white box key and SM2 public key sent by the background service system, and then encrypt the SM4 white box key with the AES file key and SM2 public key, generate the ciphertext of the SM4 white box key and the SM2 public key and save it, encrypt the plaintext of the payment key issued by the electronic payment system through the SM4 white box key, the AES key and the SM2 public key , generate the ciphertext of the payment key and save it.
  • the keystore management system In the white box environment, the keystore management system, the SM4 white box key and the SM2 public key can be used to encrypt and protect the plaintext of the payment key, and in the keystore On the basis of the management system, the SM4 white box key, SM2 public key and SM2 private key are generated through the background service system, which can effectively improve the protection strength.
  • the method for decrypting the payment key provided by the second aspect of the embodiment of the present application is based on the encryption method described in the first aspect of the embodiment of the present application, by reading the stored ciphertext of the payment key, and converting the payment key
  • the ciphertext is sent to the background service system, and the payment key ciphertext is decrypted for the first time through the SM2 private key through the background service system, and the first decrypted payment key ciphertext sent by the background service system is received.
  • the payment authentication method provided by the third aspect of the embodiments of the present application collects payment data based on the decryption method described in the second aspect of the embodiments of the present application, encrypts the payment data in plaintext with a payment key, and generates a payment data encryption key. Then encrypt the transaction data and payment data ciphertext, generate transaction information, upload the transaction information to the electronic payment system, use the electronic payment system to decrypt the transaction information, obtain transaction data and payment data, and verify whether the payment data is legal.
  • Approve the transaction corresponding to the transaction data when the payment data is legal reject the transaction corresponding to the transaction data when the payment data is illegal, generate payment feedback information, and receive the payment feedback information issued by the electronic payment system, which can be performed on the plaintext of the encryption key.
  • double encryption of payment data is realized, so as to effectively ensure the security of electronic payment.
  • 1 is a first schematic flow chart of an encryption method provided by an embodiment of the present application.
  • FIG. 2 is a second schematic flow chart of the encryption method provided by the embodiment of the present application.
  • FIG. 3 is a third schematic flowchart of an encryption method provided by an embodiment of the present application.
  • FIG. 4 is a first schematic flow chart of a decryption method provided by an embodiment of the present application.
  • FIG. 5 is a second schematic flowchart of a decryption method provided by an embodiment of the present application.
  • FIG. 6 is a first schematic flowchart of an update method provided by an embodiment of the present application.
  • FIG. 8 is a first schematic flowchart of a deletion method provided by an embodiment of the present application.
  • FIG. 9 is a second schematic flowchart of a deletion method provided by an embodiment of the present application.
  • FIG. 10 is a schematic flowchart of a payment authentication method provided by an embodiment of the present application.
  • FIG. 11 is a schematic structural diagram of a terminal device provided by an embodiment of the present application.
  • the term “if” may be contextually interpreted as “when” or “once” or “in response to determining” or “in response to detecting “.
  • the phrases “if it is determined” or “if the [described condition or event] is detected” may be interpreted, depending on the context, to mean “once it is determined” or “in response to the determination” or “once the [described condition or event] is detected. ]” or “in response to detection of the [described condition or event]”.
  • references in this specification to "one embodiment” or “some embodiments” and the like mean that a particular feature, structure or characteristic described in connection with the embodiment is included in one or more embodiments of the present application.
  • appearances of the phrases “in one embodiment,” “in some embodiments,” “in other embodiments,” “in other embodiments,” etc. in various places in this specification are not necessarily All refer to the same embodiment, but mean “one or more but not all embodiments” unless specifically emphasized otherwise.
  • the terms “including”, “including”, “having” and their variants mean “including but not limited to” unless specifically emphasized otherwise.
  • the payment key encryption method, payment key decryption method, and payment authentication method provided by the embodiments of this application can be applied to mobile phones, tablet computers, wearable devices, vehicle-mounted devices, augmented reality (AR)/virtual reality (virtual reality, VR) devices, laptops, ultra-mobile personal computers computer, UMPC), netbook, personal digital assistant (personal digital assistant, PDA) and other terminal devices, the embodiments of the present application do not impose any restrictions on the specific type of the terminal device.
  • AR augmented reality
  • VR virtual reality
  • UMPC ultra-mobile personal computers computer
  • PDA personal digital assistant
  • an operating system and an electronic payment application are installed on the terminal device, the operating system and the electronic payment application are stored in the memory of the terminal device, the processor of the terminal device runs the operating system, and the operating system calls and runs the electronic payment application to realize The encryption method of the payment key, the decryption method of the payment key, or the payment authentication method.
  • the operating system can be Android (Android), iOS (Apple), Windows Phone, Symbian (Symbian), BlackBerry OS, Web Os, Windows Mobile, Harmony (Hongmeng), etc.
  • the processor may be a central processing unit (Central Processing Unit, CPU), and the processor may also be other general-purpose processors, digital signal processors (Digital Signal Processors, DSP), application specific integrated circuits (Application Specific Integrated Circuits) Integrated Circuit, ASIC), off-the-shelf Programmable Gate Array (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • a general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
  • the memory may be an internal storage unit of the terminal device in some embodiments, for example, a hard disk or a memory of the terminal device.
  • the memory may also be an external storage device of the terminal device, for example, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card equipped on the terminal device, Flash card (Flash Card) and so on.
  • the memory may also include both an internal storage unit of the terminal device and an external storage device.
  • the memory is used to store an operating system, application programs, a boot loader (Boot Loader), data, and other programs, for example, program codes of computer programs, and the like.
  • the memory may also be used to temporarily store data that has been or will be output.
  • the encryption method for the payment key includes the following steps S101 to S105:
  • Step S101 generating an AES file key and an AES key through a keystore management system.
  • the KeyStoreManagement System utilizes the Advanced Encryption Standard Standard, AES) algorithm to generate the AES file key and AES key, the AES file key and AES key will be automatically saved to the keystore management system.
  • AES Advanced Encryption Standard Standard
  • the Advanced Encryption Standard algorithm is a symmetric key encryption algorithm.
  • Step S102 sending a key generation request to the background service system; wherein, the background service system is used to generate an SM4 white box key, an SM2 public key and an SM2 private key in response to the key generation request, and save the SM2 private key. key.
  • the electronic payment application sends a key generation request to the Back-end System.
  • the background service system uses the national secret algorithm SM4 to generate the SM4 white box key
  • uses the national secret algorithm SM2 to generate the SM2 public key and SM2 private key
  • the background service system Before sending the SM4 white box key and SM2 public key to the electronic payment application, the background service system can also use the private key of the background service system to digitally sign the SM4 white box key and SM2 public key, and then sign the SM4 white box key and SM2 public key.
  • the key and the SM2 public key and its digital signature are sent to the electronic payment application to improve the security of the transmission of the SM4 white box key and the SM2 public key, and prevent the SM4 white box key and the SM2 public key from being illegally tampered with.
  • the national secret algorithm SM4 is a symmetric key encryption algorithm
  • the national secret algorithm SM2 is an asymmetric encryption algorithm.
  • the background service system can be run by computing devices such as servers and computers of banks, financial institutions, etc., or by computing devices such as servers and computers of the publisher of the electronic payment application.
  • the publisher of the electronic payment application can also be Banks, financial institutions, etc.
  • Step S103 Receive the SM4 white box key and the SM2 public key sent by the background service system.
  • the electronic payment application when the electronic payment application receives the SM4 white box key and SM2 public key and its digital signature, it first uses the certificate of the background service system to verify the digital signature to prevent the SM4 white box key and SM2 public key from being illegally tampered with. When the digital signature verification is passed, it can be determined that the SM4 white box key and the SM2 public key have not been tampered with.
  • Step S104 Encrypt the SM4 white box key and the SM2 public key with the AES file key, and generate and save the ciphertext of the SM4 white box key and the SM2 public key.
  • the electronic payment application can encrypt the SM4 white box key and SM2 public key together with the AES file key to obtain a ciphertext and Save it to the private file of the electronic payment application; you can also encrypt the SM4 white box key and the SM2 public key separately through the AES file key to obtain the SM4 white box key ciphertext and the SM2 public key ciphertext and save them to the electronic In the private file of the payment application.
  • Step S105 encrypt the plaintext of the payment key issued by the electronic payment system by using the SM4 white box key, the AES key and the SM2 public key, and generate and save the ciphertext of the payment key.
  • the application after receiving the plaintext of the payment key issued by the electronic payment system, read the stored ciphertext of the SM4 white box key and SM2 public key and the AES key from the private file of the electronic payment application, using The AES file key decrypts the ciphertext of the SM4 white box key and the SM2 public key, and then encrypts the plaintext of the payment key with the SM4 white box key, AES key and SM2 public key, generates the ciphertext of the payment key and saves it to the electronic payment The app's private files.
  • the electronic payment system can be run by a server, computer and other computing devices of banks, financial institutions, etc., or by a server, computer and other computing devices of the publisher of the electronic payment application.
  • the back-office service system and the electronic payment system may be run by computing devices of different institutions.
  • step S105 includes:
  • the plaintext of the payment key issued by the electronic payment system is encrypted for the first time by the SM4 white box key, the payment key is encrypted by the AES key for the second time, and the payment key is encrypted by the SM2 public key for the third time.
  • the payment key is described, and the ciphertext of the payment key is generated and saved.
  • the plaintext of the payment key is encrypted by the SM4 white box key, the AES key and the SM2 public key in turn, so as to realize triple encryption of the plaintext of the payment key.
  • the embodiments corresponding to FIGS. 1 and 2 can encrypt and protect the plaintext of the payment key in a white-box environment by using a combination of the keystore management system, the SM4 white-box key, and the SM2 public key, and store the payment key in the keystore.
  • the SM4 white box key, SM2 public key and SM2 private key are generated through the background service system, which can effectively improve the protection strength.
  • the embodiment corresponding to FIG. 2 can further improve the encryption protection strength of the payment key plaintext by performing triple encryption on the payment key plaintext.
  • step S102 before step S102, the following steps S301 to S306 are included:
  • Step S301 establishing a communication connection with a background service system
  • the CA public key issued by a certificate issuing authority (CA) and the certificate of the background service system are hard-coded into the code of the electronic payment application and released together with the electronic payment application.
  • the private key of the background serverless and the certificate of the background service system are stored in the encryption machine of the background service system when the background service system is initialized for the first time.
  • the electronic payment application After establishing the communication link between the electronic payment application and the background service system and realizing the communication connection, the electronic payment application can unidirectionally authenticate the legitimacy of the background service system through the TLS1.3 protocol, and when the verification result is that the background service system is legal , to establish a secure encrypted channel with the background service system.
  • Step S302 verifying the certificate issued by the background service system through the CA public key
  • Step S303 when the certificate issued by the background service system is verified and passed, compare whether the URL of the certificate issued by the background service system is consistent with the URL of the background service system;
  • Step S304 when the URL of the certificate is consistent with the URL of the background service system, perform binary comparison between the pre-hardcoded certificate of the background service system and the certificate issued by the background service system;
  • Step S305 when the pre-hardcoded certificate of the background service system is consistent with the certificate issued by the background service system, determine that the background service system is legal;
  • Step S306 establishing a secure encryption channel with the background service system.
  • the electronic payment application first uses the CA public key to verify the certificate issued by the background service system;
  • step S102 includes:
  • step S103 includes:
  • the encrypted transmission can be performed directly based on the secure encryption channel, and there is no need for the second encryption protection based on the secure encryption channel.
  • the embodiment corresponding to FIG. 3 realizes the data interaction between the electronic payment application and the background service system by establishing a secure encryption channel between the two, which can effectively ensure the security of the data interaction between the two.
  • the payment key decryption method includes the following steps S401 to S404:
  • Step S401 Read the stored ciphertext of the payment key.
  • Step S402 Send the ciphertext of the payment key to the background service system; wherein the background service system is used to decrypt the ciphertext of the payment key for the first time by using the SM2 private key.
  • the payment key ciphertext can be sent to the background service system through a secure encryption channel.
  • the background service system uses the SM2 private key stored in its encryption machine to decrypt the payment key ciphertext for the first time, and then sends it to the electronic payment application.
  • it can be encrypted through a secure encryption channel.
  • the ciphertext of the payment key decrypted for the first time is sent to the electronic payment application.
  • Step S403 receiving the first decrypted ciphertext of the payment key sent by the background service system;
  • Step S404 Decrypt the ciphertext of the payment key decrypted for the first time by using the AES key and the SM4 white box key again to obtain the plaintext of the payment key.
  • the electronic payment application After the electronic payment application receives the first decrypted payment key ciphertext, it decrypts the first decrypted payment key ciphertext again through the AES key and the SM4 white box key, and finally gets the payment Key plaintext.
  • step S404 includes:
  • the ciphertext of the payment key is decrypted for the second time with the AES key, and the ciphertext of the payment key is decrypted for the third time with the SM4 white box key to obtain the plaintext of the payment key.
  • the ciphertext of the payment key is decrypted by the SM2 private key, the AES key and the SM4 white box key in turn, and finally the plaintext of the payment key after three decryptions is obtained.
  • the embodiment corresponding to FIG. 4 makes the decryption operation of the payment key ciphertext only possible by accessing the SM2 private key in the background service system, but restricting the background service system to directly restore the payment key plaintext, it is necessary to pass the AES key and SM4
  • the plaintext of the payment key can be obtained only after the white-box key is decrypted again, which can improve the protection strength of the plaintext of the payment key.
  • the embodiment corresponding to FIG. 5 can obtain the payment key plaintext by decrypting the payment key ciphertext three times, which can further improve the protection strength of the payment key plaintext.
  • the present application also provides a method for updating a security encryption key, including the following steps S601 to S603:
  • Step S601 Generate a new security encryption key by using the encryption method; wherein, the security encryption key includes an AES file key, an AES key, an SM4 white box key, an SM2 public key, and an SM2 private key.
  • the update method of the security encryption key is the same as the process and principle of generating the AES file key, AES key, SM4 white box key, SM2 public key and SM2 private key in the above encryption method, and specifically includes the following steps:
  • the background service system is used to generate a new SM4 white box key, a new SM2 public key and a new SM2 private key in response to the new key generation request , and save the new SM2 private key;
  • the new SM4 white box key and the new SM2 public key are encrypted by the AES file key, and ciphertexts of the new SM4 white box key and the new SM2 public key are generated and saved.
  • Step S602 Encrypt the plaintext of the payment key by using the new security encryption key by the encryption method to generate a new ciphertext of the payment key.
  • the plaintext of the payment key issued by the electronic payment system is encrypted by the new SM4 white box key, the new AES key and the new SM2 public key, and the ciphertext of the payment key is generated and stored.
  • Step S603 delete the old security encryption key.
  • the old security encryption key refers to the AES file key, AES key, SM4 white box key, SM2 public key and SM2 private key before the update.
  • the old security encryption key may not be deleted.
  • the electronic payment application saves both the old and the new security encryption key.
  • both the new and the old security encryption key are It can be used normally. It is in the transition period of the replacement of the old and new security encryption keys.
  • the electronic payment application can store all the security encryption keys updated in the past period of time at the same time, that is, at least two security encryption keys can be stored at the same time.
  • the present application also provides a method for deleting a security encryption key, including the following steps S801 and S802:
  • Step S801 delete the old AES file key, the old AES key, the old SM4 white box key and the old SM2 public key.
  • the operation of deleting the security encryption key needs to be performed.
  • One is that after the update of the old security encryption key is completed, the old security encryption key can be deleted, and only the new security encryption key can be kept.
  • the encryption key the other is that when the electronic payment application detects that the payment environment is not secure, the security encryption key needs to be deleted. That is, the operation of deleting the security encryption key can be performed on the basis of any one of the foregoing encryption method, decryption method or update method embodiment, and only the old security encryption key can be deleted, or all security encryption keys can be deleted.
  • step S801 includes:
  • Step S802 Send a deletion request to the background service system, wherein the background service system is used to delete the old SM2 private key in response to the deletion request.
  • the electronic payment application when it completes the operation of deleting the AES file key, AES key, SM4 white box key and SM2 public key, it sends a deletion request for deleting the SM2 private key to the background service system, and the background service system receives After the deletion request, respond and execute the operation of deleting the SM2 private key.
  • the security encryption key can be updated, and the security encryption key can be prevented from being tampered with when the payment security is not secure.
  • the present application further provides a payment authentication method, including the following steps S1001 to S1005:
  • Step S1001 collecting payment data.
  • the methods of collecting payment data are also different.
  • the electronic payment application can support at least one of card-based payment and card-free payment; when supporting card-based payment, a magnetic card (Magnetic Card) and a contact IC card (Integrated Circuit Card) can be collected through a card reader.
  • Payment data of at least one payment card among non-contact cards and non-contact cards; when cardless payment is supported, biometric data, password data, codes can be collected through the human-computer interaction device supported by the terminal device At least one of data and digital certificate (Digital Certificate) data.
  • Biometric data may include face data based on face recognition, fingerprint (Finger Print) data based on fingerprint recognition technology, electronic signature data based on electronic signature (Electronic Signature) recognition technology, voiceprint data based on voiceprint recognition technology, etc. .
  • Electronic signature refers to the data contained in the data message in electronic form and attached to identify the signer's identity and indicate that the signer approves the content.
  • the password authentication data is the user data for logging in through the user name and password.
  • the password can be a fixed password set by the user, or a dynamic password (that is, a dynamic password) generated by a payment-related computing device.
  • the encoded authentication data may include one-dimensional code data based on one-dimensional code identification technology or two-dimensional code data based on two-dimensional code identification technology, and the one-dimensional code may specifically refer to a one-dimensional barcode.
  • Digital certificate refers to a digital certification that identifies the identity information of all parties in Internet communication, and can be used to identify identities in the Internet. Digital certificates include mobile certificates and browser certificates. Mobile certificates use U-KEY (U-KEY). ) class carrier is used as a device for encrypting and storing digital certificates, and a browser certificate uses a computer class carrier as a device for downloading and installing digital certificates.
  • U-KEY U-KEY
  • the card reader may include a magnetic card reader, a contact IC card reader, a contactless card reader, etc.
  • the contactless card reader may be a near field communication (Near Field Communication, NFC) reader card holder.
  • Human-computer interaction equipment may include cameras, fingerprint modules, electronic signature panels, microphones and other biometric acquisition devices for collecting biometric data, keyboards, touch screens, etc. for collecting password data. Coded cameras or code scanning guns and other code acquisition devices, and UShield used to collect digital certificates, etc.
  • the electronic signature pad can be replaced by a touch screen.
  • Step S1002 encrypting the payment data in plaintext with a payment key to generate a ciphertext of the payment data.
  • the ciphertext of the payment key is first read from the private file of the electronic payment application, and then the plaintext of the payment key is obtained after decrypting the security encryption key.
  • the payment key plaintext will appear in the memory of the terminal device for a short time. After the encryption is completed, the payment key plaintext in the memory must be cleared immediately to prevent the payment key plaintext from being stolen or tampered with. Payment security.
  • Step S1003 encrypting the transaction data and the ciphertext of the payment data to generate transaction information.
  • the transaction data and the ciphertext of the payment data can be encrypted for the second time using any passed encryption algorithm to generate transaction information.
  • Step S1004 uploading the transaction information to an electronic payment system; wherein, the electronic payment system is used to decrypt the transaction information, obtain the transaction data and the payment data, and verify whether the payment data is legal.
  • the payment data is legal, the transaction corresponding to the transaction data is approved, and when the payment data is illegal, the transaction corresponding to the transaction data is rejected, and payment feedback information is generated.
  • the transaction information is generated, it is transmitted to the electronic payment system for transaction verification.
  • the electronic payment system receives the transaction information, it decrypts the transaction information to obtain transaction data and payment data, and then verifies whether the payment data is legal. If it is legal, the transaction is approved, otherwise the transaction is rejected, and the corresponding payment feedback information is generated and sent to the electronic payment.
  • the payment feedback information may include information representing transaction success, transaction failure, insufficient balance, payment data verification failure, and the like.
  • Step S1005 Receive the payment feedback information issued by the electronic payment system.
  • the electronic payment application after receiving the payment feedback information, can use any human-computer interaction method supported by the terminal device to notify the user of the transaction result, for example, notify the user of the transaction result through display, voice, image, etc.
  • the embodiment corresponding to FIG. 10 can realize double encryption of payment data on the premise of effectively protecting the plaintext of the encryption key, thereby effectively guaranteeing the security of electronic payment.
  • the terminal device 100 provided by this embodiment of the present application includes: at least one processor 10 (only one processor is shown in FIG. 11 ), a memory 20 , and a memory 20 that is stored in the memory 20 and can be used in the at least one processor 10
  • the computer program 21 running on the processor 10 implements the steps in each of the above method embodiments when the processor 10 executes the computer program 21 .
  • a computer program may be divided into one or more modules that are stored in a memory and executed by a processor to complete the present application.
  • the one or more modules may be a series of computer program instruction segments capable of accomplishing specific functions, and the instruction segments are used to describe the execution process of the computer program in the terminal device.
  • the computer program can be divided into the following functional modules:
  • the first key generation module is used to generate the AES file key and the AES key through the keystore management system;
  • the first sending module is used to send a key generation request to the background service system; wherein, the background service system is used to generate the SM4 white box key, the SM2 public key and the SM2 private key in response to the key generation request, and save them the SM2 private key;
  • a first receiving module configured to receive the SM4 white box key and the SM2 public key sent by the background service system
  • a second key generation module configured to encrypt the SM4 white box key and the SM2 public key by using the AES file key, generate and save the ciphertext of the SM4 white box key and the SM2 public key ;
  • the first encryption module is configured to encrypt the plaintext of the payment key issued by the electronic payment system by using the SM4 white box key, the AES key and the SM2 public key, and generate and save the ciphertext of the payment key.
  • the computer program can also be divided into the following functional modules:
  • a first communication module used for establishing a communication connection with the background service system
  • a verification module for verifying the certificate issued by the background service system through the CA public key
  • the first comparison module is used to compare whether the URL of the certificate issued by the background service system is consistent with the URL of the background service system when the certificate issued by the background service system is verified;
  • the second comparison module is used to perform binary comparison between the pre-hardcoded certificate of the background service system and the certificate issued by the background service system when the URL of the certificate is consistent with the URL of the background service system;
  • a determination module which determines that the background service system is legal when the pre-hardcoded certificate of the background service system is consistent with the certificate issued by the background service system;
  • the second communication module is used to establish a secure encrypted channel with the background service system.
  • the computer program can also be divided into the following functional modules:
  • the read module is used to read the stored ciphertext of the payment key
  • the second sending module is configured to send the payment key ciphertext to the background service system; wherein, the background service system is used to decrypt the payment key ciphertext for the first time through the SM2 private key;
  • a second receiving module configured to receive the first decrypted ciphertext of the payment key sent by the background service system
  • the decryption module is used for decrypting the ciphertext of the payment key decrypted for the first time by using the AES key and the SM4 white box key again to obtain the plaintext of the payment key.
  • the computer program can also be divided into the following functional modules:
  • the second key generation module is configured to generate a new security encryption key by using the encryption method; wherein, the security encryption key includes AES file key, AES key, SM4 white box key, SM2 public key and SM2 private key.
  • the second encryption module is configured to encrypt the plaintext of the payment key by using the new security encryption key by the encryption method to generate a new ciphertext of the payment key.
  • the deletion module is specifically used for:
  • the computer program can also be divided into the following functional modules:
  • the data collection module is used to collect payment data.
  • the third encryption module is used for encrypting the payment data through the payment key plaintext to generate the payment data ciphertext.
  • the fourth encryption module is used for encrypting the transaction data and the ciphertext of the payment data to generate transaction information.
  • the third sending module is used for uploading the transaction information to the electronic payment system.
  • the third receiving module is configured to receive the payment feedback information issued by the electronic payment system.
  • the above software program modules can also be implemented by different logic circuits integrated in the processor, and can also be implemented by multiple distributed processors.
  • the terminal device may include, but is not limited to, a processor and a memory, may include more or less components than the figure, or combine some components, or different components, for example, may also include input and output devices, network interface into the equipment, etc.
  • Embodiments of the present application further provide a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the steps in the foregoing method embodiments can be implemented.
  • the embodiments of the present application provide a computer program product, when the computer program product runs on a terminal device, so that the terminal device can implement the steps in the foregoing method embodiments when executed.
  • the integrated modules if implemented in the form of software functional modules and sold or used as independent products, can be stored in a computer-readable storage medium.
  • the present application realizes all or part of the processes in the methods of the above-mentioned embodiments, which can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium, and the computer program is stored in a computer-readable storage medium.
  • the computer program includes computer program code
  • the computer program code may be in the form of source code, object code, executable file or some intermediate forms, and the like.
  • the computer-readable medium may include at least: any entity or device capable of carrying the computer program code to the management system, recording medium, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory) Memory), electrical carrier signals, telecommunication signals, and software distribution media.
  • ROM read-only memory
  • RAM random access memory
  • electrical carrier signals electrical carrier signals
  • telecommunication signals and software distribution media.
  • U disk mobile hard disk, disk or CD, etc.

Abstract

一种支付密钥的加密和解密方法、支付认证方法及终端设备（100），通过密钥库管理系统生成AES文件密钥和AES密钥（S101），后台服务系统生成SM4白盒密钥、SM2公钥和SM2私钥并保存SM2私钥，接收后台服务系统发送的SM4白盒密钥和SM2公钥（S103），通过AES文件密钥加密SM4白盒密钥和SM2公钥生成SM4白盒密钥和SM2公钥的密文并保存（S104），通过SM4白盒密钥、AES密钥和SM2公钥加密电子支付系统下发的支付密钥明文生成支付密钥密文并保存（S105）。可以在白盒环境下采用密钥库管理系统、SM4白盒密钥和SM2公钥结合的方式加密保护支付密钥明文，通过后台服务系统生成SM4白盒密钥、SM2公钥和SM2私钥，能够提高保护强度。

Description

支付密钥的加密和解密方法、支付认证方法及终端设备
本申请要求于2020年10月14日在中国专利局提交的、申请号为202011099201.3的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请属于密钥（secret key）技术领域，尤其涉及一种支付密钥的加密和解密方法、支付认证方法及终端设备。
 背景技术
密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥和非对称密钥。对称密钥又称私钥或会话密钥，信息的发送方和接收方使用同一个密钥去加密和解密数据，它的最大优势是加/解密速度快，适合于对大数据量进行加密，但密钥管理困难。非对称密钥又称公钥，它需要使用不同的密钥来分别完成加密和解密操作，一个公开发布，即公开密钥，另一个由用户自己秘密保存，即私用密钥，信息发送者用公开密钥去加密，而信息接收者则用私用密钥去解密，非对称密钥机制灵活，但加密和解密速度却比对称密钥慢得多。在实际的应用中，通常将对称密钥和非对称密钥结合在一起使用，对称密钥用于存储大量数据信息，而非对称密钥则用于加密密钥。密钥在电子支付领域应用广泛，保护电子支付密钥，使其不被暴露和未授权使用，是保障电子支付安全的关键。
 技术问题
有鉴于此，本申请实施例提供了一种支付密钥的加密和解密方法、支付认证方法及终端设备，能够对电子支付系统下发的支付密钥进行加密保护并提高保护强度。
 技术解决方案
本申请实施例的第一方面提供了一种支付密钥的加密方法，包括：
通过密钥库管理系统生成AES文件密钥和AES密钥；
向后台服务系统发送密钥生成请求；其中，所述后台服务系统用于响应所述密钥生成请求生成SM4白盒密钥、SM2公钥和SM2私钥，并保存所述SM2私钥；
接收所述后台服务系统发送的所述SM4白盒密钥和所述SM2公钥；
通过所述AES文件密钥加密所述SM4白盒密钥和所述SM2公钥，生成所述SM4白盒密钥和所述SM2公钥的密文并保存；
通过所述SM4白盒密钥、所述AES密钥和所述SM2公钥加密电子支付系统下发的支付密钥明文，生成支付密钥密文并保存。
本申请实施例的第二方面提供了一种支付密钥的解密方法，基于如本申请实施例的第一方面所述的支付密钥的加密方法实现，所述解密方法包括：
读取保存的支付密钥密文；
将所述支付密钥密文发送给后台服务系统；其中，所述后台服务系统用于通过SM2私钥第一次解密所述支付密钥密文；
接收所述后台服务系统发送的第一次解密后的所述支付密钥密文；
通过AES密钥和SM4白盒密钥再次解密第一次解密后的所述支付密钥密文，获得支付密钥明文。
本申请实施例的第三方面提供了一种支付认证方法，基于如本申请实施例的第二方面所述的支付密钥的解密方法实现，所述支付认证方法包括：
采集支付数据；
通过支付密钥明文加密所述支付数据，生成支付数据密文；
加密交易数据和所述支付数据密文，生成交易信息；
将所述交易信息上传至电子支付系统；其中，所述电子支付系统用于解密所述交易信息，获得所述交易数据和所述支付数据，校验所述支付数据是否合法，在所述支付数据合法时批准所述交易数据对应的交易，在所述支付数据不合法时拒绝所述交易数据对应的交易，并生成支付反馈信息；
接收所述电子支付系统下发的所述支付反馈信息。
本申请实施例的第四方面提供了一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如本申请实施例的第一方面至第三方面任一项所述方法的步骤。
本申请实施例的第五方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如本申请实施例的第一方面至第三方面任一项所述方法的步骤。
本申请实施例的第一方面提供的支付密钥的加密方法，通过密钥库管理系统生成AES文件密钥和AES密钥，向后台服务系统发送密钥生成请求，通过后台服务系统响应密钥生成请求生成SM4白盒密钥、SM2公钥和SM2私钥并保存SM2私钥，接收后台服务系统发送的SM4白盒密钥和SM2公钥，然后通过AES文件密钥加密SM4白盒密钥和SM2公钥，生成所述SM4白盒密钥和所述SM2公钥的密文并保存，通过SM4白盒密钥、AES密钥和SM2公钥加密电子支付系统下发的支付密钥明文，生成支付密钥密文并保存，可以在白盒环境下采用密钥库管理系统、SM4白盒密钥和SM2公钥相结合的方式对支付密钥明文进行加密保护，并且在密钥库管理系统的基础上通过后台服务系统生成SM4白盒密钥、SM2公钥和SM2私钥，能够有效提高保护强度。
本申请实施例的第二方面提供的支付密钥的解密方法，通过在本申请实施例的第一方面所述的加密方法的基础上，读取保存的支付密钥密文，将支付密钥密文发送给后台服务系统，通过后台服务系统通过SM2私钥第一次解密支付密钥密文，并接收后台服务系统发送的第一次解密后的支付密钥密文，然后通过AES密钥和SM4白盒密钥再次解密第一次解密后的支付密钥密文，获得支付密钥明文，使得对支付密钥密文的解密操作必须访问后台服务系统中的SM2私钥才能实现，但限制后台服务系统直接还原出支付密钥明文，需要通过AES密钥和SM4白盒密钥再次解密后才能获得支付密钥明文，可以提高对支付密钥明文的保护强度。
本申请实施例的第三方面提供的支付认证方法，通过在本申请实施例的第二方面所述的解密方法的基础上，采集支付数据，通过支付密钥明文加密支付数据，生成支付数据密文，然后加密交易数据和支付数据密文，生成交易信息，将交易信息上传至电子支付系统，通过电子支付系统用于解密交易信息，获得交易数据和支付数据，校验支付数据是否合法，在支付数据合法时批准交易数据对应的交易，在支付数据不合法时拒绝交易数据对应的交易，并生成支付反馈信息，并接收电子支付系统下发的支付反馈信息，可以在对加密秘钥明文进行有效保护的前提下，实现对支付数据的双重加密，从而有效保障电子支付安全。
可以理解的是，上述第四方面至第五方面的有益效果可以参见上述第一方面、第二方面或第三方面中的相关描述，在此不再赘述。
 附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的加密方法的第一种流程示意图；
图2是本申请实施例提供的加密方法的第二种流程示意图；
图3是本申请实施例提供的加密方法的第三种流程示意图；
图4是本申请实施例提供的解密方法的第一种流程示意图；
图5是本申请实施例提供的解密方法的第二种流程示意图；
图6是本申请实施例提供的更新方法的第一种流程示意图；
图7是本申请实施例提供的更新方法的第二种流程示意图；
图8是本申请实施例提供的删除方法的第一种流程示意图；
图9是本申请实施例提供的删除方法的第二种流程示意图；
图10是本申请实施例提供的支付认证方法的流程示意图；
图11是本申请实施例提供的终端设备的结构示意图。
 本发明的实施方式
以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。
应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。
另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
本申请实施例提供的支付密钥的加密方法、支付密钥的解密方法和支付认证方法，可以应用于手机、平板电脑、可穿戴设备、车载设备、增强现实（augmented reality，AR）/虚拟现实（virtual reality，VR）设备、笔记本电脑、超级移动个人计算机（ultra-mobile personal computer，UMPC）、上网本、个人数字助理（personal digital assistant，PDA）等终端设备上，本申请实施例对终端设备的具体类型不作任何限制。
在应用中，终端设备上安装有操作系统和电子支付应用，操作系统和电子支付应用存储在终端设备的存储器中，终端设备的处理器运行操作系统，操作系统调用和运行电子支付应用，以实现支付密钥的加密方法、支付密钥的解密方法或支付认证方法。
在应用中，操作系统可以是Android（安卓）、iOS（苹果）、Windows Phone、Symbian（塞班）、BlackBerry OS、Web Os、Windows Mobile、Harmony（鸿蒙）等。
在应用中，处理器可以是中央处理单元（Central Processing Unit，CPU），该处理器还可以是其他通用处理器、数字信号处理器（Digital Signal Processor，DSP）、专用集成电路（Application Specific Integrated Circuit，ASIC）、现成可编程门阵列（Field-Programmable Gate Array，FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
在应用中，存储器在一些实施例中可以是终端设备的内部存储单元，例如，终端设备的硬盘或内存。存储器在另一些实施例中也可以是终端设备的外部存储设备，例如，终端设备上配备的插接式硬盘，智能存储卡（Smart Media Card，SMC），安全数字（Secure Digital，SD）卡，闪存卡（Flash Card）等。存储器还可以既包括终端设备的内部存储单元也包括外部存储设备。存储器用于存储操作系统、应用程序、引导装载程序（Boot Loader）、数据以及其他程序等，例如，计算机程序的程序代码等。存储器还可以用于暂时地存储已经输出或者将要输出的数据。
如图1和图2所示，本申请实施例提供的支付密钥的加密方法，包括如下步骤S101至S105：
步骤S101、通过密钥库管理系统生成AES文件密钥和AES密钥。
在应用中，密钥库管理系统（KeyStoreManagement System）利用高级加密标准（Advanced Encryption Standard，AES）算法生成AES文件密钥和AES密钥后，AES文件密钥和AES密钥会自动保存至密钥库管理系统。高级加密标准算法是一种对称密钥加密算法。
步骤S102、向后台服务系统发送密钥生成请求；其中，所述后台服务系统用于响应所述密钥生成请求生成SM4白盒密钥、SM2公钥和SM2私钥，并保存所述SM2私钥。
在应用中，在生成AES文件密钥和AES密钥之后，电子支付应用向后台服务系统（Back-end System）发送密钥生成请求。后台服务系统响应该密钥生成请求后，采用国密算法SM4生成SM4白盒密钥、采用国密算法SM2生成SM2公钥和SM2私钥，将SM2私钥保存至后台服务系统的加密机中，然后将SM4白盒密钥和SM2公钥发送给电子支付应用。后台服务系统在将SM4白盒密钥和SM2公钥发送给电子支付应用之前，也可以先利用后台服务系统的私钥对SM4白盒密钥和SM2公钥进行数字签名，再将SM4白盒密钥和SM2公钥及其数字签名发送给电子支付应用，以提高传输SM4白盒密钥和SM2公钥的安全性，防止SM4白盒密钥和SM2公钥被非法篡改。国密算法SM4是一种对称密钥加密算法，国密算法SM2是一种非对称加密算法。
在应用中，后台服务系统可以由银行、金融机构等的服务器、计算机等计算设备运行，也可以由电子支付应用的发布方的服务器、计算机等计算设备运行，电子支付应用的发布方也可以是银行、金融机构等。
步骤S103、接收所述后台服务系统发送的所述SM4白盒密钥和所述SM2公钥。
在应用中，电子支付应用在接收到SM4白盒密钥和SM2公钥及其数字签名时，先利用后台服务系统的证书验证数字签名，防止SM4白盒密钥和SM2公钥被非法篡改，在数字签名验证通过时，可以判定SM4白盒密钥和SM2公钥未被篡改。
步骤S104、通过所述AES文件密钥加密所述SM4白盒密钥和所述SM2公钥，生成所述SM4白盒密钥和所述SM2公钥的密文并保存。
在应用中，电子支付应用接收到后台服务系统发送的SM4白盒密钥和SM2公钥之后，可以通过AES文件密钥对SM4白盒密钥和SM2公钥一起进行加密，得到一个密文并保存至电子支付应用的私有文件中；也可以通过AES文件密钥分别对SM4白盒密钥和SM2公钥进行单独加密，得到SM4白盒密钥密文和SM2公钥密文并保存至电子支付应用的私有文件中。
步骤S105、通过所述SM4白盒密钥、所述AES密钥和所述SM2公钥加密电子支付系统下发的支付密钥明文，生成支付密钥密文并保存。
在应用中，在接收到电子支付系统下发的支付密钥明文后，从电子支付应用的私有文件中读取已保存的SM4白盒密钥和SM2公钥的密文以及AES密钥，采用AES文件密钥解密SM4白盒密钥和SM2公钥的密文，然后通过SM4白盒密钥、AES密钥和SM2公钥加密支付密钥明文，生成支付密钥密文并保存至电子支付应用的私有文件。
在应用中，电子支付系统可以由银行、金融机构等的服务器、计算机等计算设备运行，也可以由电子支付应用的发布方的服务器、计算机等计算设备运行。后台服务系统和电子支付系统可以由不同机构的计算设备运行。
如图2所示，在一个实施例中，步骤S105包括：
通过所述SM4白盒密钥第一次加密电子支付系统下发的支付密钥明文，通过所述AES密钥第二次加密所述支付密钥，通所述SM2公钥第三次加密所述支付密钥，生成支付密钥密文并保存。
在应用中，支付密钥明文依次通过SM4白盒密钥、AES密钥和SM2公钥进行加密，从而实现对支付密钥明文的三重加密。
图1和2所对应的实施例可以在白盒环境下，采用密钥库管理系统、SM4白盒密钥和SM2公钥相结合的方式对支付密钥明文进行加密保护，并且在密钥库管理系统的基础上通过后台服务系统生成SM4白盒密钥、SM2公钥和SM2私钥，能够有效提高保护强度。图2所对应的实施例通过对支付密钥明文进行三重加密，可以进一步提高对支付密钥明文的加密保护强度。
如图3所示，在一个实施例中，步骤S102之前，包括如下步骤S301至S306：
步骤S301、与后台服务系统建立通信连接；
在应用中，在向后台服务系统发送密钥生成请求之前，需要先与后台服务系统之间建立安全加密通道，然后通过该安全加密通道来传输两者之间的交互数据，以保障数据安全。在发布电子支付应用时，会将证书签发机构（Certification Authority，CA）签发的CA公钥和后台服务系统的证书硬编码至电子支付应用的代码中，随同电子支付应用一起发布。后台无服务器的私钥和后台服务系统的证书在后台服务系统第第一次初始化时，存储到后台服务系统的加密机中。在建立电子支付应用与后台服务系统之间的通信链路，实现通信连接之后，电子支付应用可以通过TLS1.3协议单向认证后台服务系统的合法性，并在验证结果为后台服务系统合法时，建立与后台服务系统之间的安全加密通道。
步骤S302、通过CA公钥验证所述后台服务系统下发的证书；
步骤S303、在所述后台服务系统下发的证书验证通过时，比较所述后台服务系统下发的证书的URL和所述后台服务系统的URL是否一致；
步骤S304、在所述证书的URL和所述后台服务系统的URL一致时，将预先硬编码的所述后台服务系统的证书和所述后台服务系统下发的证书进行二进制比较；
步骤S305、在预先硬编码的所述后台服务系统的证书与所述后台服务系统下发的证书一致时，判定所述后台服务系统合法；
步骤S306、与后台服务系统建立安全加密通道。
在应用中，单向认证后台服务系统的合法性的过程为：
1、电子支付应用先采用CA公钥验证后台服务系统下发的证书；
2、在台服务系统下发的证书验证通过时，再比较后台服务系统下发的证书的统一资源定位器（Uniform Resource Locator，URL）和后台服务系统的URL是否一致；
3、在证书的URL和后台服务系统的URL一致时，将预先硬编码的后台服务系统的证书和后台服务系统下发的证书进行二进制比较；
4、在后台服务系统的证书和后台服务系统下发的证书一致时，也即上述三步验证操作全部验证通过时，才判定后台服务系统合法，从而可以电子支付应用建立与后台服务系统之间的安全加密通道。
在一个实施例中，步骤S102包括：
通过所述安全加密通道向所述后台服务系统发送密钥生成请求。
在一个实施例中，步骤S103包括：
接收所述后台服务系统通过所述安全加密通道发送的所述SM4白盒密钥和所述SM2公钥。
在应用中，由于SM4白盒密钥和SM2公钥不属于特别敏感的信息，可以直接基于安全加密通道进行加密传输，不需要在安全加密通道的基础上进行第二次加密保护。
图3所对应的实施例通过建立电子支付应用与后台服务系统之间的安全加密通道来实现二者之间的数据交互，可以有效保障二者之间的数据交互安全。
如图4和图5所示，基于上述加密方法实施例，本申请实施例提供的支付密钥的解密方法，包括如下步骤S401至S404：
步骤S401、读取保存的支付密钥密文。
在应用中，在对已保存的支付密钥密文进行解密时，需要先从电子支付应用的私有文件中读取支付密钥密文。
步骤S402、将所述支付密钥密文发送给后台服务系统；其中，所述后台服务系统用于通过SM2私钥第一次解密所述支付密钥密文。
在应用中，在对读取的支付密钥密文进行解密之前，需要先将其发送给后台服务系统，具体可以通过安全加密通道将支付密钥密文发送给后台服务系统。后台服务系统接收到支付密钥密文之后，利用事先存储在其加密机中的SM2私钥对支付密钥密文进行第一次解密，然后发送给电子支付应用，具体可以通过安全加密通道将第一次解密后的支付密钥密文发送给电子支付应用。
步骤S403、接收所述后台服务系统发送的第一次解密后的所述支付密钥密文；
步骤S404、通过AES密钥和SM4白盒密钥再次解密第一次解密后的所述支付密钥密文，获得支付密钥明文。
在应用中，电子支付应用接收到经过第一次解密的支付密钥密文之后，再通过AES密钥和SM4白盒密钥再次解密第一次解密后的支付密钥密文，最终得到支付密钥明文。
如图5所示，在一个实施例中，步骤S404包括：
通过AES密钥第二次解密所述支付密钥密文，通过SM4白盒密钥第三次解密所述支付密钥密文，获得支付密钥明文。
在应用中，支付密钥密文依次通过SM2私钥、AES密钥和SM4白盒密钥进行解密，最终得到经过三次解密后的支付密钥明文。
图4所对应的实施例使得对支付密钥密文的解密操作必须访问后台服务系统中的SM2私钥才能实现，但限制后台服务系统直接还原出支付密钥明文，需要通过AES密钥和SM4白盒密钥再次解密后才能获得支付密钥明文，可以提高对支付密钥明文的保护强度。图5所对应的实施例通过对支付密钥密文进行三次解密才能获得支付密钥明文，可以进一步提高对支付密钥明文的保护强度。
如图6和7所示，基于上述加密方法和解密方法实施例，本申请还提供一种安全加密秘钥的更新方法，包括如下步骤S601至S603：
步骤S601、通过所述加密方法生成新的安全加密密钥；其中，所述安全加密密钥包括AES文件密钥、AES密钥、SM4白盒密钥、SM2公钥和SM2私钥。
在应用中，安全加密秘钥（Session Encryption Key，SEK）使用一段时间之后，为了提高安全性需要进行更新。安全加密密钥的更新方法与上述加密方法中生成AES文件密钥、AES密钥、SM4白盒密钥、SM2公钥和SM2私钥的流程和原理相同，具体包括如下步骤：
通过密钥库管理系统生成新的AES文件密钥和新的AES密钥；
向后台服务系统发送新的密钥生成请求；其中，所述后台服务系统用于响应所述新的密钥生成请求生成新的SM4白盒密钥、新的SM2公钥和新的SM2私钥，并保存所述新的SM2私钥；
接收所述后台服务系统发送的所述新的SM4白盒密钥和所述新的SM2公钥；
通过所述AES文件密钥加密所述新的SM4白盒密钥和所述新的SM2公钥，生成所述新的SM4白盒密钥和所述新的SM2公钥的密文并保存。
步骤S602、通过所述加密方法采用所述新的安全加密密钥加密所述支付密钥明文，生成新的支付密钥密文。
在应用中，在生成新的安全加密密钥之后，继续采用与上述加密方法中相同的流程和原理来加密支付密码明文，具体包括如下步骤：
通过所述新的SM4白盒密钥、所述新的AES密钥和所述新的SM2公钥加密电子支付系统下发的支付密钥明文，生成支付密钥密文并保存。
步骤S603、删除旧的安全加密密钥。
在应用中，旧的安全加密密钥即是指更新之前的AES文件密钥、AES密钥、SM4白盒密钥、SM2公钥和SM2私钥。在完成对旧的安全加密密钥的更新之后，也可以不删除旧的安全加密密钥，此时电子支付应用同时保存有新旧两个安全加密密钥，此时新旧两个安全加密密钥都可以正常使用，处于新旧两个安全加密密钥交替的过渡期，一旦旧的安全加密密钥被删除，则只能使用新的安全加密密钥。不排除电子支付应用可以同时保存过去一段时间内更新的所有安全加密密钥，也即可以同时保存至少两个安全加密密钥。
图6和图7所对应的实施例通过对安全加密密钥进行更新，可以有效降低安全加密密钥长时间使用所存在的被破解的风险。
如图8和9所示，在一个实施例中，基于上述加密方法、解密方法或更新方法实施例，本申请还提供一种安全加密秘钥的删除方法，包括如下步骤S801和S802：
步骤S801、删除旧的AES文件密钥、旧的AES密钥、旧的SM4白盒密钥和旧的SM2公钥。
在应用中，在两种情况下，需要执行删除安全加密秘钥的操作，一种是在完成对旧的安全加密密钥的更新之后，可以删除旧的安全加密密钥，仅保留新的安全加密密钥；另一种是在电子支付应用检测到支付环境不安全时，需要删除安全加密密钥。也即删除安全加密密钥的操作可以在上述加密方法、解密方法或更新方法实施例中任一个的基础上执行，可以仅删除旧的安全加密密钥，也可以删除全部安全加密密钥。
如图9所示，在一个实施例中，步骤S801包括：
删除旧的AES文件密钥和旧的AES密钥；
将旧的SM4白盒密钥和旧的SM2公钥都设置为0。
在应用中，电子支付应用在执行删除AES文件密钥、AES密钥、SM4白盒密钥和SM2公钥的操作时，需要删除AES文件密钥和AES密钥，并将SM4白盒密钥和SM2公钥设置为0。
步骤S802、向所述后台服务系统发送删除请求；其中，所述后台服务系统用于响应所述删除请求删除旧的SM2私钥。
在应用中，电子支付应用完成删除AES文件密钥、AES密钥、SM4白盒密钥和SM2公钥的操作时，向后台服务系统发送用于删除SM2私钥的删除请求，后台服务系统接收到该删除请求之后，响应并执行删除SM2私钥的操作。
图8和图9所对应的实施例通过删除旧的安全加密密钥，可以实现对安全加密密钥的更新，还可以防止在支付安全不安全时安全加密密钥被篡改。
如图10所示，基于上述解密方法或更新方法实施例，本申请还提供一种支付认证方法，包括如下步骤S1001至S1005：
步骤S1001、采集支付数据。
在应用中，根据电子支付应用所支持的电子支付方式的不同，采集支付数据的方式也不同。例如，电子支付应用可以支持有卡支付和无卡支付中的至少一种；其中，支持有卡支付时，可以通过读卡器来采集磁卡（Magnetic Card）、接触式IC卡（Integrated Circuit Card）及非接触式卡（Non-Contacted Card）等中的至少一种支付卡的支付数据；支持无卡支付时，可以通过终端设备所支持的人机交互设备来采集生物特征数据、口令数据、编码数据及数字证书（Digital Certificate）数据中的至少一种。生物特征数据可以包括基于人脸识别的人脸数据、基于指纹识别技术的指纹（Finger Print）数据、基于电子签名（Electronic Signature）识别技术的电子签名数据、基于声纹识别技术的声纹数据等。电子签名是指数据电文中以电子形式所含、所附用于识别签名人身份并表明签名人认可其中内容的数据。口令认证数据为通过用户名和口令进行登录的用户数据，口令可以是用户自行设置的固定密码，也可以是由支付相关的计算设备生成的动态口令（即动态密码）。编码认证数据可以包括基于一维码识别技术的一维码数据或基于二维码识别技术的二维码数据，一维码具体可指一维条形码。数字证书是指在互联网通讯中标志通讯各方身份信息的一个数字认证，可以在互联网中用它来识别身份，数字证书包括移动证书和浏览器证书两种，移动证书使用优盾（U-KEY）类载体作为数字证书的加密和存储的设备，浏览器证书使用计算机类载体作为下载和安装数字证书的设备。
在应用中，读卡器可以包括磁卡读卡器、接触式IC卡读卡器、非接触式卡读卡器等，非接触式读卡器可以为近场通信（Near Field Communication，NFC）读卡器。人机交互设备可以包括用于采集生物特征数据的摄像头、指纹模块、电子签名板（Electronic Signature Panel）、麦克风等生物特征采集设备，用于采集口令数据的键盘、触控屏等，用于采集编码的摄像头或扫码枪等编码采集设备，用于采集数字证书的优盾等。电子签名板可以采用触控屏代替。
步骤S1002、通过支付密钥明文加密所述支付数据，生成支付数据密文。
在应用中，在需要加密支付数据时，先从电子支付应用的私有文件中读取支付密钥密文，再经过安全加密密钥解密后得到支付密钥明文。使用支付密钥明文加密支付数据时，支付密钥明文会短暂出现在终端设备的内存中，加密结束后必须立即清除内存中的支付密钥明文，以防止支付密钥明文被窃取或篡改，保障支付安全。
步骤S1003、加密交易数据和所述支付数据密文，生成交易信息。
在应用中，在加密支付数据之后，可以采用任意通过的加密算法对交易数据和支付数据密文进行第二次加密，生成交易信息。
步骤S1004、将所述交易信息上传至电子支付系统；其中，所述电子支付系统用于解密所述交易信息，获得所述交易数据和所述支付数据，校验所述支付数据是否合法，在所述支付数据合法时批准所述交易数据对应的交易，在所述支付数据不合法时拒绝所述交易数据对应的交易，并生成支付反馈信息。
在应用中，在生成交易信息之后将其传至电子支付系统进行交易验证。电子支付系统接收到交易信息之后，先解密交易信息获得交易数据和支付数据，然后校验支付数据是否合法，若合法，则批准交易，否则拒绝交易，并生成相应的支付反馈信息发送给电子支付应用，支付反馈信息可以包括表征交易成功、交易失败、余额不足、支付数据校验失败等的信息。
步骤S1005、接收所述电子支付系统下发的所述支付反馈信息。
在应用中，电子支付应用接收到支付反馈信息之后可以采用终端设备所支持的任意人机交互方式，将交易结果告知用户，例如，通过显示、语音、图像等方式告知用户交易结果。
图10所对应的实施例可以在对加密秘钥明文进行有效保护的前提下，实现对支付数据的双重加密，从而有效保障电子支付安全。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
如图11所示，本申请实施例提供的终端设备100包括：至少一个处理器10（图11中仅示出一个处理器）、存储器20以及存储在存储器20中并可在至少一个处理器10上运行的计算机程序21，处理器10执行计算机程序21时实现上述各个方法实施例中的步骤。
示例性的，计算机程序可以被分割成一个或多个模块，所述一个或者多个模块被存储在存储器中，并由处理器运行，以完成本申请。所述一个或多个模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序在终端设备中的执行过程。例如，所述计算机程序可以被分割成如下功能模块：
第一密钥生成模块，用于通过密钥库管理系统生成AES文件密钥和AES密钥；
第一发送模块，用于向后台服务系统发送密钥生成请求；其中，所述后台服务系统用于响应所述密钥生成请求生成SM4白盒密钥、SM2公钥和SM2私钥，并保存所述SM2私钥；
第一接收模块，用于接收所述后台服务系统发送的所述SM4白盒密钥和所述SM2公钥；
第二密钥生成模块，用于通过所述AES文件密钥加密所述SM4白盒密钥和所述SM2公钥，生成所述SM4白盒密钥和所述SM2公钥的密文并保存；
第一加密模块，用于通过所述SM4白盒密钥、所述AES密钥和所述SM2公钥加密电子支付系统下发的支付密钥明文，生成支付密钥密文并保存。
在一个实施例中，所述计算机程序还可以被分割成如下功能模块：
第一通信模块，用于与后台服务系统建立通信连接；
验证模块，用于通过CA公钥验证所述后台服务系统下发的证书；
第一比较模块，用于在所述后台服务系统下发的证书验证通过时，比较所述后台服务系统下发的证书的URL和所述后台服务系统的URL是否一致；
第二比较模块，用于在所述证书的URL和所述后台服务系统的URL一致时，将预先硬编码的所述后台服务系统的证书和所述后台服务系统下发的证书进行二进制比较；
判定模块，在预先硬编码的所述后台服务系统的证书与所述后台服务系统下发的证书一致时，判定所述后台服务系统合法；
第二通信模块，用于与后台服务系统建立安全加密通道。
在一个实施例中，所述计算机程序还可以被分割成如下功能模块：
读模块，用于读取保存的支付密钥密文；
第二发送模块，用于将所述支付密钥密文发送给后台服务系统；其中，所述后台服务系统用于通过SM2私钥第一次解密所述支付密钥密文；
第二接收模块，用于接收所述后台服务系统发送的第一次解密后的所述支付密钥密文；
解密模块，用于通过AES密钥和SM4白盒密钥再次解密第一次解密后的所述支付密钥密文，获得支付密钥明文。
在一个实施例中，所述计算机程序还可以被分割成如下功能模块：
第二密钥生成模块，用于通过所述加密方法生成新的安全加密密钥；其中，所述安全加密密钥包括AES文件密钥、AES密钥、SM4白盒密钥、SM2公钥和SM2私钥。
第二加密模块，用于通过所述加密方法采用所述新的安全加密密钥加密所述支付密钥明文，生成新的支付密钥密文。
删除模块，用于删除旧的安全加密密钥。
在一个实施例中，所述删除模块具体用于：
删除旧的AES文件密钥、旧的AES密钥、旧的SM4白盒密钥和旧的SM2公钥；
向所述后台服务系统发送删除请求；其中，所述后台服务系统用于响应所述删除请求删除旧的SM2私钥。
在一个实施例中，所述计算机程序还可以被分割成如下功能模块：
数据采集模块，用于采集支付数据。
第三加密模块，用于通过支付密钥明文加密所述支付数据，生成支付数据密文。
第四加密模块，用于加密交易数据和所述支付数据密文，生成交易信息。
第三发送模块，用于将所述交易信息上传至电子支付系统。
第三接收模块，用于接收所述电子支付系统下发的所述支付反馈信息。
在应用中，上述各软件程序模块，也可以通过处理器中集成的不同逻辑电路实现，还可以通过多个分布式处理器实现。
在应用中，终端设备可包括但不仅限于，处理器和存储器，可以包括比图更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。
需要说明的是，上述模块之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中，上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。另外，各功能模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述装置中模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。
本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行时实现可实现上述各个方法实施例中的步骤。
集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，计算机程序包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质至少可以包括：能够将计算机程序代码携带到管理系统的任何实体或装置、记录介质、计算机存储器、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的模块及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在本申请所提供的实施例中，应该理解到，所揭露的设备、方法和存储介质，可以通过其它的方式实现。作为分离部件说明的模块可以是或者也可以不是物理上分开的，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

  1. 一种支付密钥的加密方法，其特征在于，包括：
    通过密钥库管理系统生成AES文件密钥和AES密钥；
    向后台服务系统发送密钥生成请求；其中，所述后台服务系统用于响应所述密钥生成请求生成SM4白盒密钥、SM2公钥和SM2私钥，并保存所述SM2私钥；
    接收所述后台服务系统发送的所述SM4白盒密钥和所述SM2公钥；
    通过所述AES文件密钥加密所述SM4白盒密钥和所述SM2公钥，生成所述SM4白盒密钥和所述SM2公钥的密文并保存；
    通过所述SM4白盒密钥、所述AES密钥和所述SM2公钥加密电子支付系统下发的支付密钥明文，生成支付密钥密文并保存。
  2. 如权利要求1所述的支付密钥的加密方法，其特征在于，所述通过所述SM4白盒密钥、所述AES密钥和所述SM2公钥加密电子支付系统下发的支付密钥明文，生成支付密钥密文并保存，包括：
    通过所述SM4白盒密钥第一次加密电子支付系统下发的支付密钥明文，通过所述AES密钥第二次加密所述支付密钥，通所述SM2公钥第三次加密所述支付密钥，生成支付密钥密文并保存。
  3. 如权利要求1或2所述的支付密钥的加密方法，其特征在于，所述向后台服务系统发送密钥生成请求之前，包括：
    与后台服务系统建立安全加密通道；
    所述向后台服务系统发送密钥生成请求，包括：
    通过所述安全加密通道向所述后台服务系统发送密钥生成请求；
    所述接收所述后台服务系统发送的所述SM4白盒密钥和所述SM2公钥，包括：
    接收所述后台服务系统通过所述安全加密通道发送的所述SM4白盒密钥和所述SM2公钥。
  4. 如权利要求3所述的支付密钥的加密方法，其特征在于，所述与后台服务系统建立安全加密通道之前，包括：
    与后台服务系统建立通信连接；
    通过CA公钥验证所述后台服务系统下发的证书；
    在所述后台服务系统下发的证书验证通过时，比较所述后台服务系统下发的证书的URL和所述后台服务系统的URL是否一致；
    在所述证书的URL和所述后台服务系统的URL一致时，将预先硬编码的所述后台服务系统的证书和所述后台服务系统下发的证书进行二进制比较；
    在预先硬编码的所述后台服务系统的证书与所述后台服务系统下发的证书一致时，判定所述后台服务系统合法。
  5. 一种支付密钥的解密方法，其特征在于，基于如权利要求1至4任一项所述的支付密钥的加密方法实现，所述解密方法包括：
    读取保存的支付密钥密文；
    将所述支付密钥密文发送给后台服务系统；其中，所述后台服务系统用于通过SM2私钥第一次解密所述支付密钥密文；
    接收所述后台服务系统发送的第一次解密后的所述支付密钥密文；
    通过AES密钥和SM4白盒密钥再次解密第一次解密后的所述支付密钥密文，获得支付密钥明文。
  6. 如权利要求5所述的支付密钥的解密方法，其特征在于，所述通过AES密钥和SM4白盒密钥再次解密第一次解密后的所述支付密钥密文，获得支付密钥明文，包括：
    通过AES密钥第二次解密所述支付密钥密文，通过SM4白盒密钥第三次解密所述支付密钥密文，获得支付密钥明文。
  7. 如权利要求5所述的支付密钥的解密方法，其特征在于，还包括：
    通过所述加密方法生成新的安全加密密钥；其中，所述安全加密密钥包括AES文件密钥、AES密钥、SM4白盒密钥、SM2公钥和SM2私钥；
    通过所述加密方法采用所述新的安全加密密钥加密所述支付密钥明文，生成新的支付密钥密文并保存。
  8. 如权利要求5至7任一项所述的支付密钥的解密方法，其特征在于，还包括：
    删除旧的AES文件密钥、旧的AES密钥、旧的SM4白盒密钥和旧的SM2公钥；
    向所述后台服务系统发送删除请求；其中，所述后台服务系统用于响应所述删除请求删除旧的SM2私钥。
  9. 一种支付认证方法，其特征在于，基于如权利要求5至8任一项所述的支付密钥的解密方法实现，所述支付认证方法包括：
    采集支付数据；
    通过支付密钥明文加密所述支付数据，生成支付数据密文；
    加密交易数据和所述支付数据密文，生成交易信息；
    将所述交易信息上传至电子支付系统；其中，所述电子支付系统用于解密所述交易信息，获得所述交易数据和所述支付数据，校验所述支付数据是否合法，在所述支付数据合法时批准所述交易数据对应的交易，在所述支付数据不合法时拒绝所述交易数据对应的交易，并生成支付反馈信息；
    接收所述电子支付系统下发的所述支付反馈信息。
  10. 一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至9任一项所述方法的步骤。
PCT/CN2021/123462 2020-10-14 2021-10-13 支付密钥的加密和解密方法、支付认证方法及终端设备 WO2022078367A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/027,962 US20230368194A1 (en) 2020-10-14 2021-10-13 Encryption method and decryption method for payment key, payment authentication method, and terminal device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011099201.3A CN112232814B (zh) 2020-10-14 2020-10-14 支付密钥的加密和解密方法、支付认证方法及终端设备
CN202011099201.3 2020-10-14

Publications (1)

Publication Number Publication Date
WO2022078367A1 true WO2022078367A1 (zh) 2022-04-21

Family

ID=74113673

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/123462 WO2022078367A1 (zh) 2020-10-14 2021-10-13 支付密钥的加密和解密方法、支付认证方法及终端设备

Country Status (3)

Country Link
US (1) US20230368194A1 (zh)
CN (1) CN112232814B (zh)
WO (1) WO2022078367A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115001703A (zh) * 2022-05-25 2022-09-02 深圳市证通电子股份有限公司 一种基于国密加密机的堡垒机安全提升方法

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11538031B2 (en) 2017-03-31 2022-12-27 Vijay Madisetti Method and system for identity and access management for blockchain interoperability
CN112232814B (zh) * 2020-10-14 2023-10-27 深圳市百富智能新技术有限公司 支付密钥的加密和解密方法、支付认证方法及终端设备
CN113673976A (zh) * 2021-08-13 2021-11-19 支付宝(杭州)信息技术有限公司 应用于车辆的支付处理方法及装置
CN115174136B (zh) * 2022-05-23 2024-02-02 北京旷视科技有限公司 数据获取和数据传送方法、终端、服务器及存储介质
CN116596542A (zh) * 2023-05-24 2023-08-15 广东科谊网络技术有限公司 移动安全支付方法及系统
CN116582266B (zh) * 2023-07-13 2023-09-29 鼎铉商用密码测评技术(深圳)有限公司 电子签章方法、电子签章系统以及可读存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150310431A1 (en) * 2014-04-23 2015-10-29 Minkasu, Inc. Secure Payments Using a Mobile Wallet Application
CN106850522A (zh) * 2016-05-24 2017-06-13 中国科学院信息工程研究所 一种即时通信中群组文件加密传输的实现方法
CN107181754A (zh) * 2017-06-06 2017-09-19 江苏信源久安信息科技有限公司 一种对网络文件加解密授权多人分享的方法
CN108616516A (zh) * 2018-04-03 2018-10-02 四川新网银行股份有限公司 一种基于多种加密算法的第三方明文口令校验方法
EP3447667A1 (de) * 2017-08-23 2019-02-27 Bundesdruckerei GmbH Kryptographische sicherung für eine verteilte datenspeicherung
CN112232814A (zh) * 2020-10-14 2021-01-15 深圳市百富智能新技术有限公司 支付密钥的加密和解密方法、支付认证方法及终端设备

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150310431A1 (en) * 2014-04-23 2015-10-29 Minkasu, Inc. Secure Payments Using a Mobile Wallet Application
CN106850522A (zh) * 2016-05-24 2017-06-13 中国科学院信息工程研究所 一种即时通信中群组文件加密传输的实现方法
CN107181754A (zh) * 2017-06-06 2017-09-19 江苏信源久安信息科技有限公司 一种对网络文件加解密授权多人分享的方法
EP3447667A1 (de) * 2017-08-23 2019-02-27 Bundesdruckerei GmbH Kryptographische sicherung für eine verteilte datenspeicherung
CN108616516A (zh) * 2018-04-03 2018-10-02 四川新网银行股份有限公司 一种基于多种加密算法的第三方明文口令校验方法
CN112232814A (zh) * 2020-10-14 2021-01-15 深圳市百富智能新技术有限公司 支付密钥的加密和解密方法、支付认证方法及终端设备

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115001703A (zh) * 2022-05-25 2022-09-02 深圳市证通电子股份有限公司 一种基于国密加密机的堡垒机安全提升方法
CN115001703B (zh) * 2022-05-25 2023-09-01 深圳市证通电子股份有限公司 一种基于国密加密机的堡垒机安全提升方法

Also Published As

Publication number Publication date
CN112232814A (zh) 2021-01-15
US20230368194A1 (en) 2023-11-16
CN112232814B (zh) 2023-10-27

Similar Documents

Publication Publication Date Title
WO2022078367A1 (zh) 支付密钥的加密和解密方法、支付认证方法及终端设备
US8386795B2 (en) Information security device of Universal Serial Bus Human Interface Device class and data transmission method for same
EP2999189B1 (en) Network authentication method for secure electronic transactions
CN110798315B (zh) 基于区块链的数据处理方法、装置及终端
CA2914956C (en) System and method for encryption
CN101651675A (zh) 提高网络交易安全性的方法和系统
CN102710611A (zh) 网络安全身份认证方法和系统
US20070180507A1 (en) Information security device of universal serial bus human interface device class and data transmission method for same
CN108460597B (zh) 一种密钥管理系统及方法
CN110620763A (zh) 一种基于移动端app的移动身份认证方法及系统
CN110601836B (zh) 密钥获取方法、装置、服务器和介质
KR101498120B1 (ko) 클라우드 공인인증 시스템 및 그 방법
CN112202794A (zh) 交易数据的保护方法、装置、电子设备和介质
CN2914498Y (zh) 基于通用串行总线人机交互类设备的信息安全设备
JP2902087B2 (ja) Ｉｃカードによる電子署名方法
CN113904850A (zh) 基于区块链私钥keystore安全登录方法、生成方法、系统及电子设备
WO2011060739A1 (zh) 一种安全系统及方法
CN1889420B (zh) 一种实现加密的方法
CN113452528B (zh) 请求处理方法、系统、计算机设备和介质
WO2011060738A1 (zh) 一种确认cpu卡内数据的方法
KR20040031434A (ko) 모바일 디바이스를 이용한 실시간 계좌 정보 수신 시스템및 그 서비스 방법
KR20140047058A (ko) 클라우드 공인인증 시스템 및 그 제공방법
CN114900309A (zh) 一种将信息化应用系统的用户身份标识与区块链链账户对应的方法
CN114900307A (zh) 一种基于区块链的盾及其可信监测系统
CN116743375A (zh) 一种密钥传输方法、装置、设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21879410

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205N DATED 07/06/2023)

122 Ep: pct application non-entry in european phase

Ref document number: 21879410

Country of ref document: EP

Kind code of ref document: A1