Data processing method and device, electronic equipment, computer readable storage medium and computer program product

Abstract

The invention provides a data processing method and device, electronic equipment, a computer readable storage medium and a computer program product. The method comprises the steps that a data binding request sent by a client is received, and the data binding request carries an object identifier of a target object and sensitive data of the target object; performing hash processing on the sensitive data to obtain a corresponding hash value; obtaining a root key from a key management system, and generating an encryption key for the sensitive data based on the root key, the object identifier and the hash value; encrypting the sensitive data based on the encryption key to obtain ciphertext data, and destroying the encryption key; and constructing a data record comprising the object identifier, the hash value and the ciphertext data, and storing the data record in a pre-created business data table. According to the method and the device, the security of the data can be remarkably improved while the operation and maintenance overhead is reduced.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] With the rapid development of mobile internet and fintech, third-party payment, aggregated payment, and various consumer finance applications have become deeply integrated into users' daily lives. In these business scenarios, users typically need to bind their bank cards, credit card numbers, or ID card numbers to platform accounts for quick payments. Taking credit card numbers as an example, traditional credit card number encryption schemes usually use a globally unified key to encrypt and store all card numbers for all users. This scheme uses a single key to encrypt all card number fields in the database. The encryption key is usually stored in a key management system or configuration file, and all encryption and decryption operations call the same key instance. When the key is compromised due to configuration file leaks, memory dump attacks, or malicious theft by internal personnel, attackers can decrypt all card number data in the database in batches, causing large-scale data breaches. Summary of the Invention

[0003] This application provides a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product that can significantly improve data security while reducing maintenance costs.

[0004] The technical solution of this application embodiment is implemented as follows: This application provides a data processing method, including: Receive a data binding request sent by a client, wherein the data binding request carries the object identifier of the target object and the sensitive data of the target object; The sensitive data is hashed to obtain the corresponding hash value; Obtain the root key from the key management system, and generate an encryption key for the sensitive data based on the root key, the object identifier, and the hash value; The sensitive data is encrypted using the encryption key to obtain ciphertext data, and the encryption key is then destroyed. Construct a data record including the object identifier, the hash value, and the ciphertext data, and store the data record in a pre-created business data table.

[0005] This application provides a data processing apparatus, including: A receiving module is used to receive a data binding request sent by a client, wherein the data binding request carries the object identifier of the target object and the sensitive data of the target object; The hash module is used to perform hash processing on the sensitive data to obtain the corresponding hash value; The acquisition module is used to obtain the root key from the key management system; The generation module is used to generate an encryption key for the sensitive data based on the root key, the object identifier, and the hash value. An encryption module is used to encrypt the sensitive data based on the encryption key to obtain ciphertext data; The destruction module is used to destroy the encryption key; The construction module is used to construct a data record including the object identifier, the hash value, and the ciphertext data; The storage module is used to store the data records into a pre-created business data table.

[0006] In the above scheme, the generation module is further configured to obtain a preset key derivation function; use the hash value as the salt value parameter of the key derivation function, and use the object identifier as the context information parameter of the key derivation function; input the root key, the salt value parameter, and the context information parameter into the key derivation function, and use the output result of the key derivation function as the encryption key for the sensitive data.

[0007] In the above scheme, the encryption module is further configured to randomly generate an initialization vector of fixed length; encrypt the sensitive data using the encryption key and the initialization vector to obtain an encryption payload; obtain the version identifier of the root key; and concatenate the version identifier, the initialization vector, and the encryption payload to obtain ciphertext data.

[0008] In the above scheme, the encryption module is further configured to initialize an encryption instance using the encryption key and the initialization vector; convert the sensitive data into ciphertext fragments and generate an authentication tag for the sensitive data through the encryption instance; and combine the ciphertext fragments and the authentication tag to obtain the encryption payload.

[0009] In the above scheme, the hash module is further used to obtain a pre-configured system-level interference code, wherein the system-level interference code is stored in an application configuration file or environment variable; mix the sensitive data and the system-level interference code according to a preset rule to obtain mixed data; perform a digest algorithm calculation on the mixed data, and use the calculated digest result as the hash value corresponding to the sensitive data.

[0010] In the above scheme, the hash module is further configured to generate a first key padding value and a second key padding value based on a preset hash key; concatenate the first key padding value with the sensitive data to obtain a first concatenation result, and perform a hash operation on the first concatenation result to obtain an inner hash digest; concatenate the second key padding value with the inner hash digest to obtain a second concatenation result, and perform a hash operation on the second concatenation result to obtain a hash value corresponding to the sensitive data.

[0011] In the above scheme, the construction module is further configured to generate a structured record containing a metadata area and a data entity area according to a predefined storage protocol; write the object identifier and the hash value into the metadata area, and write the ciphertext data into the data entity area; and establish a logical association between the metadata area and the data entity area to form a logically complete data record.

[0012] In the above scheme, the construction module is further configured to obtain the organization code of the organization associated with the sensitive data, and extract the last character fragment of the sensitive data; combine the organization code and the last character fragment into plaintext index data; and construct a composite data record including the object identifier, the plaintext index data, the hash value, and the ciphertext data.

[0013] In the above scheme, the device further includes a verification module, which is used to perform the following processing before the hash module performs hash processing on the sensitive data: performing format validity verification on the sensitive data based on preset verification rules; when the sensitive data passes the format validity verification, proceeding to the step of performing hash processing on the sensitive data.

[0014] In the above scheme, the device further includes a return module, which is used to return a prompt message to the client indicating that the sensitive data is incorrect when the sensitive data fails the format validity check.

[0015] In the above scheme, the device further includes a query module, which is used to query the pre-created business data table based on the hash value before the storage module stores the data record into the pre-created business data table; the storage module is also used to store the data record into the business data table when there is no data record including the hash value in the business data table.

[0016] In the above scheme, the return module is further configured to refuse to store the data record in the business data table when there is a data record in the business data table that includes the hash value, and to return a prompt message to the client indicating that the sensitive data has been bound.

[0017] In the above scheme, after the storage module stores the data record into a pre-created business data table, the receiving module is further configured to receive a data query request sent by the client, wherein the data query request carries the object identifier and the encrypted data; the query module is further configured to query the business data table based on the object identifier and the encrypted data to obtain a data record including the object identifier and the encrypted data, and extract the hash value from the queried data record; the acquisition module is further configured to acquire a root key from the key management system; the generation module is further configured to generate a decryption key based on the root key, the hash value, and the object identifier; the device further includes a decryption module, configured to decrypt the encrypted data using the decryption key to obtain the sensitive data; the destruction module is further configured to destroy the decryption key; and the return module is further configured to return the sensitive data to the client.

[0018] In the above scheme, the ciphertext data includes a version identifier of the root key used during encryption; the acquisition module is further configured to parse the ciphertext data to obtain the version identifier of the root key used during encryption; and to obtain the root key corresponding to the version identifier from the key management system.

[0019] In the above scheme, after the decryption module decrypts the ciphertext data using the decryption key, the acquisition module is further configured to obtain the version identifier of the latest root key from the key management system; the generation module is further configured to generate a new encryption key based on the latest root key, the hash value, and the object identifier when the version identifier parsed from the ciphertext data is earlier than the version identifier of the latest root key; the encryption module is further configured to encrypt the sensitive data using the new encryption key to obtain new ciphertext data; the construction module is further configured to construct a new data record including the new ciphertext data, the hash value, and the object identifier; the device further includes a replacement module, configured to replace the data record stored in the business data table with the new data record.

[0020] In the above scheme, the object identifier is obtained by the client in the following way: in response to the login instruction initiated by the target object, the client is redirected to the authorization page of the third-party open platform based on the standard authorization protocol; the client receives the authorization code returned by the third-party open platform after the target object confirms the authorization; the client requests an access token from the third-party open platform using the authorization code, and parses the response data of the access token to obtain the unique object identifier generated by the third-party open platform for the target object.

[0021] This application provides an electronic device, including: Memory is used to store executable instructions for a computer; The processor, when executing computer-executable instructions stored in the memory, implements the data processing method provided in the embodiments of this application.

[0022] This application provides a computer-readable storage medium storing computer-executable instructions for implementing the data processing method provided in this application when executed by a processor.

[0023] This application provides a computer program product, including a computer program or computer executable instructions, which, when executed by a processor, implements the data processing method provided in this application.

[0024] The embodiments of this application have the following beneficial effects: This application introduces a dynamic key derivation mechanism based on a root key combined with object identifiers and hash values. This means that there is "one key per data" within the system. If a single user's encryption key is stolen in memory, an attacker can only decrypt that specific piece of data belonging to that particular user, and cannot decrypt other data in the database. This greatly enhances the system's resistance to attacks and data isolation. Furthermore, by incorporating the object identifier as a parameter into the encryption key generation process, data ownership is cryptographically bound. This means that even if user A's data is mistakenly copied to user B's record, the generated key will fail to decrypt the ciphertext correctly due to the mismatched object identifiers provided during decryption. This provides a second layer of strong verification beyond the code logic for data integrity and ownership. In addition, this application also employs a "use-and-burn" key management strategy, destroying the encryption key immediately after encryption. This stateless key usage method compresses the exposure window of the encryption key in memory to an extremely short time, greatly reducing the risk of key theft due to server intrusion or memory leaks. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the architecture of the data processing system 100 provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of the electronic device 500 provided in the embodiments of this application; Figure 3 This is a first flowchart illustrating the data processing method provided in an embodiment of this application; Figure 4 This is a second flowchart illustrating the data processing method provided in the embodiments of this application; Figure 5 This is a schematic diagram illustrating an application scenario of the data processing method provided in the embodiments of this application; Figure 6This is a schematic diagram of the architecture of the data processing system provided in the embodiments of this application; Figure 7 This is a schematic diagram of the third process of the data processing method provided in the embodiments of this application; Figure 8 This is a schematic diagram of the first process of the data processing method provided in the embodiments of this application; Figure 9 This is a schematic diagram of the second process of the data processing method provided in the embodiments of this application; Figure 10 This is a schematic diagram of the fourth process of the data processing method provided in the embodiments of this application; Figure 11 This is a schematic diagram of the third process of the data processing method provided in the embodiments of this application; Figure 12 This is a schematic diagram of the fourth process of the data processing method provided in the embodiments of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0028] It is understood that in the embodiments of this application, data such as user information are involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0029] In the following description, the terms “first, second, ...” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first, second, ...” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0030] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0031] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0032] 1) Responding to: used to indicate the conditions or states on which the operation is performed depends. When the conditions or states on which it depends are met, one or more operations can be performed in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations are performed.

[0033] 2) Sensitive data: refers to data involving user privacy, property security, or trade secrets, which, if leaked, illegally provided, or misused, may endanger the user's personal and property safety. In this application embodiment, sensitive data may specifically refer to data that requires encrypted storage and binding operations, including but not limited to: personal identification information (such as ID card number, passport number, biometric information, etc.); financial account information (such as bank card number, credit card number, payment account password, etc.); contact information (such as mobile phone number, email address, etc.).

[0034] 3) Object identifier: refers to a string or number sequence that uniquely identifies a target object in the server. In the embodiments of this application, the object identifier can not only be used as the primary key or index of the database, but also as the context parameter of the key derivation function to achieve data isolation at the cryptographic level.

[0035] 4) Hash processing: This refers to the process of mapping input data of arbitrary length to output data of fixed length using a one-way hash function (such as SHA-256, SM3, etc.). This process is irreversible (i.e., it is impossible to recover the plaintext from the hash value) and deterministic (i.e., the same plaintext will always produce the same hash value).

[0036] 5) Root Key: This refers to the highest-level key stored in the key management system or hardware security module. The root key is typically not used directly to encrypt specific business data, but rather as input to derive specific subkeys (i.e., encryption keys) through algorithms. The root key has an extremely high level of security and is usually protected by strict access control and round-robin policies.

[0037] 6) Encryption Key: This refers to a key generated in real time using a specific algorithm based on parameters such as the root key, object identifier, and hash value, and is used to directly encrypt sensitive data. In this embodiment, the encryption key is dynamically generated and temporary. It typically follows the principle of "one key per data" or "one key per use" and is immediately destroyed from memory after use.

