A wireless payment system for intelligent consumer machine and transaction protection method thereof

Abstract

This application provides a wireless payment system for smart POS terminals and its transaction protection method, relating to the field of transaction protection technology. The method involves: verifying a set of initial transaction data to obtain the privacy sensitivity of the transaction data block when a user initiates a transaction; determining the signature ciphertext information group of the transaction data when the user initiates a transaction request based on security constraints, and submitting the signature ciphertext information group to the file synchronization contract of the POS terminal during the transaction to obtain the transaction ciphertext dataset; determining the security identifier ciphertext for transaction security verification based on the transaction consensus node and privacy sensitivity, and determining the homomorphic privacy loss during the transaction; and dynamically protecting the user's transaction data during the transaction based on the transaction ciphertext dataset and the homomorphic privacy loss. This application can dynamically adapt to different transaction scenarios and privacy requirements to improve the privacy protection adaptability of transaction data in the POS terminal.

Description

Technical Field

[0001] This application relates to the field of transaction protection technology, and more specifically, to a wireless payment system for a smart POS terminal and a method for protecting transactions therein. Background Technology

[0002] Transaction protection refers to the use of technical means and strategies during the transaction process to ensure the privacy, integrity, authenticity, and security of transaction data, preventing unauthorized access, tampering, or leakage of transaction information during transmission, storage, and processing. The goal of transaction protection is to ensure that sensitive user information (such as personal identity, account data, and transaction amounts) is not stolen or tampered with by external attackers during the transaction process, while also guaranteeing the legality and transparency of the transaction. To achieve effective transaction protection, multi-layered security measures are typically employed, including: encryption algorithms to convert sensitive information into an unreadable form, ensuring that data cannot be decrypted even if intercepted; authentication and authorization mechanisms to ensure that only legally authorized users and nodes can participate in transactions; data integrity verification to verify whether data has been tampered with during transmission; and privacy protection technologies to reduce the risk of leakage and protect the personal privacy information involved in the transaction.

[0003] Existing smart POS terminals typically rely on multiple encryption technologies, authentication mechanisms, and privacy protection measures to ensure transaction security and user privacy. First, the terminal uses end-to-end encryption to protect transaction data during transmission, ensuring it is not tampered with or leaked. Common encryption technologies include symmetric and asymmetric encryption, with asymmetric encryption (such as RSA and ECDSA) commonly used for digital signatures and authentication. Second, the integrity and legitimacy of transaction data are usually verified through digital signatures and hash algorithms, ensuring data is not altered during transmission. Digital signatures use a private key to sign the transaction information, and the verifier can use the public key to verify the data's authenticity. However, existing transaction protection methods for smart consumer terminals mainly rely on static encryption and authentication mechanisms. While these mechanisms can ensure the security of transaction data transmission, they typically lack dynamic assessment and targeted protection of transaction data privacy sensitivity. The protection of transaction data privacy is too static and fails to make fine-grained real-time adjustments for different types of data and privacy risks. This leaves high-privacy-risk data at risk of privacy leakage during transactions, resulting in privacy protection measures that are neither precise nor flexible. Consequently, privacy protection measures cannot dynamically adapt to different transaction scenarios and privacy requirements. Therefore, how to dynamically adapt to different transaction scenarios and privacy needs to improve the privacy protection adaptability of transaction data in consumer terminals is a problem facing the industry. Summary of the Invention

[0004] This application provides a wireless payment system for a smart POS terminal and a transaction protection method thereof, which can dynamically adapt to different transaction scenarios and privacy requirements to improve the privacy protection adaptability of transaction data in the POS terminal.

[0005] Firstly, this application provides a transaction protection method for a smart consumer terminal, the transaction protection method comprising the following steps:

[0006] Establish data communication between the wireless payment system in the POS terminal and obtain the initial transaction data of the user when the POS terminal conducts a transaction;

[0007] Based on the initial transaction data, a set of verifications is defined to obtain the privacy sensitivity of the transaction data block when a transaction user makes a transaction.

[0008] Security constraints are obtained when exchanging transaction data in the consumer terminal. Based on the security constraints, the signature ciphertext information group of the transaction data when the transaction user initiates a transaction request is determined. The signature ciphertext information group is submitted to the file synchronization contract when the consumer terminal conducts a transaction to obtain the transaction ciphertext dataset when the consumer terminal conducts a transaction.

[0009] The transaction consensus node on the transaction data block is determined. Based on the transaction consensus node and the privacy sensitivity, the security identifier ciphertext is determined when the transaction data is used for transaction security verification. The security identifier ciphertext is then homomorphically verified to obtain the homomorphic privacy loss when the consumer machine makes a transaction.

[0010] The transaction data of the user is dynamically protected when the consumer machine conducts transactions based on the transaction ciphertext dataset and the homomorphic privacy loss.

[0011] In this embodiment, the initial transaction data refers to the set of basic information about the transaction received by the consumer from the user terminal when the transaction is initiated.

[0012] In this embodiment, the privacy sensitivity of the transaction data block when a transaction user makes a transaction is determined by verifying the set based on the initial transaction data. This specifically includes:

[0013] Select privacy-preserving numerical features from the initial transaction data;

[0014] Determine the encrypted transaction log in the transaction data block when the transaction user makes a transaction;

[0015] The privacy numerical features are categorized based on the encrypted transaction logs to obtain the privacy sensitivity of the transaction data blocks.

[0016] In this embodiment, determining the signature ciphertext information group of the transaction data when a transaction user initiates a transaction request based on the security constraints specifically includes:

[0017] The level of privacy required for verification when a user node initiates a transaction request is determined based on the aforementioned security constraints.

