POS machine transaction data security processing method and system based on multi-dimensional feature analysis

Abstract

This application provides a method and system for secure processing of POS machine transaction data based on multi-dimensional feature analysis. The method involves generating a trusted snapshot by performing a trust measurement on the POS terminal using a hardware root of trust; combining the trust measurement results, transaction context, and field categories for multi-dimensional analysis to generate field trust factors for each field category; deriving corresponding field encryption subkeys based on each field trust factor; performing partitioned encryption on different field categories to obtain corresponding field partition ciphertexts; generating corresponding field encryption proof values ​​based on the transaction context, according to the field trust factors and field partition ciphertexts for each field category; verifying the legality of each field partition ciphertext and its field encryption proof value based on the trusted snapshot; and performing security processing on the corresponding transaction fields based on the verification results. This application can dynamically bind the terminal's trust status with field-level encryption to improve the granularity of POS machine transaction data security protection.

Description

Technical Field

[0001] This application relates to the field of financial payment security technology, and more specifically, to a method and system for secure processing of POS machine transaction data based on multi-dimensional feature analysis. Background Technology

[0002] Point-of-Sale (POS) terminals are important terminal devices in bank card payments, QR code payments, and other offline transaction scenarios. They typically need to collect and process multiple transaction fields, such as master account, transaction amount, merchant information, terminal information, authentication information, and personal identification codes. Because these transaction fields have different business attributes and security sensitivities, if they are tampered with, stolen, or forged during collection, processing, encryption, or transmission, it can easily lead to security risks such as transaction fraud, financial losses, and leakage of user privacy.

[0003] However, existing POS transaction data security processing methods mostly employ a unified encryption method to encrypt and verify the entire transaction as a whole, lacking differentiated security control for different transaction fields. Furthermore, the encryption key and the terminal's real-time trusted state are disconnected, failing to combine terminal trusted state and transaction scenario characteristics for multi-dimensional security verification. Simultaneously, traditional solutions typically perform unified verification and overall processing of the entire transaction, failing to accurately identify tampering or abnormal risks in local fields within a single transaction. This easily leads to risky data infiltrating the normal transaction process or indiscriminately intercepting legitimate transactions, resulting in poor transaction data security, low risk control granularity, and weak scenario adaptability. Therefore, how to dynamically bind the terminal's trusted state with field-level encryption to improve the granularity of POS transaction data security protection has become a challenge facing the industry. Summary of the Invention

[0004] This application provides a method and system for secure processing of POS machine transaction data based on multi-dimensional feature analysis, which can dynamically bind the trusted status of the terminal with field-level encryption to improve the precision of POS machine transaction data security protection.

[0005] Firstly, this application provides a method for securely processing POS machine transaction data based on multi-dimensional feature analysis, including the following steps: In response to a POS transaction request, the hardware root of trust performs a trust measurement on the POS terminal to generate a trust snapshot; Based on the credibility measurement results, transaction context, and the field categories of transaction data, a multi-dimensional analysis is performed to generate a unique field credibility factor for each field category. For each field category, the field trust factor is used as the key derivation factor to generate a field encryption subkey for that field category. The field encryption subkey is then used to perform partition encryption on the transaction fields belonging to that field category to obtain the field partition ciphertext. Based on the transaction context, corresponding field encryption proof values ​​are generated according to the field trust factor and field partition ciphertext of each field category. Based on the trusted snapshot, verify the legality of the encrypted partition of each field and the encrypted proof value of each field, and perform security processing on the corresponding transaction fields according to the verification results.

[0006] In some embodiments, in response to a POS transaction request, generating a trusted snapshot by performing a trust measurement on the POS terminal using a hardware root of trust specifically includes: In response to a POS transaction request, obtain the transaction context corresponding to the current transaction session; The hardware root of trust performs step-by-step trust measurement on each key system component of the POS terminal according to the transmission order of the trust measurement chain, resulting in multiple trust measurement items and the trust measurement results corresponding to each trust measurement item. Based on the transaction context and the results of each trust metric, a trust snapshot bound to the current transaction session is generated.

[0007] In some embodiments, multi-dimensional analysis is performed based on the credibility measurement results, transaction context, and various field categories of the transaction data to generate a unique field credibility factor for each field category. Specifically, this includes: For each field category, determine the set of security dependency metrics corresponding to that field category; Extract the target trust measure result that matches the set of security dependency measures from multiple trust measure results; The field identifier of the field category, the target trust measurement result, and the transaction context are combined to generate a field trust factor that uniquely corresponds to the field category. Iterate through all field categories and then generate the field confidence factor corresponding to each field category.

[0008] In some embodiments, for each field category, generating a field encryption subkey for that field category using the field trust factor as a key derivation factor specifically includes: Obtain the pre-installed transaction root key within the POS terminal; For each field category, select multiple parameters from the field trust factor, field identifier, transaction random number, and transaction serial number of that field category to form the key derivation input parameters; The transaction root key and the key derivation input parameters are derived by using a key derivation function to obtain the field encryption subkey corresponding to the field category.

[0009] In some embodiments, the transaction field belonging to the field category is partitioned and encrypted using the field encryption subkey to obtain the field partition ciphertext, specifically including: The transaction data is divided into multiple field partitions according to field categories. Each field partition includes one or more transaction fields belonging to the same field category. Generate a corresponding random number for each field partition; Using the field encryption subkey corresponding to the field category and combining it with the field partition random number, the transaction field within the field partition is encrypted to obtain the ciphertext of the field partition corresponding to the field category.

[0010] In some embodiments, generating corresponding field encryption proof values ​​based on the transaction context, according to the field trust factor and field partition ciphertext of each field category, specifically includes: Iterate through all field categories, and associate and match the transaction context with the field trust factor and field partition ciphertext corresponding to the current field category; The associated data is fused using a message authentication code algorithm to generate a field encryption proof value corresponding to the current field category.