[0038] 7) Key Management System (KMS): This refers to the hardware and software system used to manage the entire lifecycle of keys (e.g., generation, storage, distribution, rotation, and destruction). In this embodiment, when an encryption key needs to be generated, the server can temporarily request a root key from the key management system to ensure that the root key is not written to disk or leaked.

[0039] 8) Ciphertext data: refers to the unreadable data sequence generated after sensitive data has been processed by an encryption algorithm (such as AES-GCM, AES-CBC, etc.) and an encryption key. In the embodiments of this application, due to the use of an encryption mode containing random numbers or a dynamically derived key, even the same sensitive data will generate different ciphertext data at different times or under different object identifiers.

[0040] 9) Destruction: This refers to the operation of completely erasing data from computer memory. In this application embodiment, destroying the key (including the encryption key and the decryption key) does not only mean releasing variable references, but also means rewriting the memory area where the key is located using methods such as zero-padding or random number overwriting, in order to prevent attackers from recovering the key through memory dumps or cold start attacks.

[0041] Taking credit card numbers as an example of sensitive data, traditional credit card number encryption schemes typically use a globally unified key to encrypt and store all card numbers for all users. This scheme uses a single Advanced Encryption Standard (AES) key to encrypt all card number fields in the database. The encryption key is usually stored in a key management system or configuration file, and all encryption and decryption operations call the same key instance. The specific encryption process is as follows: obtain the global master key → encrypt the card number using the AES-GCM algorithm → store the ciphertext in the database; the decryption process is as follows: read the ciphertext from the database → decrypt using the same master key → return the plaintext card number.

[0042] To achieve finer-grained key isolation, related technologies have proposed a scheme to generate independent encryption keys for each credit card. This scheme randomly generates a 256-bit string as the Data Encryption Key (DEK) when a user binds their card. The DEK is then encrypted using the root key (or master key) stored in the KMS (Key Management System), and the encrypted DEK is stored in a separate key table. The card number is encrypted using the corresponding DEK. The corresponding storage architecture is as follows: Key storage table (including unique card identifier, DEK encrypted with the master key, creation time, and key version); Card binding table (including user identifier, card identifier, encrypted card number, and bank code). The specific encryption process is as follows: Generate a 256-bit random DEK → Obtain the master key from the KMS and encrypt the DEK using the master key → Store the card identifier and the encrypted DEK in the key size table → Encrypt the plaintext card number using the DEK → Add the user identifier, card identifier, and encrypted card number size to the card binding table. The decryption process is as follows: Query the encrypted DEK from the key storage table based on the card identifier → Obtain the master key from KMS and use the master key to decrypt the encrypted DEK → Use the DEK to decrypt the encrypted card number in the card binding table.

[0043] However, during the implementation of the embodiments of this application, the applicant discovered that for the globally unified key scheme, since the scheme uses the same encryption key for all card numbers of all users, when the key is compromised due to reasons such as configuration file leakage, memory dump attacks, or malicious theft by internal personnel, attackers can decrypt all card number data in the database in batches, causing large-scale data leakage incidents. Furthermore, this scheme fails to meet the requirements of financial security standards such as PCI DSS 3.2.1 for graded protection of sensitive data and minimum impact scope, and does not comply with regulatory compliance requirements. In addition, for the single-card single-key scheme provided by related technologies, since this scheme requires generating and storing an independent encrypted DEK for each card, when the system user scale reaches millions and each user binds 2-3 cards, the key storage table needs to maintain millions of records, with each record storing 32-64 bytes of encrypted DEK, resulting in high storage costs. At the same time, the complexity of key management also increases significantly. For example, when the master key is rotated, all DEKs need to be re-encrypted, key table backup and recovery need to be synchronized with business data, and the key table itself becomes a high-value attack target, requiring strict access control and auditing policies, increasing the system maintenance burden and security risks.

[0044] Furthermore, the applicant discovered that existing credit card management systems typically require maintaining separate user tables to store user names, phone numbers, password hashes, and other private data, increasing the attack surface for user privacy data breaches. They also need to implement complex authentication functions such as password policy management, account locking, and password retrieval, increasing system development and maintenance costs. Moreover, user table data must comply with regulations such as the General Data Protection Regulation (GDPR) and personal information protection laws, creating additional compliance pressure.

[0045] In view of this, embodiments of this application provide a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can significantly improve data security while reducing operation and maintenance costs. The electronic device provided in the embodiments of this application will be described below. The electronic device provided in the embodiments of this application can be implemented as a server, for example, it can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or it can be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0046] In some embodiments, see Figure 1 , Figure 1 This is a schematic diagram of the architecture of the data processing system 100 provided in the embodiments of this application, as shown below. Figure 1 As shown in the embodiments of this application, the data processing system 100 includes: a server 200, a network 300, and a terminal device 400. The network 300 can be a local area network (LAN), a wide area network (WAN), or a combination of both. The terminal device 400 is a user-associated terminal device, such as a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited to these. A client 410 runs on the terminal device 400. The client 410 can be various types of clients, such as instant messaging clients, e-commerce shopping clients, and electronic payment clients.

[0047] For example, client 410 can send a data binding request (e.g., a credit card binding request) to server 200 via network 300. This data binding request may carry the user's identifier and sensitive data (e.g., the user-entered credit card number in plaintext). Upon receiving the data binding request from client 410, server 200 can first parse the request to obtain the user identifier and sensitive data. Next, server 200 can hash the parsed sensitive data to obtain a hash value. Then, server 200 can obtain a root key from the key management system and, based on the root key, the parsed user identifier, and the hash value, generate an encryption key for the sensitive data. After obtaining the encryption key, server 200 can use it to encrypt the sensitive data, obtaining ciphertext data. After completing the encryption operation, server 200 immediately destroys the encryption key from memory. Finally, server 200 can construct a data record including the user identifier, hash value, and ciphertext data, and store the constructed data record in a pre-created business data table (e.g., a card binding table).

[0048] The structure of the electronic device provided in the embodiments of this application will be described below. Taking the electronic device as a server as an example, see... Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device 500 provided in the embodiments of this application. Figure 2 The illustrated electronic device 500 includes at least one processor 510, a memory 540, and at least one network interface 520. The various components in the electronic device 500 are coupled together via a bus system 530. It is understood that the bus system 530 is used to implement communication between these components. In addition to a data bus, the bus system 530 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 530.

[0049] The processor 510 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0050] The memory 540 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 540 may optionally include one or more storage devices physically located away from the processor 510.

[0051] The memory 540 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 540 described in this application embodiment is intended to include any suitable type of memory.

[0052] In some embodiments, memory 540 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0053] Operating system 541 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, for implementing various basic business functions and handling hardware-based tasks; The network communication module 542 is used to reach other computing devices via one or more (wired or wireless) network interfaces 520, exemplary network interfaces 520 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc. In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A data processing device 543 stored in memory 540 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a receiving module 5431, a hashing module 5432, an acquisition module 5433, a generation module 5434, an encryption module 5435, a destruction module 5436, a construction module 5437, a storage module 5438, a verification module 5439, a return module 54310, a query module 54311, a decryption module 54312, and a replacement module 54313. These modules are logically connected and can therefore be arbitrarily combined or further split according to the functions implemented. It should be noted that... Figure 2 For ease of explanation, all the above modules are shown at once, but this should not be construed as excluding the implementation of the data processing device 543 which may only include the receiving module 5431, hashing module 5432, acquisition module 5433, generation module 5434, encryption module 5435, destruction module 5436, construction module 5437, and storage module 5438. The functions of each module will be described below.

[0054] The data processing method provided in this application will be specifically described below with reference to exemplary applications and implementations of the server provided in the embodiments of this application.

[0055] For example, see Figure 3, Figure 3 This is a first flowchart illustrating the data processing method provided in the embodiments of this application, which will be combined with... Figure 3 The steps shown are explained.

[0056] In step 101, a data binding request sent by the client is received.

[0057] Here, the data binding request can carry the object identifier of the target object (i.e., the entity initiating the data binding request) and the sensitive data of the target object. Of course, the data binding request can also carry a business type identifier to distinguish different sensitive data types (e.g., distinguishing whether it is binding a bank card or an ID card).

[0058] In some embodiments, after collecting sensitive data (such as a bank card number or credit card number) input by a target object (e.g., user 1), the client can encapsulate the sensitive data and the target object's identifier (e.g., the user identifier of the currently logged-in user) into a JSON-formatted request message. To prevent data tampering during transmission, the client and server can use a secure transport layer protocol of TLS 1.2 or higher. For example, a secure transmission channel based on the SSL protocol can be established between the server and the client. The server can receive request messages sent by the client through this secure transmission channel, where the payload of the request message contains the object identifier and sensitive data. After receiving the request message sent by the client, the server can perform transport layer decryption on the received request message to parse out the plaintext data binding request. For example, in a specific electronic payment application scenario, the client can be a payment application installed on the user's terminal, the data binding request can be a "quick payment card binding request," the object identifier can be the user's account ID, used to uniquely identify the user in the business system, and the sensitive data can be the user's main bank card account number and the bank card's registered mobile phone number. After receiving the card binding request, the server can perform subsequent hash index construction and dynamic key encryption processes for the bank card's main account, thereby achieving secure binding between bank card information and user account ID.

[0059] It's worth noting that in certain high-security scenarios, before sending sensitive data to the server, the client can encrypt the sensitive data using the server's public key. In this case, after receiving the sensitive data from the client, the server can decrypt it using its private key to obtain the original plaintext sensitive data for subsequent hashing. Furthermore, to avoid wasting computational resources on invalid data, the server can first perform a validity check on the received data binding request. For example, it can verify whether the object identifier and sensitive data carried in the request are empty. If either is empty, the request is rejected and an error code is returned. Next, based on the authentication token or signature carried in the request header, the server can verify the client's identity and whether they have the authority to perform data binding. Simultaneously, the server can also verify the format of the sensitive data according to preset regular expression rules or algorithms. For example, when the sensitive data is a bank card number, the Luhn algorithm (modulo 10 algorithm) can be used to verify the validity of the card number; if the sensitive data is an ID card number, the check digits can be verified for correctness. Subsequently, the received sensitive data can be standardized, such as by removing leading and trailing spaces and special delimiters, to ensure the consistency of subsequent hash value calculations.

[0060] In other embodiments, the object identifier of the target object may be obtained by the client in the following ways: in response to a login instruction initiated by the target object, the client is redirected to the authorization page of a third-party open platform based on a standard authorization protocol (e.g., OAuth2); the client receives an authorization code returned by the third-party open platform after the target object confirms the authorization; the client requests an access token from the third-party open platform using the authorization code, and parses the response data of the access token to obtain a unique object identifier generated by the third-party open platform for the target object.

[0061] For example, the target object's identifier may not be generated locally on the client side, but rather a unique identifier obtained through authorization from a third-party open platform. For instance, when a "third-party account login" command triggered by the target object (e.g., user 1) is detected on the client interface, the client can construct an authorization request link based on the pre-configured third-party open platform interface documentation. This link can include the following key parameters: the client's registration identifier on the third-party open platform, the callback address after successful authorization, the requested permission scope (specifying that only the user identifier is obtained), and a generated random string to prevent cross-site request forgery attacks. Next, the client can load this authorization request link through a browser or built-in WebView, redirecting the page to the third-party open platform's authorization page to guide the target object to verify its identity and grant permissions. After the target object completes the verification operation on the third-party open platform's authorization page, the third-party open platform can redirect the page back to the callback address after successful authorization, appending the generated temporary authorization code and the returned random string to the callback address. The client can detect this callback address and perform the following operations: compare the returned random string with the sent random string; if they do not match, terminate the process to ensure security. Parse and extract the temporary authorization code from the callback address. Afterwards, the client can use the temporary authorization code to initiate a GET request to the token issuing endpoint of the third-party open platform. This request can carry the following parameters to prove the client's identity: the client's identity credentials (such as an application key), the temporary authorization code, and the declared authorization type. Subsequently, the client can receive the response message returned by the token issuing endpoint of the third-party open platform, parse the received response message, and extract key fields, such as the access token (credential used for subsequent API calls) and the object identifier (a unique identifier assigned to the target object by the third-party open platform). This object identifier is unique and immutable within the scope of the third-party open platform, ensuring that the object identifier is the same when the same user logs in on different devices.