[0018] To obtain the privacy protection level of transaction data when a user initiates a transaction request;

[0019] The encrypted data when a user initiates a transaction request is determined based on the privacy protection level.

[0020] The signature ciphertext information group of the transaction data when the transaction user initiates a transaction request is determined based on the privacy verification level and the ciphertext data.

[0021] In this embodiment, submitting the signature ciphertext information group to the file synchronization contract when the consumer machine conducts a transaction to obtain the transaction ciphertext dataset when the consumer machine conducts a transaction specifically includes:

[0022] Obtain the file synchronization contract during transactions conducted by the consumer terminal;

[0023] The privacy balance constraints for transactions by the consumer machine are determined based on the document synchronization contract.

[0024] By performing homomorphic verification on the signature ciphertext information group using the privacy balance constraints, a transaction ciphertext dataset is obtained when the consumer machine conducts a transaction.

[0025] In this embodiment, determining the transaction consensus node on the transaction data block specifically includes:

[0026] Determine the transaction data block when the consumer machine conducts a transaction;

[0027] The transaction privacy characteristics of the transaction data are determined based on the transaction data blocks;

[0028] The transaction consensus node on the transaction data block is determined based on the transaction privacy features.

[0029] In this embodiment, the security identifier ciphertext determined when performing transaction security verification based on the transaction consensus node and the privacy sensitivity specifically includes:

[0030] The transaction data is generated based on the transaction consensus node;

[0031] The privacy sensitivity is used to determine the credibility measure during transaction security verification;

[0032] Determine the encryption verification score when performing transaction security verification on transaction data;

[0033] The security identifier ciphertext is determined based on the encrypted signature information, the trust metric, and the encrypted verification score when performing transaction security verification on the transaction data.

[0034] In this embodiment, homomorphic verification is performed on the encrypted security identifier to obtain the homomorphic privacy loss during transactions by the POS terminal, specifically including:

[0035] The homomorphic association quantity of the aircraft during the transaction is determined based on the security identifier ciphertext.

[0036] Determine the public verification information for aircraft transactions;

[0037] The homomorphic privacy loss during transactions by the consumer machine is determined by the homomorphic association quantity and the public verification information.

[0038] In this embodiment, the signature ciphertext information group refers to an information set consisting of encrypted transaction data and the corresponding digital signature.

[0039] Secondly, this application provides a wireless payment system for a smart POS terminal, used to implement a transaction protection method for the smart POS terminal, the wireless payment system comprising:

[0040] The transaction data acquisition module is used to establish data communication between the wireless payment system in the POS terminal and to acquire the initial transaction data of the user when the POS terminal conducts a transaction.

[0041] The data set verification module is used to define a set for verification based on the initial transaction data to obtain the privacy sensitivity of the transaction data block when the transaction user makes a transaction.

[0042] The encrypted information submission module is used to obtain the security constraints when exchanging transaction data in the consumer machine, determine the signature encrypted information group of the transaction data when the transaction user initiates a transaction request based on the security constraints, and submit the signature encrypted information group to the file synchronization contract when the consumer machine conducts a transaction to obtain the transaction encrypted dataset when the consumer machine conducts a transaction.

[0043] The transaction security verification module is used to determine the transaction consensus node on the transaction data block, determine the security identifier ciphertext when the transaction data is verified for transaction security based on the transaction consensus node and the privacy sensitivity, perform homomorphic verification on the security identifier ciphertext, and obtain the homomorphic privacy loss when the consumer machine conducts a transaction.

[0044] The transaction dynamic protection module is used to dynamically protect the transaction data of the user when the consumer machine conducts transactions based on the transaction encrypted dataset and the homomorphic privacy loss.

[0045] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects:

[0046] Establish data communication between the wireless payment system in the POS terminal to obtain the initial transaction data of the user when the POS terminal conducts a transaction; define a set for verification based on the initial transaction data to obtain the privacy sensitivity of the transaction data block when the user conducts a transaction; obtain the security constraints when the transaction data in the POS terminal exchanges data; determine the signature ciphertext information group of the transaction data when the user initiates a transaction request based on the security constraints; submit the signature ciphertext information group to the file synchronization contract when the POS terminal conducts a transaction to obtain the transaction ciphertext dataset when the POS terminal conducts a transaction; determine the transaction consensus node on the transaction data block; determine the security identifier ciphertext when the transaction data undergoes transaction security verification based on the transaction consensus node and the privacy sensitivity; perform homomorphic verification on the security identifier ciphertext to obtain the homomorphic privacy loss when the POS terminal conducts a transaction; and dynamically protect the transaction data of the user when the POS terminal conducts a transaction based on the transaction ciphertext dataset and the homomorphic privacy loss.

[0047] Therefore, this application effectively prevents the leakage of privacy data. Specifically, by establishing stable and secure wireless data communication, it can acquire the initial transaction data of users in real time, ensuring the complete recording of basic transaction information. By conducting privacy sensitivity assessments on transaction data, it can dynamically identify highly sensitive information, thereby providing stricter privacy protection measures for sensitive data during the transaction process and ensuring the security of highly private data throughout the entire transaction process. By formulating clear security constraints and using signed ciphertext information groups, it can ensure the integrity and confidentiality of transaction data during exchange. Simultaneously, file synchronization contracts ensure the effective synchronization and consistency of transaction data, further enhancing the security and legitimacy of transaction data. Through blockchain's transaction consensus nodes and homomorphic verification technology, it achieves intelligent verification of transaction data privacy, ensuring effective assessment of the legitimacy of privacy data without decryption, and obtaining a measure of privacy loss, thus providing a basis for dynamic protection mechanisms and optimizing privacy risk control. Through dynamic protection mechanisms, based on real-time privacy loss assessments and ciphertext datasets, it flexibly adjusts the protection strategy for transaction data, intelligently strengthening or weakening protection measures according to changes in privacy risks, ensuring that privacy data is always in an optimal protection state during the transaction process, improving transaction security and reducing the risk of privacy leakage.