[0011] In some embodiments, based on the trusted snapshot, verifying the legality of the ciphertext of each field partition and the encryption proof value of its fields, and performing security measures on the corresponding transaction fields according to the verification results, specifically includes: Upload the encrypted text of each field partition and its corresponding encrypted proof value to the backend; The backend verifies the field credibility factor of each field category one by one based on the trusted snapshot, and completes the legality verification of the corresponding field encrypted proof value based on the field credibility factor that has passed the verification. When the encrypted proof value of a field corresponding to a certain field category passes the verification, it is determined that the ciphertext of the field partition of that field category is generated in an appropriate trusted state, and thus the transaction field corresponding to that field category is allowed to be recorded, stored and transferred normally. When the verification of the encrypted proof value of a field corresponding to a certain field category fails, field-level security measures are taken for the transaction field corresponding to that field category based on the security level and business dependencies of that field category.

[0012] Secondly, this application provides a POS machine transaction data security processing system based on multi-dimensional feature analysis, used to execute a POS machine transaction data security processing method based on multi-dimensional feature analysis, including: The Trust Measurement module is used to generate a Trust Snapshot by performing a Trust Measurement on the POS terminal in response to a POS transaction request, using the hardware root of trust. The multidimensional feature analysis module is used to perform multidimensional analysis based on the credibility measurement results, transaction context, and various field categories of transaction data, and to generate a unique field credibility factor for each field category. The partition encryption module is used to generate a field encryption subkey for each field category, using the field trust factor as the key derivation factor, and then use the field encryption subkey to perform partition encryption on the transaction fields belonging to that field category to obtain the field partition ciphertext. The field proof calculation module is used to generate corresponding field encryption proof values ​​based on the transaction context, according to the field credibility factor and field partition ciphertext of each field category. The security processing module is used to verify the legality of the encrypted text of each field partition and the encrypted proof value of its fields based on the trusted snapshot, and to perform security processing on the corresponding transaction fields according to the verification results.

[0013] Thirdly, this application provides a computer device, the computer device including a memory and a processor, the memory storing code, and the processor being configured to acquire the code and execute the above-described POS machine transaction data security processing method based on multi-dimensional feature analysis.

[0014] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described POS transaction data security processing method based on multi-dimensional feature analysis.

[0015] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects: The POS transaction data security processing method and system based on multi-dimensional feature analysis provided in this application, in response to a POS transaction request, generates a trusted snapshot by performing a trust measurement on the POS terminal using a hardware root of trust; performs multi-dimensional analysis based on the trust measurement results, transaction context, and various field categories of the transaction data, generating a unique field trust factor for each field category; for each field category, uses the field trust factor as a key derivation factor to generate a field encryption subkey for that field category, and uses the field encryption subkey to partition and encrypt the transaction fields belonging to that field category, obtaining field partition ciphertext; based on the transaction context, generates corresponding field encryption proof values ​​according to the field trust factor and field partition ciphertext of each field category; verifies the legality of each field partition ciphertext and its field encryption proof value based on the trusted snapshot, and performs security processing on the corresponding transaction fields according to the verification results.

[0016] Therefore, this application demonstrates that, firstly, by generating the trusted snapshot before the transaction field enters the encryption process, the true and trusted state of each key system component of the POS machine under the current transaction session can be solidified in advance, effectively avoiding the data security risks caused by directly encrypting the transaction field after it has been processed by an untrusted collection channel or abnormal system component; secondly, by combining and binding the field identifier, target trust measurement result, and transaction context, the traditional terminal trust status at the whole machine level is refined to the field-level granularity, allowing transaction fields of different security levels to match the corresponding component trust verification results according to their own business attributes and security dependencies, forming differentiated trust parameter support; simultaneously, by dynamically deriving subkeys based on the field trust factor, differentiated encryption subkeys are generated for different field categories, achieving field-level granularity encryption. Key isolation; in conjunction with the HKDF standardized key derivation mechanism, and using unique parameters for each transaction in key generation, key reuse can be effectively prevented, improving the uniqueness and anti-attack capabilities of the key system; then, by partitioning and encrypting transaction data according to field categories, and generating a field encryption subkey for each field category, key isolation and ciphertext isolation between different field categories can be achieved; finally, the backend server performs dual verification of the trust factor and encryption proof value for each field category, realizing field-level trusted collection and verifiable encryption status of POS transaction data; when a field verification fails, differentiated handling is performed according to its security level, thereby accurately blocking or downgrading abnormal fields without affecting the entire transaction, improving the flexibility and reliability of transaction security processing.

[0017] In summary, the technical solution adopted in this application can dynamically bind the trusted state of the terminal with field-level encryption to improve the precision of POS machine transaction data security protection. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only for this embodiment of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is an exemplary flowchart of a POS machine transaction data security processing method based on multi-dimensional feature analysis, as shown in some embodiments of this application. Figure 2 This is a schematic diagram illustrating an application scenario of a POS machine transaction data security processing method based on multi-dimensional feature analysis, as shown in some embodiments of this application. Figure 3This is an exemplary flowchart illustrating the generation of a unique field confidence factor for each field category, according to some embodiments of this application; Figure 4 This is a schematic diagram of the structure of a POS machine transaction data security processing system based on multi-dimensional feature analysis, as shown in some embodiments of this application; Figure 5 This is a schematic diagram of the structure of a computer device that implements a POS transaction data security processing method based on multi-dimensional feature analysis, according to some embodiments of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0021] This application provides a method and system for secure processing of POS transaction data based on multi-dimensional feature analysis. The core of this method is as follows: In response to a POS transaction request, a hardware root of trust performs a trust measurement on the POS terminal to generate a trust snapshot; based on the trust measurement results, transaction context, and the categories of each field in the transaction data, multi-dimensional analysis is performed to generate a unique field trust factor for each field category; for each field category, the field trust factor is used as a key derivation factor to generate a field encryption subkey for that field category; the field encryption subkey is used to partition and encrypt transaction fields belonging to that field category to obtain field partition ciphertext; based on the transaction context, corresponding field encryption proof values ​​are generated according to the field trust factor and field partition ciphertext for each field category; based on the trust snapshot, the legality of each field partition ciphertext and its field encryption proof value is verified, and security measures are performed on the corresponding transaction fields based on the verification results. This approach dynamically binds the terminal's trust status with field-level encryption, thereby improving the granularity of POS transaction data security protection.