[0062] In step 102, the sensitive data is hashed to obtain the corresponding hash value.

[0063] Here, the hash value can be used as a unique index identifier for sensitive data (for example, when the sensitive data is a credit card number, the hash value can be used as a card index identifier, which is irreversible and can be used for database storage, anti-duplicate card binding detection, and key derivation parameters).

[0064] In some embodiments, step 102 can be implemented as follows: Obtain a pre-configured system-level jamming code, wherein the system-level jamming code can be stored in an application configuration file or environment variable, and is not stored on the same computer-readable storage medium as the business data table; mix the sensitive data and the system-level jamming code according to a preset rule to obtain mixed data; perform a digest algorithm calculation on the mixed data, and use the calculated digest result as the hash value corresponding to the sensitive data, wherein the hash value can be used both as the salt parameter of the key derivation function and as a confusion index to prevent rainbow table attacks. Thus, by introducing a system-level jamming code, it becomes very difficult for attackers to deduce the sensitive data from the hash value, solving the technical problem of weak hash protection for low-entropy sensitive data.

[0065] For example, after parsing sensitive data from a data binding request sent by a client, the server can read a pre-configured system-level jamming code from the runtime security context. To ensure security, the storage medium for the system-level jamming code is physically or logically isolated from the storage medium of the business data table. Next, the parsed sensitive data can be "salted" using the read system-level jamming code to obtain mixed data. For example, the system-level jamming code can be appended to the beginning or end of the sensitive data, or it can be split into two parts and appended to the beginning and end of the sensitive data respectively. Alternatively, the system-level jamming code can be inserted into a specific index position in the sensitive data, or a bitwise XOR operation can be performed between the binary stream of the sensitive data and the binary stream of the system-level jamming code (ensuring length alignment or cyclic use of the jamming code). Finally, a cryptographic digest algorithm can be executed on the resulting mixed data, and the calculation result can be normalized to a string form as the final hash value. In this way, the hash value generated by the same sensitive data (such as the same bank card number) under the same system-level jamming code remains constant. This allows the system to perform equality queries and uniqueness checks by comparing hash values ​​without decryption. Furthermore, because the system-level jamming code is unknown to attackers, even if an attacker steals the database file, they cannot use the pre-calculated rainbow table to reconstruct the plaintext sensitive data. In addition, storing the system-level jamming code in environment variables or configuration files achieves key-lock separation, significantly improving the overall security level of the system.

[0066] In other embodiments, step 102 above can also be implemented in the following way: based on a preset hash key, a first key padding value and a second key padding value are generated; the first key padding value is concatenated with the sensitive data to obtain a first concatenation result, and a hash operation is performed on the first concatenation result to obtain an inner hash digest; the second key padding value is concatenated with the inner hash digest to obtain a second concatenation result, and a hash operation is performed on the second concatenation result to obtain a hash value corresponding to the sensitive data.

[0067] For example, embodiments of this application can employ a dual hash structure (i.e., HMAC structure) to generate hash values, thereby eliminating the risk of length extension attacks and enhancing the unpredictability of hash values. Specifically, a preset hash key can be obtained first. To adapt to the block size of the selected hash function (usually 64 bytes), the hash key needs to be standardized. For instance, if the key length of the hash key is greater than the block size, a hash operation can be performed on the hash key first, so that the resulting hash digest becomes the new hash key. If the key length of the hash key is less than the block size, zero bytes can be padded to the end of the hash key until the length equals the block size. Subsequently, based on the standardized hash key, a padding value can be generated using a preset XOR constant. Specifically, each byte of the standardized hash key can be XORed with the internal padding constant to obtain the first key padding value, and each byte of the standardized hash key can be XORed with the external padding constant to obtain the second key padding value. After obtaining the first and second key padding values, the first key padding value can be concatenated before the sensitive data to obtain the first concatenated result. Then, a hash function can be used to perform a digest calculation on the first concatenated result, generating a binary inner hash digest. Subsequently, the second key padding value can be concatenated before the inner hash digest to obtain the second concatenated result. This second concatenated result is then again processed using the selected hash function to obtain the final binary digest result. Finally, this binary digest result can be converted into a hexadecimal string, which is the final hash value corresponding to the sensitive data.

[0068] In some embodiments, before hashing the sensitive data, the following processes may also be performed: performing format validity checks on the sensitive data based on preset validation rules; when the sensitive data passes the format validity check, proceeding to the step of hashing the sensitive data; when the sensitive data fails the format validity check, a prompt message indicating that the sensitive data is incorrect may be returned to the client.

[0069] For example, to prevent invalid data (such as incorrect mobile phone numbers, illegal ID card numbers, etc.) from polluting the hash index library and to improve the system's processing efficiency, the following processing can be performed before hashing sensitive data: First, identify the data type of the sensitive data to be processed (such as mobile phone numbers, ID card numbers, bank card numbers, email addresses, etc.), and retrieve the corresponding preset verification rules from the preset rule base according to the identified data type. The preset verification rules may include, but are not limited to, the following combinations: length constraints (i.e., specifying a fixed length or length range of data), character set constraints (i.e., specifying that it only contains numbers, letters, or specific symbols), regular expression patterns (used to match specific string structures), and check bit algorithms (numerical verification logic for specific document numbers, such as the Luhn algorithm for bank card numbers or credit card numbers). Subsequently, sensitive data can be cleaned (e.g., removing leading and trailing spaces, hyphens, etc.) to obtain standard data to be verified. The following verification logic is then executed sequentially: the standard data to be verified is matched against a preset regular expression; if the match fails, the format is deemed invalid. If the data type is an ID card number or bank card number, the check digit at the end of the data is extracted, and the theoretical check digit is recalculated based on the data prefix using a preset algorithm (e.g., the Luhn algorithm). The actual check digit is compared with the theoretical check digit; if they do not match, the format is deemed invalid. If the sensitive data passes all the above verification rules, it is considered valid and can proceed with subsequent hash processing. If the sensitive data fails any verification rule, it is deemed invalid, and the subsequent hash calculation process is blocked, generating an exception response object. This exception response object can include an error status code and descriptive prompts. The server can return this exception response object to the client via an application programming interface (API) to drive the client to render a red warning box in the interactive interface, guiding the target object to re-enter the data.

[0070] In step 103, the root key is obtained from the key management system.

[0071] In some embodiments, the server may first initiate a connection request to the key management system. To prevent man-in-the-middle attacks and spoofing attacks, the server and the key management system can establish an encrypted communication tunnel through a bidirectional transport layer security protocol. The server can present a valid digital certificate to the key management system, which verifies the certificate's validity and revocation status. In addition to the digital certificate, the server can also carry a specific identity identifier and dynamic token in the request header. The key management system can verify whether the server has the permission to read the specified key according to the identity access management policy. After successful authentication, the server can send a request to the key management system to obtain the root key through the encrypted communication tunnel. The version number of the root key can be specified in the request; if not specified, the key management system can return the latest version of the root key by default. This supports a key rotation mechanism, that is, when the old key is leaked or expires, it can smoothly switch to a new version key. After receiving and approving the request, the key management system can retrieve the internally stored root key ciphertext and decrypt it in a hardware security module or secure environment (or read it directly). Subsequently, the key management system can return the root key to the server through the encrypted communication tunnel. To further enhance security, the key management system can also encrypt the root key using a pre-configured public key on the server. Upon receiving the response packet, the server can decrypt it using its locally protected private key to obtain the root key in plaintext.

[0072] In step 104, an encryption key for sensitive data is generated based on the root key, object identifier, and hash value.

[0073] In some embodiments, step 104 can be implemented as follows: obtaining a preset key derivation function (KDF); using the hash value as the salt parameter of the key derivation function and the object identifier as the context information parameter of the key derivation function; inputting the root key, the salt parameter, and the context information parameter into the key derivation function, and using the output of the key derivation function as the encryption key for sensitive data.

[0074] For example, a preset key derivation function can be obtained first, such as an HMAC-based key derivation function or a password-based key derivation function. Then, a pseudo-random function matching the key derivation function can be loaded, such as SHA-256 or SM3 as the underlying hash algorithm. At this point, the key derivation function is initialized to a state ready to receive input parameters. Next, the hash value generated in step 102 can be used as the salt parameter of the key derivation function. Using the data hash as the salt strongly binds the derived key to the data content. This means that even with the same root key, different sensitive data will generate completely different encryption keys, greatly increasing the difficulty of cracking. Next, the object identifier of the target object can be encoded as a binary sequence and used as the context information parameter of the key derivation function. This parameter can be used to implement domain isolation. Even if two pieces of sensitive data have the same content and hash value, if they belong to different objects, the final generated encryption keys will be completely different. This prevents cross-user rainbow table attacks and replay attacks. The root key, along with the salt value and context information parameters, can then be used as input key material and fed into the key derivation function. The function performs the following processing: entropy extraction on the root key using the salt value to obtain a pseudo-random key; then, using the context information parameters, it expands and truncates the pseudo-random key into an output sequence of a specified length. After obtaining the output of the key derivation function, the output can be truncated or padded according to the key length required by a preset encryption algorithm (e.g., including symmetric and asymmetric encryption algorithms). The resulting binary sequence is then used as the encryption key for sensitive data, which is used to encrypt the sensitive data.

[0075] It should be noted that in practical applications, a unique application identifier for the current business scenario can also be obtained. Then, the object identifier can be concatenated with the unique application identifier to obtain a context information parameter with domain isolation attributes. Finally, this context information parameter can be input into the key derivation function to ensure that the generated encryption key is only valid in the current business scenario. In this way, domain isolation at the cryptographic level is achieved. Even if the root key is leaked, the encryption key generated for scenario A cannot decrypt the ciphertext data of scenario B. This is a very strong security feature in a microservice architecture.

[0076] In some embodiments, the business data table may also be configured with a combined unique index for the object identifier and the hash value. Before executing step 104 above, the following processing may also be performed: query the business data table based on the object identifier and the hash value; if there is no data record in the business data table that includes the object identifier and the hash value, proceed to execute step 104 above; if there is a data record in the business data table that includes the object identifier and the hash value, refuse to respond to the data binding request sent by the client, and return a prompt message to the client that the sensitive data has been bound.

[0077] For example, to ensure that the same sensitive data is not repeatedly bound to the same object, and to reduce unnecessary key derivation and encryption operation overhead, this application embodiment can introduce an idempotency check mechanism before generating the encryption key using the key derivation function. Specifically, in the system's business data persistent storage layer (e.g., a relational database MySQL or a distributed database), a composite unique index can be configured for the business data table used to store binding relationships. This composite unique index covers the following two key fields: an object identifier field (used to uniquely identify the data's owner) and a hash value field (used to uniquely identify the content characteristics of sensitive data). Before generating the encryption key using the key derivation function, a query request can be constructed first. For example, a search operation can be initiated on the business data table using the object identifier and the hash value of the sensitive data to be processed as search conditions. When the query results show that no data record containing the object identifier and hash value exists in the business data table (e.g., the query result is empty or the return count is 0), the current request can be determined as the first binding request, the operation can be confirmed as legitimate, and the process can proceed to the step of generating the encryption key. When the query results show that a data record containing the object identifier and hash value already exists in the business data table, the current request can be determined as a duplicate binding request, and subsequent key derivation, data encryption, and data writing operations can be stopped immediately to save server computing and storage resources. Simultaneously, a business-level exception status code can be generated, and a return message can be sent to the client that initiated the request. This message can clearly indicate to the user that the sensitive data has already been bound (e.g., "This ID card has already been bound to the current account; no need to repeat the operation").

[0078] In step 105, the sensitive data is encrypted based on the encryption key to obtain ciphertext data, and the encryption key is destroyed.