[0048] In summary, the technical solution adopted in this application can dynamically adapt to different transaction scenarios and privacy requirements, thereby improving the privacy protection adaptability of transaction data in the consumer terminal. Attached Figure Description

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

[0050] Figure 1 This is a flowchart of a transaction protection method for a smart POS machine provided in this application;

[0051] Figure 2 This is a flowchart illustrating the process of determining the encrypted signature information group provided in this application;

[0052] Figure 3 This is a flowchart illustrating the process of determining the encrypted security identifier provided in this application;

[0053] Figure 4 This is a module structure diagram of the wireless payment system for a smart POS terminal provided in this application. Detailed Implementation

[0054] 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 some embodiments of this application, and not all 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.

[0055] This application provides a wireless payment system for a smart POS terminal and its transaction protection method. The core of the method is to establish data communication within the POS terminal's wireless payment system, acquire the initial transaction data of the user during a transaction, define a set for verification based on the initial transaction data, and obtain the privacy sensitivity of the transaction data block during the transaction. It then acquires security constraints for data exchange within the POS terminal, determines the signature ciphertext information group of the transaction data when the user initiates a transaction request based on the security constraints, submits the signature ciphertext information group to the file synchronization contract during the transaction, and obtains the transaction ciphertext dataset during the transaction. Next, it determines the transaction consensus node on the transaction data block, determines the security identifier ciphertext for transaction security verification based on the transaction consensus node and the privacy sensitivity, performs homomorphic verification on the security identifier ciphertext, and obtains the homomorphic privacy loss during the transaction. Finally, it dynamically protects the user's transaction data during the transaction based on the transaction ciphertext dataset and the homomorphic privacy loss. This approach can dynamically adapt to different transaction scenarios and privacy requirements, thereby improving the privacy protection adaptability of transaction data within the POS terminal.

[0056] 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 As shown, this figure is an exemplary flowchart of a transaction protection method for a smart consumer terminal according to this embodiment of the present application. The transaction protection method includes the following steps:

[0057] In step S1, data communication with the wireless payment system in the POS terminal is established to obtain the initial transaction data of the user when the POS terminal conducts a transaction.

[0058] In practical implementation, when establishing data communication for the wireless payment system within the POS terminal, the first step is to ensure that the terminal can receive the initial transaction data from the user. This process typically relies on wireless communication protocols such as NFC (Near Field Communication), Bluetooth, or Wi-Fi. Specifically, when a user initiates a payment request via a mobile device (such as a smartphone, bank card, or smartwatch), the POS terminal establishes a connection with the user's device through the corresponding wireless communication module. Taking NFC as an example, the user simply brings their device close to the POS terminal, and the terminal's NFC reader activates, receiving payment information from the user's device. This information includes the user's identity (such as a credit card number or account identifier), payment amount, transaction type, device information, and a timestamp, among other preliminary transaction data. To ensure data security and integrity, encryption technologies, such as TLS or SSL protocols, are typically used during transmission to prevent data tampering or theft. Simultaneously, the POS terminal also performs preliminary verification of the received transaction data to ensure its validity and the legitimacy of its source; details of this will not be elaborated upon here.

[0059] It should be noted that, in this application, initial transaction data refers to the set of basic information about the transaction received by the consumer from the user at the time the transaction is initiated.

[0060] In step S2, the privacy sensitivity of the transaction data block when the transaction user makes a transaction is obtained by defining a set for verification based on the initial transaction data.

[0061] In this embodiment, the privacy sensitivity of the transaction data block when a transaction user makes a transaction can be obtained by defining a set for verification based on the initial transaction data, using the following steps:

[0062] Select privacy-preserving numerical features from the initial transaction data;

[0063] Determine the encrypted transaction log in the transaction data block when the transaction user makes a transaction;

[0064] The privacy numerical features are categorized based on the encrypted transaction logs to obtain the privacy sensitivity of the transaction data blocks.