[0022] To better understand the above technical solutions, a detailed description of the technical solutions will be provided below in conjunction with the accompanying drawings and specific embodiments. (Refer to...) Figure 1 This figure is an exemplary flowchart of a POS machine transaction data security processing method based on multi-dimensional feature analysis, according to some embodiments of this application. The figure mainly includes the following steps: In step S101, in response to a POS transaction request, a trusted snapshot is generated by the hardware root of trust performing a trusted measurement on the POS terminal.

[0023] In some embodiments, in response to a POS transaction request, the hardware root of trust performs a trust measurement on the POS terminal to generate a trust snapshot. This can be achieved in the following ways: In response to a POS transaction request, obtain the transaction context corresponding to the current transaction session; The hardware root of trust performs step-by-step trust measurement on each key system component of the POS terminal according to the transmission order of the trust measurement chain, resulting in multiple trust measurement items and the trust measurement results corresponding to each trust measurement item. Based on the transaction context and the results of each trust metric, a trust snapshot bound to the current transaction session is generated.

[0024] It should be noted that, Figure 2 This is a schematic diagram of an application scenario for a POS transaction data security processing method based on multi-dimensional feature analysis, as shown in some embodiments of this application. As shown in the figure, the dashed box on the left represents transaction triggering events, including triggering forms such as card swiping, QR code payment, and interface online reporting. Various transaction events generate transaction requests and input them to the POS terminal in the middle. After the POS terminal extracts the transaction context corresponding to the current session, it sends the relevant data to the hardware trust root on the right, which integrates a hardware security module (HSM).

[0025] Additionally, it should be noted that the transaction context is used to uniquely represent the business environment and temporal environment of the current transaction session, and to bind the trusted measurement result to the current transaction session. This includes, but is not limited to, the transaction serial number, transaction timestamp, terminal identifier, merchant identifier, and transaction random number. The transaction random number is generated by the random number generator of the POS terminal, used to differentiate the trusted snapshots corresponding to different transaction sessions, thereby reducing the risk of historical trusted snapshots being reused. The hardware root of trust is a hardware security module integrated into the trusted platform module within the POS main chip. It has pre-set trusted benchmark values, measurement calculation logic, and a security key for generating trusted snapshots. The key system components include at least a startup loading component, an operating system component, a transaction application component, a field acquisition component, an encryption component, and a key management component. Correspondingly, corresponding trusted measurement items are set for each key system component, such as a trusted measurement item for the key management component. These trusted measurement items serve as classification identifiers for the corresponding components, used to distinguish the verification entries of different components. Component integrity is represented by the trusted measurement result bound to this trusted measurement item. The trusted snapshot is used to represent the trusted operating state of the POS terminal before transaction field encryption in the current transaction session.

[0026] In practice, when the POS terminal detects a transaction trigger event, such as swiping a card, inserting a card, waving a card, scanning a code to enter a transaction amount, calling a payment interface, or reporting the transaction online, a POS transaction request is generated. In response to the POS transaction request, the POS terminal obtains the transaction context corresponding to the current transaction session and passes the transaction context to the hardware root of trust. Then, the hardware root of trust performs step-by-step trust measurements on each key system component of the POS terminal according to the transmission order of the trust measurement chain. The transmission order of the trust measurement chain is as follows: when the POS terminal is powered on and started, starting from the boot read-only memory, the bootloader, operating system kernel, key drivers, system service processes, and security-sensitive applications are measured in sequence. In each level of measurement, the hardware root of trust calculates the hash value of the component image or program file corresponding to the current system component based on the Secure Hash Algorithm 256 (SHA-256) to obtain the corresponding component measurement value, and compares the measurement value with the pre-stored trust benchmark value. When the component measurement value is consistent with the corresponding trust benchmark value, the component trust status of the component is determined to be trustworthy; otherwise, it is abnormal. The trust benchmark value is a standard hash value that is encrypted, signed, solidified, and cannot be tampered with by the equipment manufacturer during the initialization phase of the POS terminal system. The component measurement value, component trust status, and measurement timestamp of the component are then used as the trust measurement result of the component. Through step-by-step measurement, multiple trust measurement items and corresponding trust measurement results are obtained.

[0027] In addition, in the specific implementation, all metrics and their results are arranged in the order of measurement and combined with the transaction context to form the original trusted snapshot data; the hardware root of trust calculates the digest of the original trusted snapshot data using SHA-256 to obtain the trusted snapshot digest; further, the message authentication code is calculated on the trusted snapshot digest using the message authentication key built into the hardware root of trust to obtain the trusted snapshot proof information; the original trusted snapshot data, the trusted snapshot digest, and the trusted snapshot proof information are used together as a trusted snapshot uniquely bound to this transaction session.