[0079] In some embodiments, the above-mentioned encryption of sensitive data based on the encryption key to obtain ciphertext data can be achieved by: randomly generating a fixed-length initialization vector; encrypting the sensitive data using the encryption key and the initialization vector to obtain the encryption payload; obtaining the version identifier of the root key; and concatenating the version identifier, the initialization vector, and the encryption payload to obtain the ciphertext data.

[0080] In other embodiments, following the examples above, the above-described method of encrypting sensitive data using an encryption key and an initialization vector to obtain an encrypted payload can be achieved by: initializing an encryption instance using the encryption key and the initialization vector; converting the sensitive data into ciphertext fragments and generating authentication tags for the sensitive data through the encryption instance; and combining the ciphertext fragments and the authentication tags to obtain the encrypted payload.

[0081] For example, you can first randomly generate a fixed-length initialization vector (IV). (Vitor) Then, the Advanced Encryption Standard (AES-GCM) mode can be used as the encryption algorithm. Using the encryption key and initialization vector, encryption calculations are performed on the sensitive data to obtain the encrypted payload. Specifically, the AES-GCM encryption instance can be initialized first using the encryption key and initialization vector (for example, using the encryption key to perform AES encryption on a 128-bit data block of all zeros, generating a hash subkey for subsequent Galois multiplication authentication; then, an initial counter block is constructed based on the initialization vector, and the encryption key, hash subkey, and initial counter block are loaded into the encryption context to complete the encryption instance initialization). Next, the sensitive data can be converted into ciphertext fragments using the counter mode logic of the encryption instance (for example, the sensitive data can be sequentially divided into several plaintext data blocks according to a 128-bit block size; if the last data block is less than 128 bits, its actual bit length is retained; then, for each plaintext data block, a 32-bit increment operation is performed based on the initial counter block to generate the current counter block, and the encryption key is used to perform AES encryption on the current counter block, outputting the encrypted payload). The process involves generating the corresponding keystream block, performing a bitwise XOR operation between each plaintext data block and the corresponding keystream block to obtain the corresponding ciphertext block, and concatenating all generated ciphertext blocks to form a ciphertext fragment. It also involves generating an authentication tag for sensitive data using the Galois field multiplication logic of the encryption instance. For example, additional authentication data can be concatenated with the ciphertext fragment in sequence, with zero-padding for blocks shorter than 128 bits, and finally appending a 64-bit length field containing the length of the additional authentication data and the ciphertext length to form a complete data stream to be authenticated. Then... The system initializes an authentication variable with all zeros. For each 128-bit data block in the data stream to be authenticated, the following operations are performed sequentially: The current data block is XORed with the authentication variable; the XOR result is then multiplied by the hash subkey in the Galois field, and the authentication variable is updated. Finally, the initial counter block is encrypted using the encryption key to generate a mask block, and the final output authentication variable is XORed with the mask block to obtain the final authentication tag. The ciphertext fragment and the authentication tag are then combined to obtain the encrypted payload. Finally, the version identifier of the root key is obtained, and the version identifier, initialization vector, and encrypted payload are concatenated according to a preset format to obtain the final ciphertext data. Thus, even if two users have the same sensitive data (e.g., bank card number), the encrypted ciphertext data will be completely different because the initialization vector is randomly generated. This solves the security vulnerability of traditional encryption schemes where the same plaintext corresponds to the same ciphertext.

[0082] In some embodiments, within the atomic operation cycle after obtaining the encrypted data, the encryption key stored in memory can be immediately destroyed. It should be noted that in modern operating systems, ordinary variable release does not immediately erase physical memory; data may remain in Random Access Memory (RAM) and be obtained through memory dump attacks, or be swapped to the hard drive by the operating system. Therefore, this embodiment can allocate a locked memory region in volatile memory and prevent the operating system from swapping data in the memory region to non-volatile storage media. Then, the encryption key can be written to the locked memory region, and after encryption, the locked memory region is immediately overwritten using all-zero data or pseudo-random numbers, and the memory region is released. This elevates logical security to the level of physical memory security, overcoming the shortcomings of general-purpose programming language memory management for high-level financial security scenarios. In other words, this embodiment immediately destroys the encryption key in memory after completing the encryption operation; it does not persistently store the encryption key, meaning it does not store the encryption key in the business data table.

[0083] In step 106, a data record including object identifier, hash value and ciphertext data is constructed and stored in a pre-created business data table.

[0084] In some embodiments, the above-described construction of a data record including an object identifier, a hash value, and ciphertext data can be achieved by: generating a structured record containing a metadata area and a data entity area according to a predefined storage protocol; writing the object identifier and hash value into the metadata area and writing the ciphertext data into the data entity area; and establishing a logical association between the metadata area and the data entity area to form a logically complete data record.

[0085] For example, to improve query efficiency and standardize storage format, embodiments of this application can assemble the discrete data (such as object identifiers, hash values, encrypted data, etc.) generated in the preceding steps into a standardized record that can be persistently stored, according to preset data governance specifications. Specifically, the data container format can be defined first, and the division criteria between the metadata area and the data entity area can be clarified. For example, the server can initialize a new data record container according to a predefined storage protocol. This protocol defines the binary layout of the data record, specifically including two functionally independent areas: the metadata area (configured to store plaintext or searchable information for data indexing, routing, and verification; in the underlying storage implementation, this area is usually mapped to the index column of a database table or a fixed-length field in the file header); and the data entity area (configured to store encrypted payload data; in the underlying storage implementation, this area is usually mapped to a large object field or a variable-length data segment in the database). Subsequently, the object identifier and the hash value of sensitive data can be written to the metadata area of ​​the data record. For example, the object identifier can be directly written in plaintext in the metadata area as a first-level index key for quickly locating the data owner, and the hash value can be written as a second-level index key or deduplication key. Of course, version identifiers (such as version numbers), encryption algorithm identifiers, and timestamps of the root key can also be written into the metadata area. This information does not involve data privacy but is crucial for subsequent decryption and maintenance. Furthermore, the ciphertext data generated in step 105 can be written into the data entity area of ​​the data record. This area stores completely opaque binary data, and the server can strictly limit index creation in this area, i.e., not creating a full-text index on the ciphertext data, to reduce storage overhead and prevent index-based side-channel attacks. Finally, a preset association mechanism can be used to bind the filled metadata area to the data entity area, forming a logically complete data record. For example, for relational database tables, the database's primary key or physical address can be used to enforce an atomic correspondence between the object identifier column, hash value column (i.e., metadata area), and ciphertext data column (i.e., data entity area) within the same row. Thus, by storing hash values ​​in the metadata area, the server can quickly determine the existence of sensitive data or perform precise searches simply by scanning the metadata area without decrypting the data entity area (i.e., ciphertext data). This greatly improves query performance while maintaining data confidentiality. Furthermore, the metadata area typically stores fixed-length, frequently accessed data, suitable for building high-performance indexes, while the data entity area stores variable-length, infrequently accessed encrypted data. This division helps the database engine optimize read and write strategies. Additionally, when a round-robin key is needed, only the key version number in the metadata area and the encrypted data in the data entity area need to be read, decrypted, re-encrypted, and the data entity area updated. This eliminates the need to modify the object identifier and hash value in the metadata area, reducing maintenance complexity.

[0086] In other embodiments, the above-described construction of a data record including an object identifier, a hash value, and ciphertext data can also be achieved by: obtaining the organization code of the institution associated with the sensitive data (e.g., the bank code of the issuing bank of a credit card), and extracting the last character fragment of the sensitive data (e.g., the last four digits of the credit card number); combining the organization code and the last character fragment into plaintext index data; and constructing a composite data record including an object identifier, plaintext index data, a hash value, and ciphertext data.