[0065] In practical implementation, the first step is to identify which data constitutes private information. This data typically includes sensitive information such as user identity, payment amount, transaction account, and bank card number. These private numerical features can be extracted from the initial transaction data using data mining and feature recognition techniques. Examples include: user identity information (such as a user's bank account, credit card number, or mobile phone number); payment amount (the amount usually contains high privacy information, especially for large payments); payment method (such as bank card, digital wallet, credit card, etc.); and transaction timestamps (although not directly private data, they may reveal user behavior patterns when combined with other data). The system identifies and extracts these numerical features using pre-defined rules or machine learning models. Then, to protect these private numerical features, the information in the transaction data needs to be encrypted. At this point, the ciphertext of the transaction log is the encrypted transaction dataset. Transaction logs typically record all the details of the transaction, including user identity, payment amount, and transaction time. During encryption, encryption algorithms (such as AES, RSA, etc.) are used to encrypt these logs to ensure data security during storage and transmission. Specifically, the system selects an appropriate encryption algorithm to encrypt the data in the transaction log based on the sensitivity of the privacy numerical features. The encrypted data, known as ciphertext, ensures that even if the data is illegally accessed, its content remains unreadable. Finally, during the generation of the ciphertext, the system categorizes and classifies this data according to the nature and sensitivity of the privacy numerical features. Typically, privacy sensitivity is divided into several levels: high-sensitivity data (e.g., user identity, bank card number, account balance); medium-sensitivity data (e.g., transaction amount, payment method); and low-sensitivity data (e.g., transaction time, device ID). The system analyzes the encrypted ciphertext and, combined with the classification rules of the privacy numerical features, categorizes each data field in the transaction data block into different privacy sensitivity levels. This process may utilize statistical analysis, machine learning, and other techniques, dynamically adjusting based on the potential risks of the data and the usage scenario.

[0066] It should be noted that, in this application, privacy numerical features refer to information features in transaction data that may expose users' personal privacy, such as identification codes, account information, payment amounts, etc.; ciphertext transaction logs refer to ciphertext data generated after processing transaction log data through encryption algorithms, used to protect privacy information during the transaction process; privacy sensitivity refers to the degree of protection required for the privacy information contained in the transaction data. Data sensitivity is categorized into different levels, typically including high sensitivity, medium sensitivity, and low sensitivity.

[0067] In step S3, the security constraints for data exchange of transaction data in the consumer machine are obtained. Based on the security constraints, the signature ciphertext information group of the transaction data when the transaction user initiates a transaction request is determined. The signature ciphertext information group is submitted to the file synchronization contract when the consumer machine conducts a transaction to obtain the transaction ciphertext dataset when the consumer machine conducts a transaction.

[0068] In practical implementation, security constraints when exchanging transaction data from the POS terminal can be achieved in the following ways: First, before exchanging data, the POS terminal must ensure secure communication with other systems or devices. To this end, transaction data is protected using encryption protocols (such as TLS / SSL) during the exchange process. TLS encrypts the transmission channel, ensuring data is not eavesdropped on or tampered with during transmission, and verifies the identities of both communicating parties to prevent man-in-the-middle attacks. Second, for sensitive information in the transaction data, the POS terminal encrypts the data according to preset security policies. For example, highly sensitive data such as transaction amounts and user identity information are encrypted using symmetric encryption algorithms (such as AES) to ensure that even if the data is intercepted, it cannot be read by unauthorized parties. Furthermore, authentication mechanisms are also a key part of security constraints. The POS terminal verifies the identity of the transaction request initiator through digital signatures or two-factor authentication to ensure the requester is a legitimate user. For example, during payment, users may need to authenticate using a PIN code or biometrics (such as fingerprints or facial recognition). Finally, the POS terminal also restricts data exchange permissions according to access control policies, ensuring that only authorized users and systems can access or modify transaction data.

[0069] It should be noted that, in this application, security constraints refer to the rules set to ensure the confidentiality, integrity and availability of information during data exchange, storage and processing.

[0070] Preferably, in this embodiment, the signature ciphertext information group of the transaction data when the transaction user initiates a transaction request is determined according to the security constraints, with reference to... Figure 2 The diagram is a flowchart illustrating the process of determining the ciphertext information group in some embodiments of this application. In this embodiment, determining the ciphertext information group can be achieved using the following steps:

[0071] In step S31, the verification privacy level when the user node initiates a transaction request is determined according to the security constraints;

[0072] In step S32, the privacy protection level of the transaction data when the transaction user initiates a transaction request is obtained;

[0073] In step S33, the encrypted data when the user initiates a transaction request is determined according to the privacy protection level;

[0074] In step S34, the signature ciphertext information group of the transaction data when the transaction user initiates a transaction request is determined based on the verification privacy level and the ciphertext data.

[0075] In practice, the system first assesses the privacy data involved in a transaction request based on pre-defined security constraints. For example, a user's identity information might be assessed as having high privacy, while transaction time and device information might be considered low privacy. Through these security constraints, the system determines which information requires stronger verification protection. Then, based on the initial transaction data provided by the user and the determined verification privacy level, the system further assesses the privacy protection level of the data. For example, highly sensitive data such as user identity and bank card numbers might be assigned a "high privacy protection level," while transaction time and device information might fall under a "low privacy protection level." When determining the privacy protection level, privacy protection models (such as differential privacy) might be used to ensure data privacy at different processing stages. Next, the system encrypts the transaction data. For data with a high privacy protection level, stronger encryption algorithms (such as RSA and AES) are used to encrypt the data and generate ciphertext. For example, for identity information and bank card numbers, strong encryption algorithms (such as RSA or AES-256) are used to generate ciphertext; for low-privacy data, lightweight encryption techniques or hash algorithms may be used. The goal of encryption is to ensure that even if transaction data is intercepted, unauthorized individuals cannot read the data content. Finally, after completing the encryption and privacy protection of the transaction data, the next step is to digitally sign the encrypted data, generating a signature ciphertext information set. This process includes: the system using the encrypted data and a preset private key to digitally sign the data, ensuring the integrity, origin, and non-repudiation of the transaction data; the signature information and the encrypted ciphertext data are combined to form a signature ciphertext information set, which is sent to the transaction system or target service along with the transaction request. Depending on the previously verified privacy level and privacy protection level, different levels of privacy data will use different signature algorithms and encryption strengths. For example, signing high-privacy data may use stronger encryption algorithms and more complex signature mechanisms.

[0076] It should be noted that, in this application, verification privacy level refers to determining the required strength of privacy protection and verification based on the privacy sensitivity of the data during the transaction process. A higher verification privacy level requires more stringent encryption and verification measures; privacy protection level refers to the strength and method of data protection set according to the sensitivity of the data and legal and compliance requirements; ciphertext data refers to the result of encrypting the original transaction data using an encryption algorithm, and only authorized parties holding the corresponding decryption key can access the original data; the signature ciphertext information group refers to the information set composed of the encrypted transaction data and the corresponding digital signature, used to ensure that the data is not tampered with during transmission and to prove its legality and integrity.

[0077] In this embodiment, submitting the signature ciphertext information group to the file synchronization contract when the consumer machine conducts a transaction, and obtaining the transaction ciphertext dataset when the consumer machine conducts a transaction, can be achieved through the following steps:

[0078] Obtain the file synchronization contract during transactions conducted by the consumer terminal;

[0079] The privacy balance constraints for transactions by the consumer machine are determined based on the document synchronization contract.

[0080] By performing homomorphic verification on the signature ciphertext information group using the privacy balance constraints, a transaction ciphertext dataset is obtained when the consumer machine conducts a transaction.

[0081] In practical implementation, firstly, during the transaction process, a clear agreement or contract is needed between the consumer terminal and other systems to ensure the synchronization and consistency of data exchange. This file synchronization contract is defined by the transaction system or payment platform, specifying how to handle the exchange, encryption, synchronization, and related privacy protection requirements of transaction data. Specifically, when a transaction request arrives at the consumer terminal, it automatically obtains the file synchronization contract related to the current transaction according to system settings or the transaction agreement. This contract typically includes how to handle privacy data, the encryption method for transaction data, transmission specifications, and data synchronization rules. The file synchronization contract is a "contract" between the two parties in the data exchange, ensuring the security and consistency of transaction data during transmission. Then, based on the obtained file synchronization contract, the consumer terminal determines the privacy protection requirements and related privacy balance constraints for the transaction data according to its terms. Privacy balance constraints mainly refer to how to allow the effective exchange of transaction data between systems while ensuring data privacy. Specifically, the file synchronization contract defines a privacy balance mechanism, which sets privacy constraints based on the balance between the privacy protection requirements of transaction data and the operability of transaction operations. For example, highly sensitive data may require strict regulations on encryption strength, access permissions, and verification measures. The consumer device will implement specific data protection strategies based on these privacy constraints to ensure that unnecessary privacy information is not leaked while guaranteeing the smooth operation of transactions. Finally, homomorphic encryption allows computation on encrypted data while maintaining its privacy. For example, the consumer device can verify whether the data is consistent with the original data and has not been tampered with without decrypting the signature ciphertext. During homomorphic verification, the consumer device will apply privacy constraints to ensure that the verification process meets privacy protection requirements. If the privacy protection level is high, a stronger homomorphic encryption scheme may be used to ensure that sensitive information is not leaked during transaction data processing. After homomorphic verification is completed, the consumer device will obtain a verified transaction ciphertext dataset, which contains the verified and encrypted data.

[0082] It should be noted that, in this application, the file synchronization contract refers to a set of protocols or rules that define how to synchronize and handle the privacy, encryption, and decryption requirements of transaction data during the data exchange process, ensuring the correct and secure exchange of transaction data; privacy balance constraints refer to strategies that ensure data privacy is protected during the transaction data exchange process without excessively affecting system performance or the smooth progress of transactions; and the transaction encrypted dataset.

[0083] In step S4, the transaction consensus node on the transaction data block is determined, and the security identifier ciphertext for transaction security verification is determined based on the transaction consensus node and the privacy sensitivity. Homomorphic verification is performed on the security identifier ciphertext to obtain the homomorphic privacy loss when the consumer machine conducts the transaction.

[0084] In this embodiment, determining the transaction consensus node on the transaction data block can be achieved through the following steps:

[0085] Determine the transaction data block when the consumer machine conducts a transaction;

[0086] The transaction privacy characteristics of the transaction data are determined based on the transaction data blocks;

[0087] The transaction consensus node on the transaction data block is determined based on the transaction privacy features.

[0088] In practice, firstly, during the transaction process, the transaction data generated by the POS terminal is organized into a transaction data block. This block is a collection of data containing all the key information of the transaction, including user identity, payment amount, payment time, transaction status, and transaction device information. The transaction data block is the basic unit of data in the entire transaction process, including: when a user initiates a transaction request and completes payment, the POS terminal collects transaction information from the transaction data source (such as payment terminal, banking system, etc.) and organizes it into a data block. This information includes, but is not limited to, transaction ID, user account, amount, payment method, timestamp, etc.; the transaction data block needs to be encrypted and signed to ensure the confidentiality and integrity of its data. The encrypted transaction data block can be securely transmitted and stored between the POS terminal and other systems. Then, after determining the transaction data block, the POS terminal needs to analyze and extract the privacy information in the data block to determine the transaction privacy characteristics of the data. These privacy characteristics refer to the parts of the transaction data that may expose user privacy, such as: user identity information (such as account number, credit card number, etc.);

[0089] Payment amount (large payments may reveal a user's financial situation); transaction timestamp (transaction time can reflect user behavior patterns); payment device information (device model, IP address, etc., may reveal user device characteristics). Finally, if the transaction data involves highly sensitive privacy features (such as user identity, transaction amount, etc.), the system may select a consensus node with higher privileges to process this data; if the privacy features are relatively simple and the privacy requirements of the transaction data are low, nodes with lower privileges can participate in the consensus. The selection of transaction consensus nodes can be dynamically adjusted through an evaluation algorithm based on privacy features. For example, in large-scale transactions, transaction privacy features may involve the consensus of multiple nodes to ensure data security and accuracy. Consensus nodes are responsible for verifying the legality of the transaction, completing encryption verification, and ensuring that the data has not been tampered with.

[0090] It should be noted that, in this application, a transaction data block refers to a data unit that packages and encrypts transaction-related information (such as transaction amount, user identity, timestamp, etc.) during the transaction process. It is often used in blockchain and encrypted transaction systems to represent a complete transaction; transaction privacy features refer to features or attributes in transaction data that may expose user privacy, such as identity information, transaction amount, payment method, etc.; transaction consensus nodes refer to the key points in a blockchain or decentralized network responsible for verifying transaction data.

[0091] Preferably, in this embodiment, the security identifier ciphertext is determined based on the transaction consensus node and the privacy sensitivity when performing transaction security verification on the transaction data, with reference to... Figure 3 The diagram is a flowchart illustrating the process of determining the ciphertext of the security identifier in some embodiments of this application. In this embodiment, determining the ciphertext of the security identifier can be achieved through the following steps:

[0092] In step S41, encrypted signature information of the transaction data is generated according to the transaction consensus node;

[0093] In step S42, the trust measure for transaction security verification is determined by the privacy sensitivity.

[0094] In step S43, the encryption verification score is determined when the transaction data undergoes transaction security verification;

[0095] In step S44, the security identifier ciphertext for transaction security verification is determined based on the encrypted signature information, the trust metric, and the encrypted verification score.

[0096] In practice, firstly, consensus nodes digitally sign the transaction data using their private keys. Signing is an encryption operation on the transaction data content (including transaction amount, transaction time, user information, etc.), ensuring the data has not been tampered with and originates from a legitimate node. Digital signatures verify the integrity and authenticity of the transaction data. After signing, the generated encrypted signature information is sent to downstream systems along with the transaction data for subsequent verification and validation. For example, RSA or ECDSA algorithms can be used to generate the signature, where the data is hashed and then encrypted, and the signature is appended to the transaction data block. The signature information ensures the immutability and legitimate origin of the transaction data; next, its privacy sensitivity is assessed based on the privacy characteristics of the transaction data (such as user identity information, transaction amount, etc.). Highly sensitive data (such as identity information and account information) will receive a higher privacy sensitivity assessment. Based on this sensitivity, the system assigns a corresponding trust metric to the transaction data. For example, the trust metric can be implemented using a scoring system; a trust metric of 0.9 might be used for highly sensitive information, while a trust metric of 0.5 might be used for ordinary transaction data. Then, the transaction data verification score is calculated by weighting factors such as the encrypted signature, privacy sensitivity, transaction amount, and transaction time. For example, sensitive data (such as account numbers and identity information) may be given a higher weight to improve the verification score. The purpose of the verification score is to ensure that the security verification process relies not only on the encrypted signature but also on a comprehensive consideration of privacy protection and data integrity. A higher score indicates higher security and privacy protection requirements for the transaction data. Finally, the system encrypts the encrypted signature, trust metric, and verification score using an encryption algorithm to generate the final secure identifier ciphertext. This ciphertext will serve as a security label for the transaction data and as a basis for verification during the transaction verification process. The security label ciphertext typically includes information such as the encrypted signature of the transaction data, the indication of privacy sensitivity, and the verification score, ensuring that the authenticity and privacy requirements of the data can be handled simultaneously during transaction verification.

[0097] It should be noted that, in this application, the encrypted signature information refers to a digital signature generated using encryption algorithms (such as RSA and ECDSA), which proves the legitimacy and tamper-proof nature of the transaction data. The encrypted signature relies on the signer's private key; only nodes possessing the corresponding public key can verify the signature's validity. The trust metric is a standard used to measure the authenticity and security of transaction data during the transaction data security verification process. The trust metric is determined based on privacy sensitivity and security requirements, reflecting the data's confidentiality and verification requirements. The encryption verification score is a verification value calculated by comprehensively evaluating factors such as the encrypted signature, privacy sensitivity, and trust metric of the transaction data. This score is used to assess the security and verification requirements of the transaction data. The security identifier ciphertext represents the security identifier of the transaction data during the transaction verification process; this ciphertext is used to verify the data's integrity, legitimacy, and privacy protection requirements.

[0098] In this embodiment, homomorphic verification of the security identifier ciphertext to obtain the homomorphic privacy loss during transactions by the POS terminal can be achieved through the following steps:

[0099] The homomorphic association quantity of the aircraft during the transaction is determined based on the security identifier ciphertext.

[0100] Determine the public verification information for aircraft transactions;

[0101] The homomorphic privacy loss during transactions by the consumer machine is determined by the homomorphic association quantity and the public verification information.

[0102] In practical implementation, firstly, the consumer extracts encrypted transaction data signature information, privacy features, verification scores, and other content from the secure identifier ciphertext. This encrypted information contains key features of the transaction data without directly exposing any privacy data. The homomorphic correlation coefficient is a measure or identifier of the encrypted portion of the transaction data related to privacy information. Under the homomorphic encryption framework, the consumer determines which encrypted information is closely related to privacy data through operations on the encrypted data. This information constitutes the "homomorphic correlation coefficient." Then, public verification information typically includes basic transaction information such as transaction timestamps, payment methods, and merchant information, which do not involve any user privacy. The consumer obtains this public information by accessing transaction data blocks and blockchain systems. In the homomorphic encryption process, the public key is often used for verification. The consumer verifies the encrypted data using the public key associated with the transaction data to ensure the data's legitimacy. Finally, the consumer assesses the risk of privacy information leakage during the homomorphic encryption process by comparing the homomorphic correlation coefficient and the public verification information. For example, if a certain encrypted field is overused during verification, it may lead to the risk of privacy leakage, thereby increasing privacy losses. Based on homomorphic encryption technology, the consumer machine can calculate different levels of privacy loss. For example, the leakage of privacy information may manifest as the exposure of correlations in encrypted data during processing, or the leakage of part of the original data through multiple verifications; through calculation, the consumer machine obtains a measure of privacy loss, namely homomorphic privacy loss.

[0103] It should be noted that, in this application, homomorphic correlation refers to a measure used to assess the correlation between encrypted data within a homomorphic encryption framework. It represents the relationship between encrypted data and privacy information, enabling the assessment of the impact on privacy information without decrypting the data. Public verification information refers to information that can be publicly accessed and used during transaction verification. This information typically does not involve sensitive data but can be used to verify the compliance, legality, or other non-privacy attributes of a transaction. Homomorphic privacy loss refers to the degree of privacy data leakage caused by verification operations during homomorphic encryption. It measures the risk and loss of privacy information exposure during encryption.

[0104] In step S5, the transaction data of the user is dynamically protected when the consumer machine makes a transaction based on the transaction ciphertext dataset and the homomorphic privacy loss.

[0105] In practice, the consumer first needs to parse and process the encrypted transaction datasets, which consist of encrypted signature information, encrypted transaction logs, and privacy protection levels. Each transaction dataset contains sensitive information about the transaction user (such as account information and transaction amount), and this data is protected using homomorphic encryption. The consumer analyzes each encrypted element in the encrypted dataset to identify the type and sensitivity of the privacy information. For example, some transaction data may involve high-privacy features (such as user identity and payment method), while others may be more general. Next, the consumer assesses the privacy protection requirements of the transaction data based on the homomorphic privacy loss calculation results. If the privacy loss is high, it indicates a greater risk of privacy leakage during the transaction process, and the system needs to take stricter protection measures; conversely, if the privacy loss is low, the protection measures can be appropriately relaxed. For example, if the homomorphic privacy loss of a certain data field is high during the transaction process, the consumer may need to increase the encryption strength of that field or choose not to disclose that data. Then, based on the analysis of the encrypted transaction dataset and the assessment of privacy losses, the consumer machine will dynamically adjust its privacy protection strategy. Specifically, for data with high privacy risks, the consumer machine can restrict data transmission and disclosure, sharing data only when necessary and with minimal intervention. To further protect sensitive information, the consumer machine may use privacy masking techniques, such as data anonymization or desensitization, to transform sensitive data into an unidentifiable form, preventing information leakage. Finally, during the transaction, the consumer machine will monitor the privacy protection effectiveness of the transaction data in real time. If a potential privacy leakage risk is detected during transaction execution (such as abnormal changes in encrypted data), the consumer machine will dynamically adjust its protection measures. For example, by implementing a real-time risk assessment system, the consumer machine can adjust the encryption strength or take other protective measures in a timely manner based on changes in current privacy losses, ensuring that the transaction data remains highly protected throughout the entire transaction process. Further details are omitted here.

[0106] Therefore, this application effectively prevents the leakage of privacy data. Specifically, by establishing stable and secure wireless data communication, it can acquire the initial transaction data of users in real time, ensuring the complete recording of basic transaction information. By conducting privacy sensitivity assessments on transaction data, it can dynamically identify highly sensitive information, thereby providing stricter privacy protection measures for sensitive data during the transaction process and ensuring the security of highly private data throughout the entire transaction process. By formulating clear security constraints and using signed ciphertext information groups, it can ensure the integrity and confidentiality of transaction data during exchange. Simultaneously, file synchronization contracts ensure the effective synchronization and consistency of transaction data, further enhancing the security and legitimacy of transaction data. Through blockchain's transaction consensus nodes and homomorphic verification technology, it achieves intelligent verification of transaction data privacy, ensuring effective assessment of the legitimacy of privacy data without decryption, and obtaining a measure of privacy loss, thus providing a basis for dynamic protection mechanisms and optimizing privacy risk control. Through dynamic protection mechanisms, based on real-time privacy loss assessments and ciphertext datasets, it flexibly adjusts the protection strategy for transaction data, intelligently strengthening or weakening protection measures according to changes in privacy risks, ensuring that privacy data is always in an optimal protection state during the transaction process, improving transaction security and reducing the risk of privacy leakage.

[0107] In summary, the technical solution adopted in this application can dynamically adapt to different transaction scenarios and privacy requirements, thereby improving the privacy protection adaptability of transaction data in the consumer terminal.

[0108] This application provides a wireless payment system for a smart POS terminal, with reference to... Figure 4 As shown in the figure, this is a schematic diagram of a wireless payment system for a smart POS terminal according to this embodiment of the present application. The wireless payment system includes:

[0109] The transaction data acquisition module 100 is used to establish data communication between the wireless payment system in the POS terminal and to acquire the initial transaction data of the user when the POS terminal makes a transaction.

[0110] The data set verification module 200 is used to define a set for verification based on the initial transaction data to obtain the privacy sensitivity of the transaction data block when the transaction user makes a transaction.

[0111] The encrypted information submission module 300 is used to obtain the security constraints when exchanging transaction data in the consumer machine, determine the signature encrypted information group of the transaction data when the transaction user initiates a transaction request according to the security constraints, and submit the signature encrypted information group to the file synchronization contract when the consumer machine conducts a transaction to obtain the transaction encrypted dataset when the consumer machine conducts a transaction.

[0112] The transaction security verification module 400 is used to determine the transaction consensus node on the transaction data block, determine the security identifier ciphertext when the transaction data is used for transaction security verification based on the transaction consensus node and the privacy sensitivity, perform homomorphic verification on the security identifier ciphertext, and obtain the homomorphic privacy loss when the consumer machine makes a transaction.

[0113] The transaction dynamic protection module 500 is used to dynamically protect the transaction data of the user when the consumer machine conducts a transaction based on the transaction encrypted dataset and the homomorphic privacy loss.

[0114] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0115] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0116] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