[0028] It should be noted that by using hierarchical trust measurement, the trustworthiness of each subsequent component is built upon the trustworthiness of the preceding component, thus forming a trust chain that propagates from the underlying hardware trust root to the upper-level transaction processing environment. By generating trust measurement results for each key system component, the subsequently generated trust snapshots can reflect not only the overall trustworthiness of the POS terminal but also the trustworthiness of each key system component in a specific transaction processing step. By generating the trust snapshots before the transaction fields enter the encryption process, the true trustworthiness of each key system component of the POS machine in the current transaction session can be solidified in advance, effectively avoiding the data security risks caused by directly encrypting transaction fields after they have been processed through untrusted acquisition channels or abnormal system components.

[0029] In step S102, a multi-dimensional analysis is performed based on the credibility measurement results, transaction context, and the field categories of the transaction data to generate a unique field credibility factor for each field category.

[0030] Preferably, in some embodiments, reference is made to Figure 3 As shown in the figure, this is an exemplary flowchart illustrating the generation of a unique field credibility factor for each field category according to some embodiments of this application. In this embodiment, multi-dimensional analysis is performed based on credibility measurement results, transaction context, and each field category of transaction data. The generation of a unique field credibility factor for each field category can be achieved through the following steps: In step S1021, for each field category, the set of security dependency metrics corresponding to that field category is determined; In step S1022, a target trust measure result that matches the set of security dependency measures is extracted from multiple trust measure results; In step S1023, the field identifier of the field category, the target trust measurement result, and the transaction context are combined and calculated to generate a field trust factor that uniquely corresponds to the field category. In step S1024, all field categories are traversed, and then the field confidence factor corresponding to each field category is generated.

[0031] It should be noted that the field categories are divided according to the business attributes and security sensitivity levels of each transaction field in the transaction data, specifically into six categories: main account, personal identification code, transaction amount, merchant terminal, transaction voucher, and communication security. The main account field category covers the bank card main account and card serial number; the personal identification code field category includes the personal identification code ciphertext block; the transaction amount field category includes the transaction amount and currency; the merchant terminal field category includes the merchant number and terminal number; the transaction voucher field category includes the transaction authentication code, application ciphertext, authorization request ciphertext, and dynamic verification code; and the communication security field category includes link authentication information. The set of security dependency metrics is used to characterize the key trusted states that a field category relies on during collection, generation, processing, encryption, or transmission. The field trust factor is used to characterize the trusted generation environment and trusted processing environment of the corresponding field category in the current transaction session, reflecting the trusted measurement results of the security dependency metrics that the field category relies on in this transaction.

[0032] In practice, the first step is to determine the set of security dependency metrics corresponding to each field category. Since different transaction fields have different degrees of security dependency on the terminal operating environment, a security dependency metric mapping table can be configured in advance, referring to the data security standards of the payment card industry and combining the POS terminal system architecture. The table registers the trusted metrics associated with each field category. For example, for the main account field category, its set of security dependency metrics includes trusted metrics for the field acquisition component, trusted metrics for the encryption component, and trusted metrics for the key management component. Then, for the set of security dependency metrics for the current field category, iterate through each metric name in the set, retrieve the corresponding trusted metric result from the original trusted snapshot data of the trusted snapshot, and use one or more found trusted metric results together as the target trusted metric result for the field category. In actual implementation, when a security dependency metric does not have a corresponding result in the trusted metric result, or the corresponding result is abnormal, the missing or abnormal state of the security dependency metric can be written into the target trusted metric result, so that the field trust factor generated subsequently can reflect the incomplete or untrustworthy security dependency state corresponding to the field category; thus avoiding misjudging the incomplete trusted state as a trusted state due to ignoring missing metrics.

[0033] In addition, in specific implementation, for each field category, the field identifier, target trust measurement result, and transaction context of that field category are normalized according to a preset encoding rule to obtain the field trust factor input data. The preset encoding rule is pre-defined based on the field type, trust measurement result format, and transaction context composition; the field identifier is a predefined field type number; the normalization process includes field sorting, length encoding, data format unification, and binary encoding to ensure consistent combination results for the same input data across different processing endpoints. Subsequently, the input data is hashed using a cryptographic hash function, and the resulting hash value is the field trust factor for that field category. Finally, all field categories contained in the current transaction data are traversed, and for each field category, the security dependency measurement item set is determined, the target trust measurement result is extracted, and combination operations are performed to generate the field trust factor corresponding to each field category.

[0034] It should be noted that, since the generation process of field trust factors simultaneously incorporates the field identifier of the field category, the target trust measurement result corresponding to the field category, and the transaction context of the current transaction session, different field categories will generate different field trust factors even within the same transaction session due to differences in field identifiers and security dependency metrics; the same field category will also generate different field trust factors in different transaction sessions due to different transaction contexts; and the same field category will generate different field trust factors when the terminal trust status changes due to differences in the target trust measurement result. Thus, it is ensured that the field trust factor is simultaneously bound to the field category, the terminal trust status, and the current transaction session.

[0035] It should be noted that by determining different sets of security dependency metrics for different field categories, the generation process of field trust factors can be matched with the actual security dependency relationship of the field, avoiding the problem of inaccurate expression of trust status caused by using a unified trust measurement result to bind all fields in a coarse-grained manner. By combining field identifiers, target trust measurement results and transaction context for fusion binding, the traditional terminal trust status at the whole machine level is refined to the field level granularity, so that transaction fields of different security levels can match the corresponding component trust verification results according to their own business attributes and security dependencies, forming differentiated trust parameter support.

[0036] In step S103, for each field category, the field trust factor is used as the key derivation factor to generate a field encryption subkey for that field category. The field encryption subkey is then used to perform partition encryption on the transaction fields belonging to that field category to obtain the field partition ciphertext.