[0087] For example, the server can first identify the business type and format specifications of the sensitive data to be processed, and based on the identified format specifications, perform the following processing: extract the prefix field of the sensitive data; based on this prefix field, query a pre-set organization mapping table to obtain the corresponding organization code or organization name; then, perform string truncation on the sensitive data to extract the last character fragment used for user-aided identification, such as extracting the last four characters of the sensitive data as the last digit identifier. Subsequently, the extracted organization code and the last character fragment can be combined (for example, they can be connected using a specific delimiter, or they can be stored as independent subfields in the plaintext index structure for flexible subsequent retrieval) to generate plaintext index data. It should be noted that this plaintext index data is low-sensitivity information after de-identification and is allowed to be directly used for list display on the front-end page without decryption. Finally, the server can construct a composite data record containing multiple functional fields according to a preset data pattern. This record maps the various types of data generated above to the corresponding storage fields, such as: an object identifier field (writing the unique identifier of the data's owner, used to establish data ownership), a plaintext index field (writing the plaintext index data generated above; this field is usually set to be visible or only weakly encrypted, used for a quick list display of business query results), a hash verification field (writing the hash value calculated in the preceding steps; this field is used for precise lookup and uniqueness verification, and is usually indexed to accelerate retrieval), and a ciphertext storage field (writing the encrypted ciphertext data; this field stores core confidential information and is not visible to upper-layer business except for necessary decryption processes). Thus, in high-frequency business scenarios such as "My Bank Card List" or "Payment Method Selection," the server only needs to read the plaintext index data to directly display it to the user (e.g., "XX Bank's last four digits 1234"), which completely avoids the decryption operation of the ciphertext data, greatly reducing CPU computation overhead and key access frequency, and significantly shortening interface response time. Furthermore, by separating the institution code, aggregate query requirements such as "query all XX bank cards bound to the current user" or "statistics on the number of cards bound to each issuing bank" can be easily supported without decryption, enriching the data usage scenarios.

[0088] In some embodiments, before storing data records in a pre-created business data table (e.g., a card binding table), the following processes may also be performed: querying the pre-created business data table based on the hash value; storing the data record in the business data table if there is no data record in the business data table that includes the hash value; and refusing to store the data record in the business data table if there is already a data record in the business data table that includes the hash value, and returning a prompt message to the client indicating that sensitive data has been bound.

[0089] For example, to prevent duplicate bindings or redundant storage, before formally writing the constructed data records into the business data table, a query request can be initiated against the pre-created business data table using the hash value generated in the previous steps as the retrieval key. This query process utilizes the unique or regular index created by the database on the "hash value field," resulting in extremely fast retrieval speed, without involving a full table scan or any encryption operations. If the query result indicates that no data record containing the hash value exists in the business data table (i.e., the query result is empty or the count is 0), then the current operation can be determined as a new data entry request, and a database insert operation can be performed to write the previously constructed data record into the business data table. This insert operation is protected by database transactions, ensuring the integrity of the data write. If the query results indicate that a record containing the hash value already exists in the business data table, the current operation can be determined to be a duplicate data entry or a conflict request. The current write process can then be immediately terminated, refusing to store the constructed data record in the business data table to avoid data redundancy or violations of business rules (e.g., "a card number can only be bound once"). Simultaneously, a response message containing error codes and prompts can be generated, returning messages such as "This bank card has already been bound; please do not repeat the operation" or "Sensitive data already exists" to the requesting client. Thus, by directly comparing hash values, which are fixed-length and deterministic, database query efficiency is exponentially improved, significantly reducing database read / write and CPU decryption load. Furthermore, mandatory verification before storage ensures the uniqueness of sensitive data in the database from the source, preventing the generation of dirty data due to user errors or system retry mechanisms, and ensuring the rigor of business logic.

[0090] In some embodiments, see Figure 4 , Figure 4 This is a schematic diagram of the second process of the data processing method provided in the embodiments of this application, as shown below. Figure 4 As shown, after execution Figure 3 After step 106 shown, you can also execute... Figure 4 Steps 107 to 111 shown will combine Figure 4 The steps shown are explained.

[0091] In step 107, a data query request sent by the client is received.

[0092] Here, data query requests can carry the object identifier of the target object, as well as ciphertext data obtained by encrypting sensitive data.

[0093] In some embodiments, after data records are persistently stored in a business data table, the server can expose a data query interface to support the business verification process. For example, it can listen for data query requests from clients through a pre-defined application programming interface or gateway service. This data query request can be sent via an encrypted transmission protocol to ensure data security during transmission. Upon receiving a data query request, the server can parse the data packet body to extract two core parameters: the object identifier of the target object (this identifier is used to limit the query scope; for example, the server can only search within the data set under this identifier, rather than scanning the entire database, thereby improving query efficiency and isolating data from different users), and ciphertext data obtained by encrypting sensitive data. In other words, the client sends ciphertext data instead of plaintext sensitive data when sending the request. This means that even if an attacker intercepts the network request data packet, they cannot directly obtain the user's sensitive information (such as bank card numbers), which complies with data transmission security standards.

[0094] In step 108, the business data table is queried based on the object identifier and the encrypted data to obtain data records including the object identifier and the encrypted data, and the hash value is extracted from the queried data records.

[0095] In some embodiments, after parsing the object identifier and encrypted data of the target object from the received data query request, the server can construct and execute a database query instruction. For example, it can use the object identifier and hash value as a joint query condition to search whether there is a data record in the business data table that includes both the object identifier and the hash value. If it exists, the content of the hash value field can be extracted from the field set of the data record obtained by the query.

[0096] In step 109, the root key is obtained from the key management system, and a decryption key is generated based on the root key, hash value, and object identifier.

[0097] In some embodiments, the ciphertext data may include a version identifier (e.g., a version number) of the root key used during encryption. The root key can then be obtained from the key management system as follows: the ciphertext data is parsed to obtain the version identifier of the root key used during encryption; the root key corresponding to the parsed version identifier is obtained from the key management system.

[0098] For example, after extracting the hash value from the retrieved data records, the ciphertext data can first be parsed to obtain the version identifier (e.g., version number) of the root key used in the encryption process. Then, the root key corresponding to that version number can be obtained from the key management system. Subsequently, the obtained root key, the extracted hash value, and the parsed object identifier can be input into a key derivation function to generate a decryption key for the ciphertext data. It should be noted that for symmetric encryption algorithms, the encryption and decryption keys are the same; for asymmetric encryption algorithms, the encryption and decryption keys are different.

[0099] In step 110, the encrypted data is decrypted using the decryption key to obtain the sensitive data, and the decryption key is destroyed.

[0100] In some embodiments, after generating the decryption key, the server can invoke a pre-built symmetric decryption algorithm component. This algorithm operates in the same mode as the encryption configuration used when the data was stored. Furthermore, the ciphertext data to be decrypted typically consists of two parts: an initialization vector and the ciphertext body. The server can first parse the field structure, separating the random initialization vector stored in the header, and use it as one of the input parameters for the decryption operation. Then, the decryption key generated in the previous step, the extracted initialization vector, and the ciphertext body can be input into the decryption engine. The engine performs reverse cryptographic operations and outputs the original byte stream containing padding data. Since block encryption algorithms typically require data length alignment, the decrypted data may contain padding characters in formats such as PKCS#7 at the end. The server can identify and remove these padding characters to accurately restore the original plaintext of sensitive data (e.g., complete bank card numbers, ID card numbers, etc.). Immediately after decryption is complete and sensitive data is successfully obtained (i.e., before passing plaintext data to the next business logic), the server can forcibly execute a key destruction procedure. For example, after dereferencing variables or waiting for garbage collection, the server can explicitly locate the memory address storing the "decryption key" and repeatedly overwrite that memory address using all-zero sequences, all-one sequences, or pseudo-random numbers. After the underlying memory overwrite is complete, the corresponding variable reference at the application layer can be set to null to prevent the key from being recovered through memory dumps or pointer remnants. Thus, by adopting a "use and destroy" strategy, the decryption key exists in memory for only microseconds or milliseconds during the CPU's execution of the decryption instruction. Even if an attacker obtains a memory snapshot of the server or reads the stack information through a vulnerability, they cannot obtain a valid decryption key and therefore cannot decrypt other ciphertext in the database.

[0101] In other embodiments, after decrypting the ciphertext data using the decryption key to obtain the sensitive data, the following processing can be performed: obtaining the version identifier of the latest root key from the key management system; when the version identifier parsed from the ciphertext data is earlier than the version identifier of the latest root key, generating a new encryption key based on the latest root key, hash value, and object identifier; encrypting the sensitive data using the new encryption key to obtain new ciphertext data; constructing a new data record including the new ciphertext data, hash value, and object identifier, and replacing the original data record stored in the business data table with the new data record.

[0102] For example, after decrypting the ciphertext data using the decryption key, the server can query the key management system or read the configuration from the local cache to obtain the version number of the latest active root key. Then, it can compare the latest root key version number with the version number extracted from the ciphertext data. If the latest root key version number matches, the plaintext data is returned directly to the client without a write operation. If the latest root key version number is greater than the version number extracted from the ciphertext data, the latest root key can be requested from the key management system and loaded into secure memory. Then, the latest root key, object identifier (unchanged), and hash value (unchanged because the plaintext remains unchanged) can be input into the key derivation function to generate a new encryption key. Afterward, the new encryption key can be used to encrypt sensitive data to obtain new ciphertext data. Subsequently, a new data record including the new ciphertext data, hash value, and object identifier can be constructed, and the old data record in the business data table can be replaced with the new data record. After the update is complete, the new encryption key in memory can be immediately destroyed to ensure data security. In this way, the static storage solution is upgraded to a dynamic self-maintaining system, which solves the technical problem of "service unavailability caused by key rotation under massive data" and significantly improves the availability and operation and maintenance efficiency of the system.

[0103] In step 111, sensitive data is returned to the client.

[0104] In some embodiments, after decrypting the encrypted data using the decryption key to obtain the sensitive data, the sensitive data (e.g., the complete bank card number) can be directly returned to the client. Alternatively, the institution code of the institution managing the sensitive data can be obtained, and the last character fragment of the sensitive data can be extracted. The institution code (e.g., the bank code of the issuing bank) and the last character fragment (e.g., the last four digits of the bank card number) can be returned to the client. This application embodiment does not specifically limit this.

[0105] The following example, using a user's credit card number as the sensitive data, illustrates an exemplary application of this application in a real-world scenario.

[0106] In the context of encrypted credit card number storage, traditional globally unified key schemes suffer from risks of batch data leakage due to key leaks, while traditional single-card-single-key schemes require storing independent keys for each card, resulting in high storage costs and complex key management. This application addresses these issues by employing a card index generation mechanism based on the SM3 hash algorithm, combined with an OAuth2 user-table-less architecture and key derivation functions, to construct a lightweight storage solution with zero key tables and zero user tables. This achieves a balance between secure isolation for a single card and single key and zero storage cost. In other words, this application integrates OAuth2 authentication with a third-party open platform's login system, utilizes an SM3 hash algorithm-based card index generation mechanism, and employs key derivation functions to achieve zero storage for a single card and single key, constructing a lightweight single-table storage architecture. This provides an integrated solution for user authentication, card number security encryption, and data storage management. Specifically: (1) User credit card storage architecture based on OAuth2-free user table, card number hash and encrypted ciphertext In this embodiment, users can authorize login on a third-party open platform via the OAuth2 protocol. The server can directly obtain the user's openid (i.e., a unique identifier generated by the third-party open platform for the user) as the user's unique identifier. Then, the plaintext card number (card_id) can be hashed using SM3 national cryptographic hashing to generate a fixed 64-bit hexadecimal string as the card index identifier (card_idx). The one-way irreversible property of the hash function is used to protect the privacy of the plaintext card number. In addition, this embodiment can maintain only a single card binding table (user_cards) to store the triple (including user identifier, card index identifier, and encrypted card number) and auxiliary fields such as bank code and card type. The database unique index (including user identifier and card index identifier) ​​is used to achieve anti-duplicate card binding detection. There is no need to maintain a separate user information table and key storage table, thereby decoupling user identity authentication and business data storage, reducing the risk of user privacy data leakage, and significantly reducing database storage costs and operational complexity.

[0107] (2) Single-card single-key zero-storage scheme based on key derivation function This application embodiment can employ an HMAC-based key derivation function (e.g., HKDF) to dynamically calculate and generate an independent encryption key for each card, using the root key stored in the KMS, the card index identifier in the card binding table, and the user identifier as input parameters. The key is derived in real-time during encryption and decryption and immediately destroyed from memory after use, eliminating the need to store any card keys in a database. The card index identifier, as the input parameter for key derivation, ensures that each card derives an independent encryption key, achieving secure isolation of a single card and a single key, and zero-key storage, reducing key management complexity and leakage risks. Furthermore, when encrypting the card number, the root key version number can be embedded as a prefix into the ciphertext string (e.g., "v1:{ciphertext}"). During decryption, the corresponding version of the root key is automatically identified by parsing the prefix, supporting automatic compatibility decryption of historical data during smooth root key rotation.

[0108] In other words, the technical solution provided in this application addresses the following problems: 1. Implement single-card, single-key isolation to prevent batch data leakage caused by cracking a single key. This application embodiment uses key derivation function technology to dynamically generate an independent encryption key for each card with the root key, card index identifier, and user identifier as input parameters. This ensures that different credit cards of different users use completely independent encryption keys. Even if a single encryption key is cracked, it will only affect that single card, avoiding the risk of batch data leakage caused by global key leakage. This meets the requirements of financial security standards for graded protection of sensitive data.

[0109] 2. Construct a zero-storage-cost architecture with a single card and a single key to reduce the complexity of key management. This application employs a real-time key derivation mechanism, dynamically generating keys (including encryption and decryption keys, which can be the same) during encryption and decryption. These keys are immediately destroyed from memory after use, eliminating the need to store any keys or encrypted keys in a database. This completely eliminates the key storage table and the associated storage costs, backup synchronization, access control, and other management complexities, reducing the risk of key leakage. Furthermore, a root key version number, such as "v1:{ciphertext}", can be added to the ciphertext, supporting smooth root key rotation without re-encrypting historical data.

[0110] 3. Provide an integrated user credit card binding management solution based on OAuth2. This application embodiment utilizes the OAuth2 protocol to obtain the identifier assigned to the user by a third-party open platform as a unique user identifier. Then, it calculates and generates a card index identifier (i.e., a hash value obtained by hashing the credit card number) using the SM3 hash algorithm. Only a single card binding table (i.e., user_cards) is maintained, storing necessary fields such as the user identifier, card index identifier, and encrypted card number. Anti-duplicate card binding detection is achieved through a unique index in the database. This integrates user identity authentication, encrypted card number storage, key derivation, and anti-duplicate detection functions into a unified technical solution, greatly simplifying the system architecture, reducing development and maintenance costs, and reducing the risk of user privacy data storage and leakage.

[0111] The data processing method provided in the embodiments of this application will be described in detail below.

[0112] In some embodiments, see Figure 5 , Figure 5 This is a schematic diagram illustrating an application scenario of the data processing method provided in the embodiments of this application, such as... Figure 5As shown, the technical solution provided in this application can be applied to bank card management scenarios in instant messaging clients. For example, users can complete card binding, card query, and card unbinding operations in real time within a mini-program running on the instant messaging client. After authorizing login through the instant messaging client, users can directly perform bank card binding operations without registering an account or filling in personal information. The server can automatically complete functions such as encrypted storage of card numbers and detection of duplicate card binding, ensuring the secure storage and convenient management of user bank card information. Specifically, when it is detected that a user has opened a specific mini-program in the instant messaging client, the instant messaging client can automatically call wx.login() to obtain a temporary login credential. Then, the backend service can call the application programming interface provided by the third-party open platform, use the temporary login credential to exchange for an identifier (such as openid) assigned to the user by the third-party open platform, and use this identifier as the user's unique identifier, thus eliminating the need to create an independent user account. Subsequently, the user can directly enter the main interface of the mini-program without manually clicking the authorization or login button. The user can enter the card number (16-19 digits) of the credit card they want to bind in the mini-program interface and select the issuing bank (such as "XX Bank"). After entering their card number and selecting their issuing bank, users can click the "Confirm Binding" button on the interface. Upon receiving this click, the server first verifies the card number's format (e.g., using the Luhn algorithm to validate its validity). Upon receiving the binding request, the server performs the following steps: First, it performs an SM3 hash on the plaintext card number to generate a 64-bit hexadecimal string, which serves as the card index identifier. Next, it queries the database using the user identifier and card index identifier as a combined index to check if the card is already bound. If not, it retrieves the root key from the key management system, executes a key derivation function to generate a unique encryption key for the card, and then uses this key to encrypt the card number using the AES-GCM algorithm. Finally, it inserts the user identifier, card index identifier, encrypted card number (including the root key's version number, e.g., "v1:{encrypted card number}"), and bank code into the binding table. Simultaneously, it displays a "Binding Successful" message on the front end and shows the newly bound credit card in the card list (e.g., displaying the last four digits of the card number and the bank's logo). Of course, users can also query the card list. For example, when a user enters the homepage, the server can query the card binding table based on the user's identifier and return all the credit card information bound to the user (excluding the complete plaintext card number). The front end can display the card list, and each credit card can display the following: bank logo, the last 4 digits of the card number (e.g., "**** **** **** 1234"), and the bank name.In addition, users can also unbind a credit card by clicking the "Unbind" button on the card list page. For example, when a user clicks the "Unbind" button on a credit card, a prompt message can pop up asking the user to confirm whether to unbind it. After the user confirms, the server can delete the corresponding record in the card binding table based on the user identifier and card index identifier. At the same time, the front end can return to the card list page and display a "Unbinding successful" message. At this point, the credit card has been removed from the card list.

[0113] The following will continue to combine Figure 6 The data processing method provided in the embodiments of this application will be described.

[0114] In some embodiments, see Figure 6 , Figure 6 This is a schematic diagram of the architecture of the data processing system provided in the embodiments of this application, such as... Figure 6 As shown, the data processing system provided in this application mainly consists of three parts: a social platform ecosystem layer, a backend service layer, and an infrastructure layer. The social platform ecosystem layer primarily includes mini-programs running in instant messaging clients and third-party open platforms. The mini-programs serve as the user interaction front-end, providing interfaces for credit card binding, querying, and unbinding, and automatically calling the instant messaging client's login interface to obtain user authorization. The third-party open platforms primarily provide OAuth2 authorization services, obtaining an openid through temporary login credentials, which is returned to the backend service as the user's unique identifier. The backend service layer mainly includes a card binding management service and a card number encryption / decryption module. The card binding management service primarily handles business logic such as credit card binding, querying, and unbinding, and is responsible for calling the card number encryption / decryption module to complete card number encryption storage and decryption query. It can also interact with a MySQL database to complete data persistence operations. The card number encryption / decryption module primarily executes the SM3 hash function to calculate and generate a card number index identifier, obtains the root key from the key management system, calls the key derivation function to generate an independent encryption key, performs AES-GCM encryption / decryption operations, embeds / parses the version number in the ciphertext, and immediately destroys the derived key in memory after encryption / decryption. The infrastructure layer mainly includes a key management system and a MySQL database. The key management system is primarily used for securely storing and managing the root key (supporting multiple versions of the root key, such as v1, v2, etc.), providing a key acquisition interface, and ensuring that the root key is not leaked. This application embodiment can directly reuse existing mature KMS components; any service that meets the requirements of key escrow and basic encryption algorithm implementation can be adopted. The MySQL database is used to maintain the card binding table, storing fields such as user identifier, card index identifier, encrypted card number (i.e., ciphertext card number), and bank code. A composite index composed of the user identifier and card index identifier is used to implement anti-duplicate card binding detection.

[0115] The following will continue to combine Figure 7 The process of binding the card is explained in detail.

[0116] In some embodiments, see Figure 7 , Figure 7 This is a schematic diagram of the third process of the data processing method provided in the embodiments of this application, which will be combined with Figure 7 The steps shown are explained.

[0117] In step 201, the user opens the mini-program.

[0118] In some embodiments, users can open the mini-program list by pulling down in the instant messaging client. The mini-program list can display multiple entry points for each mini-program, and users can open the corresponding bank mini-program by clicking the entry point of the bank mini-program.

[0119] In step 202, the mini-program sends a code acquisition request to the third-party open platform.

[0120] In some embodiments, when a user opens a bank mini-program in an instant messaging client, the bank mini-program can send a temporary login credential (i.e., code) acquisition request to a third-party open platform.

[0121] In step 203, the third-party open platform returns a code to the mini-program.

[0122] In some embodiments, after receiving a request from a mini-program to obtain a temporary login credential, the third-party open platform can first verify the mini-program, and then return a temporary login credential to the mini-program after the verification is successful.

[0123] In step 204, the mini-program sends a code to the card binding management service.

[0124] In some embodiments, after receiving a temporary login credential from a third-party open platform, the mini-program can send the received temporary login credential to the card binding management service.

[0125] In step 205, the binding management service sends a request to the third-party open platform to exchange a code for an openid.

[0126] In some embodiments, after receiving a temporary login credential from the mini-program, the card binding management service may send a request to a third-party open platform to exchange the temporary login credential for a user identifier (e.g., openid) assigned to the user by the third-party open platform.

[0127] In step 206, the third-party open platform returns the openid to the card binding management service.

[0128] In some embodiments, after receiving a request from the card binding management service, the third-party open platform can first verify the temporary login credentials carried in the request, and after the verification is successful, return the openid to the card binding management service.

[0129] In step 207, the card binding management service sends a login success notification message to the mini-program.

[0130] In some embodiments, after receiving the openid returned by the third-party open platform, the card binding management service can return a login success notification message to the mini-program.

[0131] In step 208, the user enters the card number and selects the issuing bank in the mini-program.

[0132] In some embodiments, users can enter the card number of the credit card they want to bind in the mini-program interface and select the issuing bank of the credit card.

[0133] In step 209, the user clicks the "Confirm Binding" button in the mini-program.

[0134] In some embodiments, after entering the credit card number and selecting the issuing bank in the mini-program interface, the user can click the "Confirm Binding" button displayed in the mini-program interface.

[0135] In step 210, the mini-program sends a card binding request to the card binding management service.

[0136] In some embodiments, when the mini-program receives a user's click on the "Confirm Binding" button, it can send a card binding request to the card binding management service.

[0137] In step 211, the card binding management service sends a card number encryption request to the card number encryption / decryption module.

[0138] In some embodiments, after receiving a card binding request from the mini-program, the card binding management service can send a card number encryption request to the card number encryption / decryption module.

[0139] In step 212, the card number encryption / decryption module uses the SM3 hash function to calculate the card index identifier.

[0140] In some embodiments, after receiving a card number encryption request sent by the card binding management service, the card number encryption / decryption module can use the SM hash function to hash the card number, generate a 64-bit hexadecimal string, and use this string as the card index identifier.

[0141] In step 213, the card number encryption / decryption module sends a query request to the MySQL database.

[0142] In some embodiments, after obtaining the card index identifier, the card number encryption / decryption module can send a query request to the MySQL database using the user identifier and the card index identifier as a combined index.

[0143] In step 214, the MySQL database returns the query results to the card number encryption / decryption module.

[0144] In some embodiments, after receiving a query request from the card number encryption / decryption module, the MySQL database can query whether the credit card has been bound and return the query result to the card number encryption / decryption module.

[0145] In step 215, when the card already exists, the card number encryption / decryption module returns an error message indicating that the card is already bound to the card binding management service.

[0146] In some embodiments, when the query result indicates that the card already exists, the card number encryption / decryption module can return an error message indicating that the card is already bound to the card binding management service.

[0147] In step 216, the card binding management service sends a notification message to the mini-program indicating that the card binding failed.

[0148] In some embodiments, after receiving an error message from the card number encryption / decryption module indicating that the card has been bound, the card binding management service can return a notification message indicating that the card binding failed to the mini-program.

[0149] In step 217, the mini-program displays a message to the user stating "This card has been bound".

[0150] In some embodiments, after receiving a notification message from the card binding management service indicating a card binding failure, the mini-program can display a message to the user stating "The card has been bound".

[0151] In step 218, when the card is not present, the card number encryption / decryption module sends a root key retrieval request to the key management system.

[0152] In some embodiments, see Figure 8 , Figure 8 This is a schematic diagram of the first process of the data processing method provided in the embodiments of this application, as shown below. Figure 8 As shown, when the query result indicates that the card does not exist (i.e., the first binding), the card number encryption / decryption module can send a root key acquisition request for the current version to the key management system.

[0153] In step 219, the key management system returns the root key to the card number encryption / decryption module.

[0154] In some embodiments, after receiving a root key retrieval request from the card number encryption / decryption module, the key management system can return the current version of the root key to the card number encryption / decryption module.

[0155] In step 220, the card number encryption / decryption module uses a key derivation function to generate an encryption key.

[0156] In some embodiments, after receiving the root key returned by the key management system, the card number encryption / decryption module can input the received root key, user identifier, and card index identifier into the key derivation function to dynamically generate an independent encryption key for the card.

[0157] In step 221, the card number encryption / decryption module encrypts the card number using an encryption key.

[0158] In some embodiments, after obtaining the encryption key, the card number encryption / decryption module can use the encryption key and the AES-256-CGM algorithm to encrypt the plaintext card number to obtain the ciphertext card number.

[0159] In step 222, the card number encryption / decryption module concatenates the version number into the ciphertext card number.

[0160] In some embodiments, after generating the ciphertext card number, the card number encryption / decryption module can prepend the root key version number to the ciphertext card number, in the format "v{version number}:{ciphertext}", for example "v1:A8f3kL9mX".

[0161] In step 223, the card number encryption / decryption module destroys the encryption key in memory.

[0162] In some embodiments, after encryption is completed, the card number encryption / decryption module can immediately destroy the derived encryption key from memory.

[0163] In step 224, the card number encryption / decryption module returns the encrypted card number to the card binding management service.

[0164] In some embodiments, after obtaining the encrypted card number, the card number encryption / decryption module can return the encrypted card number to the card binding management service.

[0165] In step 225, the card binding management service sends an insert request to the MySQL database.

[0166] In some embodiments, after receiving the encrypted card number returned by the card number encryption / decryption module, the card binding management service can send an insert request to the MySQL database. The insert request may carry the user identifier, card index identifier, and encrypted card number.

[0167] In step 226, the MySQL database returns a notification message to the card binding management service indicating successful insertion.

[0168] In some embodiments, after receiving an insert request from the card binding management service, the MySQL database can generate a corresponding data record (including fields such as user identifier, card index identifier, encrypted card number, and bank code) and return a notification message of successful insertion to the card binding management service.

[0169] In step 227, the card binding management service sends a notification message to the mini-program that the card binding was successful.

[0170] In some embodiments, after receiving a notification message from the MySQL database indicating successful insertion, the card binding management service can return a notification message indicating successful card binding to the mini-program.

[0171] In step 228, the mini-program displays a "Binding successful" message to the user and refreshes the card list.

[0172] In some embodiments, after receiving a notification message from the card binding management service indicating successful card binding, the mini-program can display a "Binding successful" message on the interface and refresh the card list, for example, displaying the user's currently bound credit card in the refreshed card list.

[0173] The following will continue to combine Figure 9 The decryption process will be explained.

[0174] In some embodiments, see Figure 9 , Figure 9 This is a schematic diagram of the second process of the data processing method provided in the embodiments of this application, as shown below. Figure 9 As shown, when a decryption request is received, the card number encryption / decryption module first parses the request to obtain the user identifier and ciphertext card number carried in the request. Then, it queries the card binding table based on the user identifier and ciphertext card number to obtain the corresponding card index identifier. Next, it parses the ciphertext card number to extract the version number and ciphertext portion, and retrieves the root key (e.g., the root key for version v1) corresponding to the parsed version number from the key management system. Subsequently, it calls the key derivation function, inputting the root key, card index identifier, and user identifier, to dynamically generate an independent decryption key for the card (the same as the encryption key generated during encryption). Finally, it uses the derived decryption key and the AES-256-GCM algorithm to decrypt the ciphertext and obtain the plaintext card number. After decryption, the derived decryption key is immediately destroyed from memory, and the plaintext card number is returned to the card binding management service.

[0175] It should be noted that the embodiments of this application can employ industry-standard encryption and decryption algorithms. For example, the national cryptographic SM3 hash algorithm can be used to perform a one-way irreversible operation on the plaintext card number, generating a fixed-length 64-bit hexadecimal string as the card index identifier. For instance, the SM3 hash algorithm can output a 256-bit (32-byte) hash value, and convert the obtained hash value into a 64-bit hexadecimal string to ensure that the same card number always generates the same card index identifier (i.e., determinism); different card numbers generate different card index identifiers (i.e., collision resistance); and the plaintext card number cannot be deduced from the card index identifier (i.e., one-wayness). In addition, the embodiments of this application can employ an HMAC-based key derivation function (i.e., HKDF), which takes the root key, user identifier, and card index identifier as input and outputs a 256-bit AES encryption key (i.e., a key unique to each card). Specifically, after obtaining the root key from the key management system, the card index identifier can be used as a salt parameter, the user identifier as a context information parameter, and input together with the root key into the HKDF so that the HKDF outputs a 256-bit (32-byte) encryption key. The HKDF algorithm needs to ensure that: the same combination of parameters (e.g., including the root key, user identifier, and card index identifier) ​​always generates the same encryption key (i.e., reproducibility); different card index identifiers or user identifiers generate completely different encryption keys (i.e., key isolation); and the derived encryption key has the same cryptographic strength as the root key (i.e., security). Furthermore, in this embodiment, when encrypting plaintext card numbers using the derived encryption key, the AES-256-GCM algorithm (a symmetric encryption scheme combining AES encryption and GCM mode, which uses a 256-bit key to encrypt data through complex mathematical transformations and provides data integrity and authentication functions by creating MAC tags) can be used to provide confidentiality and integrity protection. The AES-GCM mode ensures that: the ciphertext cannot be cracked without the known key (i.e., confidentiality); decryption fails when the ciphertext is tampered with (i.e., integrity verification); and different random initialization vectors are used each time encryption is performed, so the same plaintext can generate different ciphertexts (i.e., preventing replay attacks).

[0176] Furthermore, it should be noted that after encryption, this embodiment of the application can also append the version number of the root key as a prefix to the ciphertext string. In this way, during decryption, the prefix can be parsed to identify the version number, and the root key corresponding to the parsed version number can be obtained from the key management system (for example, assuming the parsed version number is v1, the root key of version v1 can be obtained from the key management system). This mechanism can achieve smooth rotation of the root key. For example, a newly bound card can use a new version of the root key (e.g., the root key of version v2), while historical data can retain the original version number (e.g., v1). During decryption, the correct version of the root key is automatically selected, without the need to re-encrypt historical data.

[0177] The following will continue to combine Figure 10 This section explains the process of authorizing login based on the OAuth2 protocol.

[0178] In some embodiments, see Figure 10 , Figure 10 This is a schematic diagram of the fourth process of the data processing method provided in the embodiments of this application, which will be combined with Figure 10 The steps shown are explained.

[0179] In step 301, the user opens the mini-program.

[0180] In some embodiments, users can open the mini-program list by pulling down in the instant messaging client. The mini-program list can display multiple entry points for each mini-program, and users can open the corresponding bank mini-program by clicking the entry point of the bank mini-program.

[0181] In step 302, the mini-program sends a code acquisition request to the third-party open platform.

[0182] In some embodiments, after a user opens a mini-program in an instant messaging client, the mini-program can call wx.login() to obtain a temporary login credential (i.e., code) from a third-party open platform.

[0183] In step 303, the third-party open platform returns a code to the mini-program.

[0184] In some embodiments, after receiving a code retrieval request from a mini-program, a third-party open platform can first verify the mini-program and, after successful verification, return a temporary login credential to the mini-program.

[0185] In step 304, the mini-program sends a login request to the card binding management service.

[0186] In some embodiments, after receiving a temporary login credential returned by a third-party open platform, the mini-program can send a login request carrying the temporary login credential to the card binding management service.

[0187] In step 305, the card binding management service sends a request to the third-party open platform to exchange the code for the openid.

[0188] In some embodiments, after receiving a login request from a mini-program, the card binding management service can first extract a temporary login credential from the login request, and then send a request to a third-party open platform to exchange the temporary login credential for an openid.

[0189] In step 306, the third-party open platform returns the openid to the card binding management service.

[0190] In some embodiments, after receiving a request from the card binding management service, the third-party open platform can first verify the temporary login credentials carried in the request, and return the openid to the card binding management service after the verification is successful.

[0191] In step 307, the card binding management service returns a login success notification message to the mini-program.

[0192] In some embodiments, after receiving the openid returned by the third-party open platform, the card binding management service can return a login success notification message to the mini-program.

[0193] In step 308, the mini-program displays the mini-program homepage to the user.

[0194] In some embodiments, after receiving a successful login notification message from the card binding management service, the mini-program can display the mini-program homepage to the user, meaning that the user can directly enter the mini-program's main interface without registering an account.

[0195] The card binding table provided in the embodiments of this application will be described below.

[0196] In some embodiments, the card binding table (i.e., user_cards) serves as the system's sole business data table, storing user credit card binding information. The specific field design is shown in Table 1: Table 1. A diagram illustrating the multiple fields included in the card binding table.

[0197] Furthermore, in this embodiment, the user identifier and card index identifier can be used as unique indexes to prevent duplicate card binding. The user identifier can also be used as an index to query the user card list. Through these methods, this embodiment eliminates the need for a separate user table to store user information and a separate key table to store encryption keys. Duplicate card binding detection is achieved through a unique index. Additionally, the encrypted card number field only contains the version number and the encrypted data, eliminating the need for an additional version field.

[0198] The following will continue to combine Figure 11 The process of implementing the card binding service is explained.

[0199] In some embodiments, see Figure 11 , Figure 11 This is a schematic diagram of the third process of the data processing method provided in the embodiments of this application, as shown below. Figure 11As shown, the card binding management service can provide the following core functions: 1. User authorized login: Receives temporary login credentials from the mini-program, calls the application programming interface provided by the third-party open platform, exchanges the temporary login credentials for the user's openid, and uses the openid as the user identifier for all subsequent operations. 2. Credit card binding: Receives the card number and bank code entered by the user, calls the card number encryption / decryption module to encrypt the card number, and can also perform anti-duplicate card binding detection. When the query result indicates that the card already exists, it can return an error message to the mini-program indicating that the card is already bound; when the query result indicates that the card does not exist, it can insert the user identifier, card index identifier, encrypted card number, bank code, last 4 digits of the card number, and creation time into the card binding table, and can also return a card binding success message to the mini-program.

[0200] It should be noted that if a card list query request triggered by a user is received subsequently, all credit cards bound to that user can be queried based on the openid, and a card list (including, for example, the last 4 digits of the card number, bank code, and binding time) can be returned. The complete encrypted card number will not be returned to protect data security.

[0201] The following will continue to combine Figure 12 The process of querying card details is explained.

[0202] In some embodiments, see Figure 12 , Figure 12 This is a schematic diagram of the fourth process of the data processing method provided in the embodiments of this application, as shown below. Figure 12 As shown, when a user requests to view card details via the mini-program, the system first obtains the openid based on the OAuth2 protocol. Then, it queries the card binding table using the openid and card index identifier. If no record is found, the mini-program is returned a message indicating the card does not exist. If a record is found, the encrypted card number is extracted, and the card number encryption / decryption module is called to decrypt it and obtain the complete plaintext card number, which is then returned to the mini-program for the user to view. Furthermore, if a user-triggered card unbinding request is received, the corresponding record in the card binding table can be deleted based on the user identifier and card index identifier, physically deleting the data without retaining historical records.

[0203] In summary, the technical solutions provided by the embodiments of this application have the following beneficial effects: Compared with existing credit card management systems, the technical solution provided in this application has significant advantages in terms of security, storage cost, and system complexity, specifically in the following aspects: 1) Single-card key isolation to prevent bulk data leakage. This application embodiment uses a key derivation function to dynamically generate an independent encryption key for each credit card, taking the master key, card index, and user identifier as input parameters. Compared to a globally unified key scheme, even if a single encryption key is cracked, it only affects the data security of that single card and will not lead to the mass leakage of all users' card numbers. This meets the compliance requirements of financial security standards such as PCI DSS3.2.1 for graded protection of sensitive data and minimal impact, significantly improving the overall security of the system.