Claims

1. A transaction protection method for a smart POS machine, characterized in that, The transaction protection method includes the following steps: Establish data communication between the wireless payment system in the POS terminal and obtain the initial transaction data of the user when the POS terminal conducts a transaction; Based on the initial transaction data, a set of verifications is defined to obtain the privacy sensitivity of the transaction data block when a transaction user makes a transaction. Security constraints are obtained when exchanging transaction data in the consumer terminal. Based on the security constraints, the signature ciphertext information group of the transaction data when the transaction user initiates a transaction request is determined. The signature ciphertext information group is submitted to the file synchronization contract when the consumer terminal conducts a transaction to obtain the transaction ciphertext dataset when the consumer terminal conducts a transaction. The transaction consensus node on the transaction data block is determined. Based on the transaction consensus node and the privacy sensitivity, the security identifier ciphertext is determined when the transaction data is used for transaction security verification. The security identifier ciphertext is then homomorphically verified to obtain the homomorphic privacy loss when the consumer machine makes a transaction. The transaction data of the user is dynamically protected when the consumer machine conducts transactions based on the transaction ciphertext dataset and the homomorphic privacy loss.

2. The transaction protection method for a smart consumer terminal as described in claim 1, characterized in that, The initial transaction data refers to the set of basic information about the transaction received by the consumer from the user terminal when the transaction is initiated.