[0037] In some embodiments, for each field category, the field encryption subkey for that field category can be generated using the field trust factor as the key derivation factor in the following manner: Obtain the pre-installed transaction root key within the POS terminal; For each field category, select multiple parameters from the field trust factor, field identifier, transaction random number, and transaction serial number of that field category to form the key derivation input parameters; The transaction root key and the key derivation input parameters are derived by using a key derivation function to obtain the field encryption subkey corresponding to the field category.

[0038] It should be noted that the field encryption subkey is an encryption key generated for the field category. Since the derivation process of the field encryption subkey introduces the field trust factor, and the field trust factor is bound to the field category, the target trust measurement result, and the transaction context, the field encryption subkeys generated for the same field category in different transaction sessions and for different field categories in the same session are all different.

[0039] In practice, firstly, the POS terminal obtains the pre-installed transaction root key through the hardware root of trust. This transaction root key is a master key injected by the key management system and securely stored in the non-volatile storage area of ​​the hardware root of trust during the POS terminal's production or initialization phase. It is used to derive the encryption subkeys for each field category in each transaction. Then, for each field category of the current transaction data, the POS terminal obtains the corresponding field trust factor and collects the field identifier of that field category, the transaction random number in the current transaction session, and the transaction serial number. These parameters are concatenated into a binary string according to a preset field order, field length, and field format as the key derivation input parameters. The preset field order, field length, and field format are uniformly defined and fixed during the device's factory firmware compilation phase. Secondly, a key derivation function is used in conjunction with the transaction root key and key derivation input parameters to perform key derivation operations, outputting the field encryption subkey corresponding to the current field category. In this embodiment, the key derivation function is a hash-based message authentication code (HMAC) based key derivation function (HKDF). Its calculation process is as follows: First, the transaction root key is used as the initial key material, and the key derivation input parameters are used as the salt value. After two operation stages of extraction and expansion, a fixed-length key is generated, which is the field encryption subkey corresponding to the field category. The key derivation process is repeated for all field categories to obtain the field encryption subkey corresponding to each field category.

[0040] It should be noted that the dynamic derivation of subkeys based on field trust factors enables the generation of differentiated encryption subkeys for different field categories, achieving field-level key isolation. Combined with the HKDF standardized key derivation mechanism, and the participation of unique parameters of a single transaction in key generation, key reuse can be effectively prevented, thereby improving the uniqueness and anti-attack capability of the key system.

[0041] In some embodiments, the transaction fields belonging to the field category are partitioned and encrypted using the field encryption subkey to obtain the field partition ciphertext. Specifically, this can be achieved in the following manner: The transaction data is divided into multiple field partitions according to field categories. Each field partition includes one or more transaction fields belonging to the same field category. Generate a corresponding random number for each field partition; Using the field encryption subkey corresponding to the field category and combining it with the field partition random number, the transaction field within the field partition is encrypted to obtain the ciphertext of the field partition corresponding to the field category.

[0042] It should be noted that the field partition ciphertext is ciphertext data obtained by encrypting the transaction fields within the field partition using the corresponding field encryption subkey. It is used to provide verifiable field-level ciphertext units to the backend server while ensuring data confidentiality.

[0043] In specific implementation, firstly, the POS terminal divides the current transaction data according to field categories, grouping one or more transaction fields belonging to the same field category into the same field partition. For example, transaction fields such as the bank card main account and card serial number are divided into a main account field partition, and the personal identification code ciphertext block is divided into a personal identification code field partition. Each field partition represents a group of transaction fields protected by the same field encryption subkey. For each field partition, the POS terminal performs the normalization processing on the transaction fields within that partition according to the preset field order, field length, and field format to obtain the plaintext data corresponding to that field partition. Then, a corresponding field partition random number is generated for each field partition. This random number is generated by a secure random number generator. Each partition uses an independent field partition random number, and the random number for each field partition is regenerated in each transaction session to increase the semantic security of the encryption and prevent the same plaintext from generating the same ciphertext in different partitions or different transactions. Finally, the POS terminal obtains the field encryption subkey corresponding to the field category to which the field partition belongs, and uses the field encryption subkey and the field partition random number to encrypt the plaintext data of the field partition to obtain the ciphertext of the field partition corresponding to the field category. Specifically, a symmetric encryption algorithm is used, preferably an authentication encryption algorithm with integrity protection capabilities, such as Advanced Encryption Standard-Galois / Counter Mode (AES-GCM). The field partition random number is used as the initial vector, and the field encryption subkey is used as the encryption key to encrypt the plaintext data of the field partition to generate the corresponding ciphertext of the field partition. All field categories in the current transaction data are traversed to generate the ciphertext of the field partition corresponding to each field category.

[0044] It should be noted that by partitioning and encrypting transaction data according to field categories, and generating separate field encryption subkeys for each field category, key isolation and ciphertext isolation between different field categories can be achieved. When the trust measurement result corresponding to a certain field category is abnormal, it will only affect the field trust factor and field encryption subkey corresponding to that field category, and will not cause other field categories to be affected by using the same key for their field partition ciphertext. At the same time, the field trust factor is introduced in the field encryption subkey derivation process, so that the final generated field partition ciphertext can be deeply bound to the terminal trusted operating state required by the corresponding field category.

[0045] In step S104, based on the transaction context, corresponding field encryption proof values ​​are generated according to the field trust factor and field partition ciphertext of each field category.

[0046] In some embodiments, based on the transaction context, the corresponding field encryption proof value is generated according to the field trust factor and field partition ciphertext of each field category. Specifically, this can be done in the following manner: Iterate through all field categories, and associate and match the transaction context with the field trust factor and field partition ciphertext corresponding to the current field category; The associated data is fused using a message authentication code algorithm to generate a field encryption proof value corresponding to the current field category.

[0047] The field encryption proof value is a verification value generated by performing calculations on the field identifier, field trust factor, field partition ciphertext, field partition random number, and transaction context using a cryptographic message authentication code. It is used by the backend server to verify whether the field partition ciphertext was generated in a trust state that matches the field category, preventing the ciphertext from being tampered with or replaced.