[0204] 2) Zero key storage cost, simplifying key management This application adopts a key derivation mechanism, which dynamically generates keys during encryption and decryption and destroys them from memory immediately after use. There is no need to store any data encryption keys or encrypted keys in the database. Compared with the traditional single card single key scheme, which requires maintaining an independent key storage table (each card occupies 32-64 bytes), this application completely eliminates key storage costs. When the system scale reaches millions of users and each user binds 2-3 cards on average, it can save the storage space of millions of key records. At the same time, it avoids the operation and maintenance costs of key table backup, recovery, access control, etc., and reduces the risk of key leakage.

[0205] 3) Lightweight single-table architecture reduces system complexity. This application embodiment obtains the user's unique identifier in the instant messaging client through the OAuth2 protocol as a unique identifier, eliminating the need to maintain a separate user table to store user names, mobile phone numbers, passwords, and other private data. Then, it generates a hexadecimal string using the SM3 hash algorithm as a card index, eliminating the need to maintain a key table to store encryption keys. In other words, this application embodiment only needs to maintain a single card-binding table to store triples and auxiliary fields such as bank codes, significantly simplifying the database architecture and reducing operational costs. It also reduces the risk of storing and leaking user privacy data, and lowers compliance pressure with regulations such as GDPR and personal information protection laws.