3. The transaction protection method for a smart consumer terminal as described in claim 1, characterized in that, Based on the initial transaction data, a set of verifications is defined to obtain the privacy sensitivity of the transaction data block when a transaction user conducts a transaction, specifically including: Select privacy-preserving numerical features from the initial transaction data; Determine the encrypted transaction log in the transaction data block when the transaction user makes a transaction; The privacy numerical features are categorized based on the encrypted transaction logs to obtain the privacy sensitivity of the transaction data blocks.

4. The transaction protection method for a smart POS machine as described in claim 1, characterized in that, According to the aforementioned security constraints, the specific ciphertext information group of the transaction data when a transaction user initiates a transaction request includes: The level of privacy required for verification when a user node initiates a transaction request is determined based on the aforementioned security constraints. To obtain the privacy protection level of transaction data when a user initiates a transaction request; The encrypted data when a user initiates a transaction request is determined based on the privacy protection level. The signature ciphertext information group of the transaction data when the transaction user initiates a transaction request is determined based on the privacy verification level and the ciphertext data.

5. The transaction protection method for a smart consumer terminal as described in claim 1, characterized in that, Submitting the ciphertext information group to the file synchronization contract during transaction processing by the consumer terminal, the resulting transaction ciphertext dataset during transaction processing by the consumer terminal specifically includes: Obtain the file synchronization contract during transactions from the consumer terminal; The privacy balance constraints when the consumer machine conducts transactions are determined based on the document synchronization contract. By performing homomorphic verification on the signature ciphertext information group using the privacy balance constraints, a transaction ciphertext dataset is obtained when the consumer machine conducts a transaction.