[0048] In specific implementation, firstly, each field category is traversed. For the currently traversed field category, the field identifier, field trust factor, field partition ciphertext, field partition random number, and transaction context corresponding to the current transaction session are combined according to the preset field order, field length, and field format to form a data sequence to be proved. Then, the global proof key pre-installed in the POS terminal is used as the key for the HMAC algorithm. The global proof key is pre-injected into the secure storage area of ​​the hardware root of trust by the key management system and is only used to generate field encryption proof values. Different POS terminals have different global proof keys. The data sequence is used as the input message to calculate the HMAC value, and the HMAC value is used as the field encryption proof value corresponding to the field category. Since the HMAC algorithm is collision-resistant and unforgeable, the output HMAC value can uniquely represent the integrity and authenticity of the input data sequence. Any tampering with the input data (such as field partition ciphertext, field trust factor, or transaction context) will cause the HMAC verification to fail. All field categories are traversed, and the above association matching and HMAC calculation steps are repeated for each field category to generate the field encryption proof value corresponding to each field category.

[0049] It should be noted that by using the message authentication code algorithm to associate and integrate the transaction context, field trust factor, and field partition ciphertext, a field encryption proof value with anti-counterfeiting characteristics is generated for each field category, which is then used by the backend server to complete the field legality verification.

[0050] In step S105, based on the trusted snapshot, the legality of the ciphertext of each field partition and the encryption proof value of its field are verified, and security processing is performed on the corresponding transaction fields according to the verification results.

[0051] In some embodiments, based on the trusted snapshot, the legality of the ciphertext of each field partition and the encryption proof value of its field are verified, and security measures are taken on the corresponding transaction fields according to the verification results. Specifically, the following methods can be adopted: Upload the encrypted text of each field partition and its corresponding encrypted proof value to the backend; The backend verifies the field credibility factor of each field category one by one based on the trusted snapshot, and completes the legality verification of the corresponding field encrypted proof value based on the field credibility factor that has passed the verification. When the encrypted proof value of a field corresponding to a certain field category passes the verification, it is determined that the ciphertext of the field partition of that field category is generated in an appropriate trusted state, and thus the transaction field corresponding to that field category is allowed to be recorded, stored and transferred normally. When the verification of the encrypted proof value of a field corresponding to a certain field category fails, field-level security measures are taken for the transaction field corresponding to that field category based on the security level and business dependencies of that field category.

[0052] In practice, firstly, the POS terminal encapsulates the transaction context, the trusted snapshot, the field identifiers corresponding to each field category, the field partition random number, the field partition ciphertext, and the field encryption proof value into a unified transaction security data packet and uploads it to the backend server. After receiving the transaction security data packet, the backend server prioritizes performing a two-layer integrity and legality verification on the trusted snapshot: it recalculates the HMAC of the trusted snapshot digest using the same message authentication key as the POS terminal, compares the calculation result with the trusted snapshot proof information uploaded by the terminal, and if the two are inconsistent, the trusted snapshot is deemed invalid, and the transaction is directly rejected; if they are consistent, the original trusted snapshot data and the transaction context are recalculated based on SHA-256, and compared with the uploaded trusted snapshot digest; if the digests do not match, the original snapshot data is deemed to have been tampered with, and the transaction is also rejected; after both layers of verification pass, the backend server parses the trusted measurement results of each metric item from the original trusted snapshot data. Then, a trust factor verification process is performed independently for each field category. Specifically, based on the preset security dependency metric mapping table, the set of security dependency metrics corresponding to the current field category to be verified is matched, and the target trust metric result corresponding to the field category is extracted from all the trust metric results obtained from the parsing. Subsequently, based on the extracted target trust metric result and the data in the transaction security data packet, the field trust factor of the field category is recalculated using the same combination operation method as in step S102. If the recalculated field trust factor is consistent with the field trust factor uploaded by the terminal, the verification passes; otherwise, the verification fails, and the ciphertext of the field category is directly determined to be untrustworthy.

[0053] In addition, in specific implementation, based on the successful verification of the field trust factor, the same message authentication code algorithm and global proof key as in step S104 are used to extract the field identifier, field partition ciphertext, field partition random number, and transaction context corresponding to the current field type from the transaction security data packet to complete the association matching and obtain a standard data sequence. The HMAC value is recalculated for this data sequence. The recalculated HMAC value is compared with the field encryption proof value uploaded by the POS terminal. If they match, it proves that the field partition ciphertext was generated in the trusted operating state of the terminal and that the ciphertext has not been tampered with during transmission. If they do not match, the verification fails. Finally, when the field encryption proof value verification of a certain field category passes the entire process, the transaction field corresponding to that field category is allowed to be normally recorded, stored, and transferred. At the same time, the backend server, based on the same key derivation logic as in step S103, re-derives the corresponding field encryption subkey based on the field trust factor uploaded by the terminal and the current transaction context. The legitimate subkey is used to decrypt the field partition ciphertext to obtain the complete plaintext transaction field, which is then sent to the subsequent normal business processing flow.