[0206] 4) Smooth key rotation, compatible with historical data This application employs a version number embedded in the ciphertext mechanism. During encryption, the master key version number is appended as a prefix to the ciphertext string, adding only 2-3 bytes of overhead. When the master key is rotated, newly bound cards use the new version of the master key, while historical data retains the original version number. During decryption, the correct version of the master key is automatically selected by parsing the ciphertext prefix. Thus, there is no need to re-encrypt historical data, avoiding the overhead of full data re-encryption caused by master key rotation in traditional schemes, achieving smooth key rotation and business continuity.

[0207] The following description continues to illustrate the exemplary structure of the data processing apparatus 543 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2As shown, the software modules stored in the data processing device 543 of the memory 540 may include: a receiving module 5431, a hashing module 5432, an acquisition module 5433, a generation module 5434, an encryption module 5435, a destruction module 5436, a construction module 5437, and a storage module 5438.

[0208] The receiving module 5431 is used to receive a data binding request sent by a client, wherein the data binding request carries the object identifier of the target object and the sensitive data of the target object; the hashing module 5432 is used to perform hash processing on the sensitive data to obtain the corresponding hash value; the obtaining module 5433 is used to obtain the root key from the key management system; the generating module 5434 is used to generate an encryption key for the sensitive data based on the root key, the object identifier, and the hash value; the encryption module 5435 is used to encrypt the sensitive data based on the encryption key to obtain ciphertext data; the destroying module 5436 is used to destroy the encryption key; the building module 5437 is used to build a data record including the object identifier, the hash value, and the ciphertext data; and the storage module 5438 is used to store the data record in a pre-created business data table.

[0209] In some embodiments, the generation module 5434 is further configured to obtain a preset key derivation function; use the hash value as the salt value parameter of the key derivation function and the object identifier as the context information parameter of the key derivation function; input the root key, the salt value parameter and the context information parameter into the key derivation function, and use the output of the key derivation function as the encryption key for sensitive data.

[0210] In some embodiments, the encryption module 5435 is further configured to randomly generate an initialization vector of fixed length; encrypt sensitive data using the encryption key and the initialization vector to obtain an encryption payload; obtain the version identifier of the root key; and concatenate the version identifier, the initialization vector, and the encryption payload to obtain ciphertext data.

[0211] In some embodiments, the encryption module 5435 is further configured to initialize an encryption instance using an encryption key and an initialization vector; convert sensitive data into ciphertext fragments using the encryption instance and generate authentication tags for the sensitive data; and combine the ciphertext fragments and authentication tags to obtain an encryption payload.

[0212] In some embodiments, the hash module 5432 is further configured to obtain a pre-configured system-level interference code, wherein the system-level interference code is stored in an application configuration file or environment variable; mix the sensitive data and the system-level interference code according to a preset rule to obtain mixed data; perform a digest algorithm calculation on the mixed data, and use the calculated digest result as the hash value corresponding to the sensitive data.