6. The transaction protection method for a smart consumer terminal as described in claim 1, characterized in that, The specific nodes for determining the transaction consensus on the transaction data block include: Determine the transaction data block when the consumer machine conducts a transaction; The transaction privacy characteristics of the transaction data are determined based on the transaction data blocks; The transaction consensus node on the transaction data block is determined based on the transaction privacy features.

7. The transaction protection method for a smart consumer terminal as described in claim 1, characterized in that, The security identifier ciphertext used to perform transaction security verification based on the transaction consensus node and the privacy sensitivity specifically includes: The transaction data is generated based on the transaction consensus node; The privacy sensitivity is used to determine the credibility measure during transaction security verification; Determine the encryption verification score when performing transaction security verification on transaction data; The security identifier ciphertext is determined based on the encrypted signature information, the trust metric, and the encrypted verification score when performing transaction security verification on the transaction data.

8. The transaction protection method for a smart POS machine as described in claim 1, characterized in that, Homomorphic verification of the security identifier ciphertext reveals the specific homomorphic privacy loss during transactions by the POS terminal, including: The homomorphic association quantity of the aircraft during the transaction is determined based on the security identifier ciphertext. Determine the public verification information for aircraft transactions; The homomorphic privacy loss during transactions by the consumer machine is determined by the homomorphic association quantity and the public verification information.