[0054] In practical implementation, when the encryption proof value verification of a field corresponding to a certain field category fails, the backend server performs field-level security measures on the transaction field corresponding to that field category based on the security level and business dependencies of that field category. Specifically, the backend server pre-configures a mapping table between field categories and security sensitivity levels, business dependencies, and security measures. The security sensitivity levels are categorized into high sensitivity, medium sensitivity, and low sensitivity based on the impact of the transaction field on transaction authorization and fund security. The business dependencies are used to determine whether the corresponding field category is a necessary item for transaction authorization, fund receipt, identity authentication, risk control, or log retention. Specifically, for fields such as personal identification codes, master accounts, transaction amounts, and transaction authentication... For core transaction fields with high sensitivity levels, the backend server directly rejects the transaction and returns a transaction failure response upon verification failure, while retaining security audit logs to prevent high-risk abnormal transactions from proceeding and ensure the security of core funds and identity data. For field categories with medium sensitivity levels, such as merchant terminals and communication security, the backend server can flexibly perform actions such as increasing the transaction risk level, limiting terminal transaction limits, triggering secondary authentication for users, and transferring the transaction to manual review, balancing transaction security and business continuity. For general supplementary field categories with low sensitivity levels, the backend server takes actions such as discarding abnormal field data, marking the field as abnormal, or retaining the current transaction but restricting the subsequent business flow of the abnormal field, to prevent non-core field anomalies from interfering with the overall transaction process.

[0055] It should be noted that the backend server performs dual verification of the trust factor and encrypted proof value for each field category, realizing field-level trusted collection and verifiable encryption status of POS transaction data. When a field fails to be verified, differentiated handling can be performed according to its security level, thereby accurately blocking or downgrading the abnormal field without affecting the entire transaction, improving the flexibility and reliability of transaction security processing.

[0056] Therefore, this application demonstrates that, firstly, by generating the trusted snapshot before the transaction field enters the encryption process, the true and trusted state of each key system component of the POS machine under the current transaction session can be solidified in advance, effectively avoiding the data security risks caused by directly encrypting the transaction field after it has been processed by an untrusted collection channel or abnormal system component; secondly, by combining and binding the field identifier, target trust measurement result, and transaction context, the traditional terminal trust status at the whole machine level is refined to the field-level granularity, allowing transaction fields of different security levels to match the corresponding component trust verification results according to their own business attributes and security dependencies, forming differentiated trust parameter support; simultaneously, by dynamically deriving subkeys based on the field trust factor, differentiated encryption subkeys are generated for different field categories, achieving field-level granularity encryption. Key isolation; in conjunction with the HKDF standardized key derivation mechanism, and using unique parameters for each transaction in key generation, key reuse can be effectively prevented, improving the uniqueness and anti-attack capabilities of the key system; then, by partitioning and encrypting transaction data according to field categories, and generating a field encryption subkey for each field category, key isolation and ciphertext isolation between different field categories can be achieved; finally, the backend server performs dual verification of the trust factor and encryption proof value for each field category, realizing field-level trusted collection and verifiable encryption status of POS transaction data; when a field verification fails, differentiated handling is performed according to its security level, thereby accurately blocking or downgrading abnormal fields without affecting the entire transaction, improving the flexibility and reliability of transaction security processing.

[0057] In summary, the technical solution adopted in this application can dynamically bind the trusted state of the terminal with field-level encryption to improve the precision of POS machine transaction data security protection.

[0058] Furthermore, in another aspect of this application, in some embodiments, this application provides a POS machine transaction data security processing system based on multi-dimensional feature analysis, see reference. Figure 4 The figure is a schematic diagram of the structure of a POS transaction data security processing system based on multi-dimensional feature analysis, according to some embodiments of this application. The POS transaction data security processing system based on multi-dimensional feature analysis includes: The trusted measurement module 201 is used to generate a trusted snapshot by performing a trusted measurement on the POS terminal using the hardware root of trust in response to a POS transaction request. The multidimensional feature analysis module 202 is used to perform multidimensional analysis based on the credibility measurement results, transaction context, and the field categories of transaction data, and to generate a unique field credibility factor for each field category. The partition encryption module 203 is used to generate a field encryption subkey for each field category, using the field trust factor as the key derivation factor, and to perform partition encryption on the transaction field belonging to the field category using the field encryption subkey to obtain the field partition ciphertext. The field proof calculation module 204 is used to generate corresponding field encryption proof values ​​based on the transaction context, according to the field credibility factor and field partition ciphertext of each field category. The security processing module 205 is used to verify the legality of the encrypted text of each field partition and the encrypted proof value of its fields based on the trusted snapshot, and to perform security processing on the corresponding transaction fields according to the verification results.

[0059] In addition, this application also provides a computer device, which includes a memory and a processor. The memory stores code, and the processor is configured to acquire the code and execute the above-described POS machine transaction data security processing method based on multi-dimensional feature analysis.

[0060] In some embodiments, reference Figure 5 The figure is a schematic diagram of the structure of a computer device implementing a POS transaction data security processing method based on multi-dimensional feature analysis, according to some embodiments of this application. The POS transaction data security processing method based on multi-dimensional feature analysis in the above embodiments can... Figure 5 The computer device shown is used to implement this, and the computer device includes at least one processor 301, a communication bus 302, a memory 303, and at least one communication interface 304.

[0061] The processor 301 can be a general-purpose central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more devices used to control the execution of the POS machine transaction data security processing method based on multi-dimensional feature analysis in this application.

[0062] The communication bus 302 can be used to transmit information between the aforementioned components.

[0063] The memory 303 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disks or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 303 may exist independently and be connected to the processor 301 via the communication bus 302. The memory 303 may also be integrated with the processor 301.

[0064] The memory 303 stores program code for executing the solution of this application, and its execution is controlled by the processor 301. The processor 301 executes the program code stored in the memory 303. The program code may include one or more software modules. In the above embodiments, the determination of the POS transaction data security processing method based on multi-dimensional feature analysis can be implemented by the processor 301 and one or more software modules in the program code in the memory 303.

[0065] Communication interface 304 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area network (WLAN), etc.

[0066] In a specific implementation, as one example, a computer device may include multiple processors, each of which may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0067] The aforementioned computer device can be a general-purpose computer device or a special-purpose computer device. In specific implementations, the computer device can be a desktop computer, a portable computer, a network server, a handheld digital assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. This application does not limit the type of computer device.