[0213] In some embodiments, the hash module 5432 is further configured to generate a first key padding value and a second key padding value based on a preset hash key; concatenate the first key padding value with sensitive data to obtain a first concatenation result, and perform a hash operation on the first concatenation result to obtain an inner hash digest; concatenate the second key padding value with the inner hash digest to obtain a second concatenation result, and perform a hash operation on the second concatenation result to obtain a hash value corresponding to the sensitive data.

[0214] In some embodiments, the construction module 5437 is further configured to generate a structured record containing a metadata area and a data entity area according to a predefined storage protocol; write the object identifier and hash value into the metadata area and write the encrypted data into the data entity area; and establish a logical association between the metadata area and the data entity area to form a logically complete data record.

[0215] In some embodiments, the construction module 5437 is further configured to obtain the organization code of the organization associated with the sensitive data and extract the last character fragment of the sensitive data; combine the organization code and the last character fragment into plaintext index data; and construct a composite data record including object identifier, plaintext index data, hash value and ciphertext data.

[0216] In some embodiments, the data processing apparatus 543 further includes a verification module 5439, which performs the following processing before the hash module 5432 performs hash processing on the sensitive data: performs format validity verification on the sensitive data based on preset verification rules; when the sensitive data passes the format validity verification, it proceeds to the step of performing hash processing on the sensitive data.

[0217] In some embodiments, the data processing device 543 further includes a return module 54310, which is used to return a prompt message to the client that the sensitive data is incorrect when the sensitive data fails the format validity check.

[0218] In some embodiments, the data processing apparatus 543 further includes a query module 54311, configured to query a pre-created business data table based on a hash value before the storage module 5438 stores the data record into the pre-created business data table; the storage module 5438 is further configured to store the data record into the business data table when there is no data record including a hash value in the business data table.

[0219] In some embodiments, the return module 54310 is further configured to refuse to store the data record in the business data table when there is a data record in the business data table that includes a hash value, and to return a prompt message to the client indicating that sensitive data has been bound.

[0220] In some embodiments, after the storage module 5438 stores data records into a pre-created business data table, the receiving module 5431 is further configured to receive a data query request sent by the client, wherein the data query request carries an object identifier and encrypted data; the query module 54311 is further configured to query the business data table based on the object identifier and encrypted data to obtain data records including the object identifier and encrypted data, and extract hash values ​​from the queried data records; the obtaining module 5433 is further configured to obtain a root key from the key management system; the generating module 5434 is further configured to generate a decryption key based on the root key, hash value, and object identifier; the data processing device 543 further includes a decryption module 54312, configured to decrypt the encrypted data using the decryption key to obtain sensitive data; the destruction module 5436 is further configured to destroy the decryption key; and the return module 54310 is further configured to return the sensitive data to the client.

[0221] In some embodiments, the ciphertext data includes a version identifier of the root key used during encryption; the acquisition module 5433 is further configured to parse the ciphertext data to obtain the version identifier of the root key used during encryption; and to obtain the root key corresponding to the version identifier from the key management system.

[0222] In some embodiments, after the decryption module 54312 decrypts the ciphertext data using the decryption key, the acquisition module 5433 is further configured to acquire the version identifier of the latest root key from the key management system; the generation module 5434 is further configured to generate a new encryption key based on the latest root key, hash value, and object identifier when the version identifier parsed from the ciphertext data is earlier than the version identifier of the latest root key; the encryption module 5435 is further configured to encrypt sensitive data using the new encryption key to obtain new ciphertext data; the construction module 5437 is further configured to construct a new data record including the new ciphertext data, hash value, and object identifier; the data processing device 543 also includes a replacement module 54313, configured to replace the data record stored in the business data table with the new data record.

[0223] In some embodiments, the object identifier is obtained by the client in the following ways: in response to a login instruction initiated by the target object, the client is redirected to the authorization page of the third-party open platform based on a standard authorization protocol; the client receives the authorization code returned by the third-party open platform after the target object confirms the authorization; the client requests an access token from the third-party open platform using the authorization code, and parses the response data of the access token to obtain a unique object identifier generated by the third-party open platform for the target object.

[0224] It should be noted that the description of the apparatus in this application embodiment is similar to the description of the method embodiment above, and has similar beneficial effects as the method embodiment; therefore, it will not be repeated. For any technical details not covered in the data processing apparatus provided in this application embodiment, please refer to... Figure 3 ,or Figure 4 The meaning is understood in accordance with the description of any of the accompanying drawings.

[0225] This application provides a computer program product, which includes a computer program or computer-executable instructions. The processor of an electronic device reads the computer-executable instructions from a computer-readable storage medium, and executes the computer-executable instructions, causing the electronic device to perform the data processing method described in this application embodiment.

[0226] This application provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are executed by a processor, they cause the processor to perform the data processing method provided in this application. For example, ... Figure 3 ,or Figure 4 The data processing method is shown.

[0227] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0228] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0229] As an example, executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located in one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0230] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A data processing method, characterized in that, The method includes: Receive a data binding request sent by the client, wherein the data binding request carries the object identifier of the target object and the sensitive data of the target object; The sensitive data is hashed to obtain the corresponding hash value; Obtain the root key from the key management system, and generate an encryption key for the sensitive data based on the root key, the object identifier, and the hash value; The sensitive data is encrypted using the encryption key to obtain ciphertext data, and the encryption key is then destroyed. Construct a data record including the object identifier, the hash value, and the ciphertext data, and store the data record in a pre-created business data table.

2. The method according to claim 1, characterized in that, The step of generating an encryption key for the sensitive data based on the root key, the object identifier, and the hash value includes: Obtain the preset key derivation function; The hash value is used as the salt parameter of the key derivation function, and the object identifier is used as the context information parameter of the key derivation function. The root key, the salt value parameter, and the context information parameter are input into the key derivation function, and the output of the key derivation function is used as the encryption key for the sensitive data.

3. The method according to claim 1, characterized in that, The process of encrypting the sensitive data based on the encryption key to obtain ciphertext data includes: Randomly generate an initialization vector of fixed length; The sensitive data is encrypted using the encryption key and the initialization vector to obtain the encrypted payload; Obtain the version identifier of the root key; The version identifier, the initialization vector, and the encryption payload are concatenated to obtain ciphertext data.

4. The method according to claim 3, characterized in that, The step of encrypting the sensitive data using the encryption key and the initialization vector to obtain the encrypted payload includes: The encryption instance is initialized using the encryption key and the initialization vector; The sensitive data is converted into ciphertext fragments through the encryption instance, and an authentication tag for the sensitive data is generated. The encrypted payload is obtained by combining the ciphertext fragment and the authentication tag.

5. The method according to claim 1, characterized in that, The process of hashing the sensitive data to obtain the corresponding hash value includes: Obtain a pre-configured system-level jamming code, wherein the system-level jamming code is stored in an application configuration file or environment variables; The sensitive data and the system-level interference code are mixed according to a preset rule to obtain mixed data; A digest algorithm is performed on the mixed data, and the resulting digest is used as the hash value corresponding to the sensitive data.

6. The method according to claim 1, characterized in that, The process of hashing the sensitive data to obtain the corresponding hash value includes: Based on the preset hash key, generate the first key padding value and the second key padding value; The first key padding value is concatenated with the sensitive data to obtain a first concatenation result, and a hash operation is performed on the first concatenation result to obtain an inner hash digest; The second key padding value is concatenated with the inner hash digest to obtain a second concatenation result, and a hash operation is performed on the second concatenation result to obtain a hash value corresponding to the sensitive data.

7. The method according to claim 1, characterized in that, The construction of a data record including the object identifier, the hash value, and the ciphertext data includes: Generate structured records containing metadata and data entity areas according to a predefined storage protocol; Write the object identifier and the hash value into the metadata area, and write the ciphertext data into the data entity area; Establish a logical association between the metadata area and the data entity area to form a logically complete data record.

8. The method according to claim 1, characterized in that, The construction of a data record including the object identifier, the hash value, and the ciphertext data includes: Obtain the organization code of the organization associated with the sensitive data, and extract the last character fragment of the sensitive data; The organization code and the last character fragment are combined into plaintext index data; Construct a composite data record that includes the object identifier, the plaintext index data, the hash value, and the ciphertext data.

9. The method according to claim 1, characterized in that, Before hashing the sensitive data, the method further includes: The sensitive data is validated for format validity based on preset validation rules; When the sensitive data passes the format validity check, the process proceeds to the step of hashing the sensitive data.

10. The method according to claim 9, characterized in that, The method further includes: When the sensitive data fails the format validity check, a message indicating that the sensitive data is incorrect is returned to the client.

11. The method according to claim 1, characterized in that, Before storing the data records into a pre-created business data table, the method further includes: Query the pre-created business data table based on the hash value; When there is no data record containing the hash value in the business data table, the data record is stored in the business data table.

12. The method according to claim 11, characterized in that, The method further includes: When a data record containing the hash value exists in the business data table, the system refuses to store the data record in the business data table and returns a prompt message to the client indicating that the sensitive data has been bound.

13. The method according to any one of claims 1 to 12, characterized in that, After storing the data records in a pre-created business data table, the method further includes: Receive a data query request sent by the client, wherein the data query request carries the object identifier and the encrypted data; Based on the object identifier and the encrypted data, the business data table is queried to obtain data records including the object identifier and the encrypted data, and the hash value is extracted from the queried data records; Obtain the root key from the key management system, and generate a decryption key based on the root key, the hash value, and the object identifier; The encrypted data is decrypted using the decryption key to obtain the sensitive data, and the decryption key is then destroyed. The sensitive data is returned to the client.

14. The method according to claim 13, characterized in that, The ciphertext data includes a version identifier of the root key used during encryption; Obtaining the root key from the key management system includes: The ciphertext data is parsed to obtain the version identifier of the root key used during encryption; Obtain the root key corresponding to the version identifier from the key management system.

15. The method according to claim 14, characterized in that, After decrypting the ciphertext data using the decryption key, the method further includes: Obtain the version identifier of the latest root key from the key management system; When the version identifier parsed from the ciphertext data is earlier than the version identifier of the latest root key, a new encryption key is generated based on the latest root key, the hash value, and the object identifier. The sensitive data is encrypted using the new encryption key to obtain new ciphertext data; Construct a new data record that includes the new encrypted data, the hash value, and the object identifier, and replace the data record stored in the business data table with the new data record.

16. The method according to any one of claims 1 to 12, characterized in that, The object identifier is obtained by the client in the following way: In response to a login command initiated by the target object, the client is redirected to the authorization page of a third-party open platform based on a standard authorization protocol; Receive the authorization code returned by the third-party open platform after the target object confirms the authorization; The authorization code is used to request an access token from the third-party open platform, and the response data of the access token is parsed to obtain a unique object identifier generated by the third-party open platform for the target object.

17. A data processing apparatus, characterized in that, The device includes: A receiving module is used to receive a data binding request sent by a client, wherein the data binding request carries the object identifier of the target object and the sensitive data of the target object; The hash module is used to perform hash processing on the sensitive data to obtain the corresponding hash value; The acquisition module is used to obtain the root key from the key management system; A generation module is used to generate an encryption key for the sensitive data based on the root key, the object identifier, and the hash value; An encryption module is used to encrypt the sensitive data based on the encryption key to obtain ciphertext data; The destruction module is used to destroy the encryption key; The construction module is used to construct a data record including the object identifier, the hash value, and the ciphertext data; The storage module is used to store the data records into a pre-created business data table.

18. An electronic device, characterized in that, include: Memory is used to store executable instructions for a computer; A processor, when executing computer-executable instructions stored in the memory, implements the data processing method according to any one of claims 1 to 16.

19. A computer-readable storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed by the processor, they implement the data processing method according to any one of claims 1 to 16.

20. A computer program product comprising a computer program or computer-executable instructions, characterized in that, When the computer program or computer-executable instructions are executed by a processor, the data processing method according to any one of claims 1 to 16 is implemented.

Images