9. A transaction protection method for a smart consumer terminal as described in claim 1, characterized in that, The ciphertext information group refers to the information set consisting of encrypted transaction data and the corresponding digital signature.

10. A wireless payment system for a smart POS terminal, used to execute a transaction protection method for a smart POS terminal as described in any one of claims 1 to 9, characterized in that, The wireless payment system includes: The transaction data acquisition module is used to establish data communication between the wireless payment system in the POS terminal and to acquire the initial transaction data of the user when the POS terminal conducts a transaction. The data set verification module is used to define a set for verification based on the initial transaction data to obtain the privacy sensitivity of the transaction data block when the transaction user makes a transaction. The encrypted information submission module is used to obtain the security constraints when exchanging transaction data in the consumer machine, determine the signature encrypted information group of the transaction data when the transaction user initiates a transaction request based on the security constraints, and submit the signature encrypted information group to the file synchronization contract when the consumer machine conducts a transaction to obtain the transaction encrypted dataset when the consumer machine conducts a transaction. The transaction security verification module is used to determine the transaction consensus node on the transaction data block, determine the security identifier ciphertext when the transaction data is verified for transaction security based on the transaction consensus node and the privacy sensitivity, perform homomorphic verification on the security identifier ciphertext, and obtain the homomorphic privacy loss when the consumer machine conducts a transaction. The transaction dynamic protection module is used to dynamically protect the transaction data of the user when the consumer machine conducts transactions based on the transaction encrypted dataset and the homomorphic privacy loss.

Images