[0068] In addition, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described POS machine transaction data security processing method based on multi-dimensional feature analysis.

[0069] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0070] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for secure processing of POS machine transaction data based on multi-dimensional feature analysis, characterized in that, Includes the following steps: In response to a POS transaction request, the hardware root of trust performs a trust measurement on the POS terminal to generate a trust snapshot; Based on the credibility measurement results, transaction context, and the field categories of transaction data, a multi-dimensional analysis is performed to generate a unique field credibility factor for each field category. For each field category, the field trust factor is used as the key derivation factor to generate a field encryption subkey for that field category. The field encryption subkey is then used to perform partition encryption on the transaction fields belonging to that field category to obtain the field partition ciphertext. Based on the transaction context, corresponding field encryption proof values ​​are generated according to the field trust factor and field partition ciphertext of each field category. Based on the trusted snapshot, verify the legality of the encrypted partition of each field and the encrypted proof value of its field, and perform security processing on the corresponding transaction fields according to the verification results; Specifically, the process of performing multi-dimensional analysis based on trust measurement results, transaction context, and various field categories of transaction data to generate a unique field trust factor for each field category includes: determining the set of security dependency metrics corresponding to each field category; extracting a target trust measurement result that matches the set of security dependency metrics from multiple trust measurement results; combining the field identifier of the field category, the target trust measurement result, and the transaction context to generate a field trust factor uniquely corresponding to the field category; and traversing all field categories to generate the field trust factor corresponding to each field category.

2. The method as described in claim 1, characterized in that, In response to a POS transaction request, the hardware root of trust performs a trust measurement on the POS terminal to generate a trusted snapshot, specifically including: In response to a POS transaction request, obtain the transaction context corresponding to the current transaction session; The hardware root of trust performs step-by-step trust measurement on each key system component of the POS terminal according to the transmission order of the trust measurement chain, resulting in multiple trust measurement items and the trust measurement results corresponding to each trust measurement item. Based on the transaction context and the results of each trust metric, a trust snapshot bound to the current transaction session is generated.

3. The method as described in claim 1, characterized in that, For each field category, using the field trust factor as the key derivation factor, the generation of the field encryption subkey for that field category specifically includes: Obtain the pre-installed transaction root key within the POS terminal; For each field category, select multiple parameters from the field trust factor, field identifier, transaction random number, and transaction serial number of that field category to form the key derivation input parameters; The transaction root key and the key derivation input parameters are derived by using a key derivation function to obtain the field encryption subkey corresponding to the field category.

4. The method as described in claim 1, characterized in that, Using the aforementioned field encryption subkey, transaction fields belonging to that field category are partitioned and encrypted to obtain the field partition ciphertext, which specifically includes: The transaction data is divided into multiple field partitions according to field categories. Each field partition includes one or more transaction fields belonging to the same field category. Generate a corresponding random number for each field partition; Using the field encryption subkey corresponding to the field category and combining it with the field partition random number, the transaction field within the field partition is encrypted to obtain the ciphertext of the field partition corresponding to the field category.

5. The method as described in claim 1, characterized in that, Based on the transaction context, the corresponding field encryption proof values ​​are generated according to the field trust factor and field partition ciphertext for each field category, specifically including: Iterate through all field categories, and associate and match the transaction context with the field trust factor and field partition ciphertext corresponding to the current field category; The associated data is fused using a message authentication code algorithm to generate a field encryption proof value corresponding to the current field category.

6. The method as described in claim 1, characterized in that, Based on the trusted snapshot, the validity of the ciphertext of each field partition and the encryption proof value of its fields are verified, and security measures are taken for the corresponding transaction fields according to the verification results, specifically including: Upload the encrypted text of each field partition and its corresponding encrypted proof value to the backend; The backend verifies the field credibility factor of each field category one by one based on the trusted snapshot, and completes the legality verification of the corresponding field encrypted proof value based on the field credibility factor that has passed the verification. When the encrypted proof value of a field corresponding to a certain field category passes the verification, it is determined that the ciphertext of the field partition of that field category is generated in an appropriate trusted state, and thus the transaction field corresponding to that field category is allowed to be recorded, stored and transferred normally. When the verification of the encrypted proof value of a field corresponding to a certain field category fails, field-level security measures are taken for the transaction field corresponding to that field category based on the security level and business dependencies of that field category.

7. A POS transaction data security processing system based on multi-dimensional feature analysis, used to execute the POS transaction data security processing method based on multi-dimensional feature analysis as described in any one of claims 1 to 6, characterized in that, The system includes: The Trust Measurement module is used to generate a Trust Snapshot by performing a Trust Measurement on the POS terminal in response to a POS transaction request, using the hardware root of trust. The multidimensional feature analysis module is used to perform multidimensional analysis based on the credibility measurement results, transaction context, and various field categories of transaction data, and to generate a unique field credibility factor for each field category. The partition encryption module is used to generate a field encryption subkey for each field category, using the field trust factor as the key derivation factor, and to perform partition encryption on the transaction fields belonging to that field category using the field encryption subkey to obtain the field partition ciphertext. The field proof calculation module is used to generate corresponding field encryption proof values ​​based on the transaction context, according to the field credibility factor and field partition ciphertext of each field category. The security processing module is used to verify the legality of the encrypted text of each field partition and the encrypted proof value of its fields based on the trusted snapshot, and to perform security processing on the corresponding transaction fields according to the verification results.

8. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing code, and the processor being configured to acquire the code and execute the POS machine transaction data security processing method based on multi-dimensional feature analysis as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the POS machine transaction data security processing method based on multi-dimensional feature analysis as described in any one of claims 1 to 6.

Images