Financial form data processing method and system based on block chain and storage medium

Abstract

The invention discloses a financial form data processing method and system based on a block chain, and a storage medium. The method comprises the following steps: receiving an access request of external equipment; the general storage server sends the access request to a permission server for identity verification and authorization; after authorization, the authority server sends the request to a secure storage server to obtain required data; the secure storage server sends the encrypted sensitive data to a verification server for verification; the security storage server sends the sensitive data to a security processing server for desensitization processing; the secure storage server combines the desensitized data with the non-sensitive data; and the secure storage server sends the merged data set back to the general storage server, and the general storage server sends the financial form data as a response to the external equipment. According to the invention, data security and user privacy are effectively protected, data processing efficiency is improved, dynamic risk assessment and access control are realized, and good expandability is achieved.

Description

Technical Field

[0001] This invention belongs to the field of financial data processing technology, and in particular relates to a blockchain-based financial form data processing method, system, and storage medium. Background Technology

[0002] In the financial industry, form data processing involves numerous stages, including data storage, data access, data transmission, and data processing. To ensure data security and protect user privacy, financial institutions need to implement appropriate security measures at each stage. However, existing technologies have some problems and limitations that may lead to threats to data security or violations of user privacy.

[0003] Traditional authentication methods, such as usernames and passwords, are vulnerable to various security threats, such as dictionary attacks and credential stuffing attacks. While multi-factor authentication technology is employed, it may still be insufficient to prevent malicious access in certain situations. Furthermore, existing technologies are relatively simple in terms of authorization management, potentially leading to the leakage or abuse of permissions. For financial form data, this could mean that unauthorized devices or individuals could access and use sensitive data. Additionally, failure to distinguish between sensitive and non-sensitive data during data processing can reduce processing efficiency and increase costs. Moreover, sensitive data needs to be anonymized to protect user privacy. However, existing anonymization techniques may not adequately protect user privacy and could even degrade data quality. In some cases, using overly simplistic anonymization methods can render data worthless and unable to meet business needs.

[0004] Furthermore, many existing technologies rely on static access control policies, which may result in some high-risk access behaviors not being identified and blocked in a timely manner. At the same time, existing risk assessment methods may not comprehensively consider multiple risk factors, leading to inaccurate risk assessments of access behaviors. These issues could expose financial form data to higher security risks.

[0005] Therefore, it is necessary to propose an improved method for processing financial form data, addressing the problems and limitations of existing technologies. This method should employ stricter measures for authentication and authorization, ensuring that only legitimate devices and users can access financial form data. Simultaneously, different processing strategies should be adopted for sensitive and non-sensitive data to protect data security and user privacy. Furthermore, while protecting user privacy, it is essential to preserve the actual value of the data as much as possible. Dynamic access control policies should be implemented in access control and risk assessment to promptly identify and block high-risk access behaviors, thereby protecting the security of financial form data. Summary of the Invention

[0006] To address the shortcomings of the existing technologies, this invention provides a blockchain-based method for processing financial form data, the method comprising:

[0007] When an external device sends an access request to financial form data, the general storage server receives the request.

[0008] The general storage server sends the access request to the authorization server for authentication and authorization;

[0009] The permission server checks the credentials of the external device and determines whether to allow access to the requested data based on predefined roles and permissions;

[0010] If the access request is authorized, the permission server will send the request to the secure storage server to obtain the required data;

[0011] The secure storage server extracts sensitive and non-sensitive data according to the request type, and the secure storage server sends encrypted sensitive data to the verification server for verification.

[0012] The verification server uses homomorphic encryption to verify the authenticity of the encrypted sensitive data without decrypting the data;

[0013] After verification, the secure storage server sends the sensitive data to the secure processing server for de-identification.

[0014] The secure processing server uses differential privacy and data masking techniques to process sensitive data, generate de-identified data, and send it to the secure storage server.

[0015] The secure storage server merges the desensitized data with the non-sensitive data to form a complete dataset.

[0016] The secure storage server sends the merged dataset back to the general storage server, which then sends the financial form data as a response to the external device.

[0017] In scenarios involving single or occasional access requests, the general storage server sends the access request to the authorization server for authentication and authorization. The authorization server then generates an access token based on the user's permissions. This token contains the range of data that the user can access and the type of operation, and sends the token to an external device.

[0018] Among them, a multi-layered blockchain structure is used to control and manage external devices and access requests;

[0019] The multi-layered blockchain structure includes a main chain and multiple sub-chains;

[0020] The plurality of subchains includes at least a permission subchain, and a plurality of subchains for external devices and general storage service servers;

[0021] In this process, multiple sub-chains are created for external devices based on different permission levels. External devices are assigned to the corresponding sub-chains according to their permissions. The sub-chains are responsible for recording data access and operation logs under their respective permissions.

[0022] When the access permissions of an external device change, the smart contract will automatically switch the device from the current subchain to another subchain. The permission subchain records and manages these subchain switching operations.

[0023] In scenarios with multiple access requests, when an external device not on the blockchain initiates an access request for financial form data, the permission server queries the external device's access permissions based on the external device's identity information. If the external device does not have access permissions, the request will be rejected.

[0024] For external devices that have passed authentication and authorization verification, the authorization server will evaluate the access request. The authorization server will assess the risk of the access request based on at least the request type, device reputation score, and access frequency.

[0025] Among them, when data interaction occurs between the secure storage server and the general storage server, zero-knowledge proof technology is used for verification.

[0026] When the secure storage server sends encrypted data to the general storage server, it includes a zero-knowledge proof. Upon receiving the encrypted data and the proof, the general storage server verifies the correctness of the proof without decrypting the data.

[0027] The permission server assesses the risk of the external device's access request based on a risk score. If the risk score in the access request is less than 0, it indicates that the external device's access request to the financial transaction report is low-risk, and the smart contract will allow the access request.

[0028] If the risk score is greater than 0, it indicates that the external device's request to access the financial transaction report is high-risk, and the smart contract will reject the access request.

[0029] The present invention also discloses a blockchain-based financial form data processing device, wherein the device is a secure storage server, an authorization server, a verification server, a secure processing server, or a general storage server, and the system is used to execute the aforementioned financial form data processing method in response to access requests from external devices.

[0030] The present invention also discloses an electronic device for processing financial form data based on blockchain. The electronic device includes a memory and a processor. The memory stores computer program code. The electronic device is used to implement the functions of the aforementioned secure storage server, authorization server, verification server, secure processing server, or general storage server.

[0031] The present invention also discloses a storage medium storing computer program code, wherein a processor executes the calculations and program code in the storage medium to realize the functions of the aforementioned secure storage server, authorization server, verification server, secure processing server or general storage server.

[0032] This invention ensures that only legitimate devices and users can access financial form data by authenticating and authorizing external devices. Furthermore, it further protects data security by encrypting sensitive data and verifying it without decryption.

[0033] This invention employs differential privacy and data masking techniques to anonymize sensitive data, aiming to protect user privacy while preserving the data's actual value as much as possible. This helps financial institutions ensure adequate protection of user privacy while meeting business needs.

[0034] This invention improves data processing efficiency by using homomorphic encryption technology to process data without decryption. Furthermore, merging anonymized data with non-sensitive data to form a complete dataset simplifies the data processing workflow and increases processing speed.

[0035] This invention implements dynamic access control policies based on predefined roles and permissions, as well as risk scoring of access requests. This helps to promptly identify and block high-risk access behaviors, protecting the security of financial form data.

[0036] This invention employs a distributed architecture consisting of a general-purpose storage server, an authorization server, a secure storage server, a verification server, and a secure processing server. This helps improve the system's scalability and maintainability, adapting to ever-increasing data processing demands.

[0037] The blockchain-based financial form data processing method of this invention effectively protects data security and user privacy, improves data processing efficiency, realizes dynamic risk assessment and access control, and has good scalability. Attached Figure Description

[0038] The above and other objects, features, and advantages of exemplary embodiments of the present disclosure will become readily apparent upon reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of the present disclosure are illustrated by way of example and not limitation, and like or corresponding reference numerals denote like or corresponding parts, wherein:

[0039] Figure 1 This is a flowchart illustrating a blockchain-based financial form data processing method according to an embodiment of the present invention. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0041] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms, and “multiple” generally includes at least two unless the context clearly indicates otherwise.

[0042] It should be understood that although the terms first, second, third, etc., may be used to describe... in the embodiments of the present invention, these... should not be limited to these terms. These terms are only used to distinguish... For example, first... may also be referred to as second... without departing from the scope of the embodiments of the present invention, and similarly, second... may also be referred to as first...

[0043] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0044] Depending on the context, the words “if” or “suppose” as used here can be interpreted as “when” or “in response to determination” or “in response to detection.” Similarly, depending on the context, the phrases “if determination” or “if detection (of the stated condition or event)” can be interpreted as “when determination” or “in response to determination” or “when detection (of the stated condition or event)” or “in response to detection (of the stated condition or event).”

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

[0046] like Figure 1 As shown, this invention discloses a blockchain-based financial form data processing method, which is an access request-based financial form data processing method, and the method includes:

[0047] Step 1. Receive access request: When an external device or service issues an access request, the general storage server receives the request.

[0048] Step 2. Authentication and Authorization: The general storage server sends the access request to the authorization server for authentication and authorization. The authorization server checks the credentials of the requesting device or user and determines whether access to the requested data is permitted based on predefined roles and permissions.

[0049] Step 3. Request Data: If the access request is authorized, the authorization server sends the request to the secure storage server to retrieve the required data. The secure storage server extracts sensitive and non-sensitive data based on the request type.

[0050] Step 4. Data Verification: Send the encrypted sensitive data from the secure storage server to the verification server for verification. The verification server uses verifiable encryption technology (such as isomorphic encryption) to verify the authenticity of the data without decryption.

[0051] Step 5. Data De-identification: The sensitive data is sent to the secure processing server for de-identification. The secure processing server uses technologies such as differential privacy and data masking to process the sensitive data and generate de-identified data.

[0052] Step 6. Data Merging: Merge the anonymized data with the non-sensitive data to form a complete dataset.

[0053] Step 7. Send Response: Send the merged dataset back to the general storage server, which then sends the data as a response to the external device or service. Ensure that encrypted channels (such as TLS / SSL) are used to secure data transmission.

[0054] By following the steps above, a method for processing financial form data based on access requests can be implemented, ensuring data security and privacy protection.

[0055] Optionally, the method may further include the following steps:

[0056] All access requests and operations during processing are logged for auditing and monitoring. Real-time monitoring of the data processing flow can be achieved using a Security Information and Event Management (SIEM) system.

[0057] Furthermore, in the event of any abnormal situation during the process (such as unauthorized access, data breaches, etc.), appropriate security measures should be taken immediately, such as suspending access and notifying relevant personnel to conduct an investigation.

[0058] In the back-end system for financial form data processing, five key devices are involved in data processing and storage, namely:

[0059] (1) Secure Storage Server: Sensitive and non-sensitive data are stored separately, for example, using different database tables, schemas, or partitions. All data stored on the secure storage server is encrypted to ensure data security. Simultaneously, communication between the secure storage server and other servers is ensured to be conducted through encrypted channels (e.g., using TLS / SSL).

[0060] (2) Permission server: Responsible for managing and allocating access permissions for different devices and users. Role-based access control (RBAC) policies can be used to initially restrict access permissions for different devices to data; and a sub-chain can be created on the permission server to record and manage device permissions, role assignments and access policies. The permission sub-chain is also responsible for recording device sub-chain switching operations.

[0061] (3) Verification Server: When processing sensitive data, verifiable encryption technology (such as isomorphic encryption) is used to verify the authenticity of the data without decryption. Ensure that communication between the verification server and other servers is conducted through encrypted channels.

[0062] (4) Secure Processing Server: Sensitive data is anonymized before being sent to the general storage server, for example, using differential privacy, data masking, or other technologies. Ensure that communication between the secure processing server and other servers is conducted through encrypted channels.

[0063] (5) General-purpose storage server: Stores non-sensitive data and anonymized data in response to external requests. When sending data to external devices or services, it uses encrypted channels (such as TLS / SSL) to ensure the security of data transmission.

[0064] In one embodiment, the present invention also discloses a financial form data processing method, which is a financial form data processing method based on a single access request application scenario (or an occasional access request application scenario), the method comprising:

[0065] Step s1: The external device sends an access request to the authorization server, and the authorization server verifies the user's validity.

[0066] Step s2: The permission server generates an access token based on the user's permissions. The token contains the range of data that the user can access and the types of operations that can be performed. The token is then sent to the external device.

[0067] Step s3: The external device uses an access token to initiate a data access request to the general storage server. The storage server forwards the access token to the authorization server to verify the token's validity and authorization scope.

[0068] Step s4: The authorization server verifies the access token, confirming the user's permission scope and validity. If the verification passes, the authorization server returns the authorization result to the general storage server.

[0069] Step s5: Based on the verification result from the authorization server, the general storage server requests the corresponding data from the secure storage server. The secure storage server processes the data according to the request type and authorization scope. For sensitive data, the secure storage server sends the encrypted data to the verification server for financial verification. The verification server uses homomorphic encryption technology to perform verification without decrypting the data.

[0070] Step s6: For sensitive data, the secure storage server sends the encrypted data to the secure processing server for de-identification. The secure processing server uses techniques such as differential privacy and data masking to process the sensitive data and generate de-identified data.

[0071] Step s7: The secure storage server sends the processed data (including non-sensitive data and de-identified data) back to the general storage server. The general storage server then sends the data as a response to the external device. Ensure that encrypted channels (such as TLS / SSL) are used to securely transmit data during this process.

[0072] Step s8: Regularly use zero-knowledge proofs (ZKP) to conduct spot checks on the data security of general-purpose storage servers and external devices to reduce the risk of sensitive data modification and leakage.

[0073] Furthermore, the process can also be used for requests to access data from external devices that do not have on-chain permissions. These external devices can only request data access by issuing tokens through a single access request permission server.

[0074] The method of this invention can ensure the security of sensitive information throughout the entire financial form data processing process, while using zero-knowledge proofs to improve the reliability and transparency of the system.

[0075] In one embodiment, the present invention also discloses a blockchain-based financial form data processing method, wherein the financial form data processing method is a financial form data processing method based on a high-frequency access request application scenario, and the method includes:

[0076] When an external device not on the blockchain initiates an access request to financial form data, the following steps are taken to respond to the request, add the device to the blockchain, or deny the access request:

[0077] Step a1: The external device provides valid identity credentials, including digital certificates and API keys, to authenticate the external device.

[0078] Step a2: The access control server checks the external device's access permissions based on its identity information. If the device does not have access permissions, the request will be rejected.

[0079] Step a3: For external devices that have passed authentication and authorization verification, the authorization server will evaluate the request. The evaluation may consider factors such as request type, device reputation score, and access frequency. If the evaluation is deemed reasonable, the request will continue to be processed; otherwise, the request will be rejected.

[0080] Step a4: If the request is accepted, the permission server adds the external device to the corresponding permission sub-chain with the general storage server. A smart contract is used to write the relevant information and permission level of the external device onto the chain, making the external device part of the chain and allowing it to access data within its corresponding permission scope. Multiple sub-chains exist between the external device and the general storage server; the smart contract determines the corresponding sub-chain for the external device based on predefined roles and permissions.

[0081] Step a5: External devices can query non-sensitive data and de-identified data on the general storage sub-chain according to their permissions. For requests for sensitive data, the security processing server will de-identify the data according to the permissions of the external device.

[0082] Step a6: When an external device requests data, the verification server uses homomorphic encryption technology to perform financial verification on the encrypted sensitive data in the secure storage server to ensure the authenticity of the data.

[0083] Step a7: Send the query results or anonymized data back to the external device to complete the request processing.

[0084] Furthermore, the process can also be used for requests to access devices with on-chain permissions on the external device.

[0085] In the above method, only devices that have undergone identity verification and authorization checks can access the data in the system. Furthermore, by utilizing a multi-layered blockchain structure and smart contract technology, device access permissions can be dynamically managed, and operation logs can be recorded, thereby ensuring data security and transparency.

[0086] In one embodiment, the present invention also discloses a blockchain-based financial form data processing method, wherein the financial form data processing method is a financial form data processing method based on a high-frequency access request application scenario, and the method includes:

[0087] When an external device already on the chain initiates an access request, respond to the request according to the following steps:

[0088] Step b1: When an external device initiates a request, the permission server queries the device's access permissions from the corresponding permission subchain based on the external device's identity information. If the device does not have access permissions, the request will be rejected.

[0089] Step b2: For external devices that have passed authentication and authorization verification, the authorization server will evaluate the request. The evaluation may consider factors such as request type, device reputation score, and access frequency. If the evaluation is deemed reasonable, the request will continue to be processed; otherwise, the request will be rejected.

[0090] Step b3: External devices can query non-sensitive and anonymized data on the general storage subchain according to their permissions. For requests for sensitive data, the security processing server will anonymize the data according to the device's permissions.

[0091] Step b4: When an external device requests data, the verification server uses homomorphic encryption technology to perform financial verification on the encrypted sensitive data in the secure storage server to ensure the authenticity of the data.

[0092] Step b6: Send the query results or anonymized data back to the external device to complete the request processing.

[0093] In the above method, only devices that have undergone identity verification and authorization checks can access the data in the system. Furthermore, by utilizing a multi-layered blockchain structure and smart contract technology, device access permissions can be dynamically managed, and operation logs can be recorded, thereby ensuring data security and transparency.

[0094] Furthermore, the process can also be used for requests to access devices with on-chain permissions on the external device.

[0095] In one embodiment, a multi-layered blockchain structure is used to provide finer-grained control and management of external devices and access requests. This multi-layered blockchain structure includes a main chain and multiple sub-chains.

[0096] Main chain:

[0097] Create a main chain to store global data and operation records. The main chain can use either Proof-of-Authority (PoA) or Delegated Proof-of-Authority (DPoA) consensus mechanisms. The main chain is primarily responsible for coordinating the operation of all sub-chains.

[0098] Multiple subchains include the following parts:

[0099] Permission subchain: Creates a subchain for the permission server, responsible for recording and managing device permissions, role assignments, and access policies. The permission subchain is also responsible for recording device subchain switching operations.

[0100] Verification Subchain: A subchain is created for the verification server to record data authenticity verification operations. The verification subchain uses homomorphic encryption technology to perform financial verification on encrypted sensitive data on the verification server.

[0101] Secure Processing Subchain: A subchain is created for the secure processing server to record data anonymization and privacy protection processing operations. The secure processing subchain can use techniques such as differential privacy and data masking to process sensitive data.

[0102] Secure Storage Subchain: A subchain is created for the secure storage server to record the storage, update, and query operations of sensitive data. Zero-knowledge proof (ZKP) technology can be applied to ensure data privacy and security.

[0103] General-purpose storage sub-chain: Creates a basic sub-chain for the general-purpose storage server to record non-sensitive data and anonymized data storage, update, and query operations. The general-purpose storage sub-chain can interact with external devices to send non-sensitive data and anonymized data to the outside world.

[0104] External devices and general storage server sub-chains: Multiple sub-chains are created for external devices based on different permission levels, and each sub-chain is connected to the general storage sub-chain. External devices are assigned to the appropriate sub-chain according to their permissions. These sub-chains are responsible for recording data access and operation logs under their respective permissions.

[0105] When a device’s reputation score or access permissions change, the smart contract will automatically switch the device from the current subchain to another subchain. The permission subchain records and manages these subchain switching operations.

[0106] This involves using cross-chain technology to enable interaction between the main chain and sub-chains, utilizing sidechains and the Inter-Chain Message Passing Protocol (ICMP). This ensures global data consistency and enables collaborative processing between devices. Each sub-chain executes corresponding data processing tasks and writes the results into blocks. Different consensus mechanisms are used to meet the needs of different devices and tasks.

[0107] By backing up data from both the main chain and sub-chains to secure storage devices, the system's durability and stability are ensured. In the event of data loss or corruption, data can be recovered from the backups. Furthermore, leveraging the distributed nature of blockchain enables decentralized data storage, reducing the risk of single points of failure.

[0108] The system implements a unified access control and authentication mechanism. A blockchain-based authentication scheme (such as Decentralized Identifiers, DIDs) is used to assign a unique identifier to each device. By recording identity information on the blockchain, device and user authentication and authorization can be achieved. The blockchain identity information of each device is recorded on the permissions sub-chain, and this blockchain identity information can be generated by smart contracts (randomly or according to preset rules).

[0109] To ensure stability and security, trusted devices are selected to deploy the main chain.

[0110] The trusted device can be a secure storage server. Deploying the main chain on this device allows the use of the device's computing and storage resources to achieve consensus and data storage for the main chain. Choosing consensus mechanisms such as Proof-of-Authority (PoA) or Delegated Proof-of-Authority (DPoA) can reduce computing and communication overhead.

[0111] The trusted device can also be a dedicated physical device for deploying the main chain, including a standalone server or distributed nodes, used to run the main chain's consensus algorithm and store data. Using new physical devices can decouple the operation of the blockchain from existing devices, reducing the risk of single points of failure and improving the system's fault tolerance.

[0112] In one embodiment, to ensure data security (such as preventing leakage risks) in a multi-layered blockchain structure, the present invention introduces various mechanisms to ensure data security in the multi-layered blockchain structure, including but not limited to the following mechanisms:

[0113] When storing data in a blockchain, sensitive data is encrypted using symmetric encryption algorithms (such as AES) or asymmetric encryption algorithms (such as RSA). The encrypted data can then be securely stored on a sub-chain. In this way, even if unauthorized users access the encrypted data during transmission and storage within the blockchain, they cannot obtain the original data.

[0114] Zero-knowledge proofs can be used to verify the authenticity of data without disclosing any sensitive information. By using zero-knowledge proofs, necessary verification and interaction can be completed while ensuring data security.

[0115] Set access controls for the blockchain. Only authorized users and devices should be able to access data on the blockchain. Access permissions for users and devices can be managed and controlled through an access control server. Simultaneously, smart contracts can be used to implement fine-grained access control, ensuring that only authorized users can access specific data.

[0116] During data processing, privacy protection technologies such as differential privacy, data anonymization, and data masking are employed to process sensitive data. This ensures that even if data is leaked, the original sensitive information cannot be obtained.

[0117] Regularly check the operational status and data access of the blockchain. Through auditing and monitoring, potential data breach risks can be identified, and appropriate measures can be taken to prevent data breaches.

[0118] In one embodiment, zero-knowledge proof technology is used to ensure data privacy and security during data interaction. Zero-knowledge proofs allow a verifier to prove a statement is true without disclosing any detailed information about the statement. Specifically, secure data interaction can be achieved using zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge). zk-SNARKs are non-interactive, concise zero-knowledge proof systems that can prove data satisfies specific conditions without revealing plaintext data.

[0119] When data interacts between a secure storage server and a general-purpose storage server, zero-knowledge proof technology is used for verification. When the secure storage server sends encrypted data to the general-purpose storage server, it can attach a zk-SNARK proof demonstrating that the data meets certain conditions (such as data ownership or data integrity). Upon receiving the encrypted data and the proof, the general-purpose storage server can verify the correctness of the proof without decrypting the data. This ensures the privacy and security of the data during transmission.

[0120] Furthermore, when an external device initiates a data query request, the query results are verified using smart contracts and zero-knowledge proof technology. The smart contract verifies the zk-SNARK proof of the query results to ensure that the results meet specific conditions. This ensures data privacy and security throughout the query process.

[0121] In one embodiment, the authorization server will evaluate the request based on factors such as request type, device reputation score, and access frequency to determine its reasonableness, including the following:

[0122] The permission server assesses the risk of device access requests based on risk scoring, thereby enabling more granular access control.

[0123] Risk score = Σ(r_i*y_i)*(1 / (1+exp(-k*(permission score-x0))))+Σ(w_i*x_i)*data sensitivity-EMA(t)*α

[0124] in:

[0125] r_i: The weighting coefficient of risk factor i. The weighting coefficient can be set according to actual business needs.

[0126] y_i: The equipment's score under risk factor i. The score can be calculated based on the equipment's historical performance, reputation, and other information under that risk factor.

[0127] For each access request, risk factors need to be calculated, including:

[0128] The formula for the probability of abnormal behavior of external devices is: Probability of abnormal behavior = (Number of historical abnormal behaviors of the device + 1) / (Total number of historical behaviors of the device + 2).

[0129] External device reputation penalty: If a device's access request is denied, a penalty formula is used to lower the device's reputation. The reputation penalty formula is:

[0130] Reputation penalty = 1 / (1+exp(-α*(historical number of rejections-β))).

[0131] k: Slope parameter, used to adjust the curve of the authority scoring adjustment factor. The larger the k value, the steeper the curve, and the more sensitive the authority score is to the risk score.

[0132] x0: Threshold offset parameter. It represents the threshold in the permission scoring adjustment factor function, used to adjust the impact of permission scoring on risk scoring. Both k and x0 can be adjusted according to business needs.

[0133] Access score: Calculated based on information such as the device's role, historical behavior, and reputation score. The calculation formula is:

[0134] Permission score = w1 * role weight + w2 * historical behavior weight + w3 * reputation score weight

[0135] Among them, w1, w2, and w3 are the weights of each factor, which can be adjusted according to business needs.

[0136] Role weight, historical behavior weight, and reputation score weight are three important factors set up for calculating permission scores. These weights represent the relative importance of each factor when calculating permission scores, and their values ​​can be adjusted according to business needs and actual scenarios.

[0137] Role weights reflect the impact of a device's role in the system on its access permissions. For example, administrator devices may have higher access permissions, while ordinary user devices may have lower access permissions. Role weights can be set based on the access permission requirements of each role in the system. This can be a fixed value or a value dynamically adjusted according to system policies. Historical behavior weights reflect the importance of a device's past behavior in determining its access permissions. Good past behavior of external devices (including but not limited to high access frequency and long access duration) earns them higher historical behavior weights, while bad behavior corresponds to lower historical behavior weights (including but not limited to low access frequency and short access duration). Reputation score weights reflect the impact of a device's reputation on its access permissions. Reputation score weights can be determined by evaluating the external device's reputation record in the system, including analyzing the external device's reputation score and evaluations, and converting this into a reputation score weight.

[0138] After determining these weights, they can be multiplied by their corresponding weight coefficients (w1, w2, and w3), and then the results can be summed to calculate the permission score. The weight coefficients can be adjusted according to business needs to ensure that the calculated permission score reflects the actual scenario.

[0139] w_i: The weighting coefficient of the device in different scenarios. It represents the relative importance of different scenarios when calculating data access weights. The weighting coefficient can be set according to actual business needs.

[0140] x_i: The access behavior score of the device in scenario i. The access behavior score can be set according to actual business needs.

[0141] Data sensitivity: Calculated based on the type of data, using the following formula:

[0142] Data sensitivity = -Σ(P_i*log(P_i)).

[0143] Here, P_i is the probability of data type i appearing. The probability of a data type can be estimated based on historical access records.

[0144] The data types include, but are not limited to, personal basic information, transaction records, account balances, credit scores, investment product information, loan information, and insurance product information. For each data type i, its probability of occurrence P_i can be calculated based on historical access records, and the sensitivity of the entire dataset can be calculated using the data sensitivity formula, including: collecting historical access records and counting the access frequency of various data types. The access probability of each data type is calculated as: P_i = access frequency (data type i) / total access frequency. The sensitivity contribution of each data type is calculated as: S_i = P_i * log(P_i). Finally, the sensitivity contributions of all data types are summed to obtain the data sensitivity of the entire dataset: Data Sensitivity = -Σ(S_i).

[0145] EMA(t): The exponential moving average access rate of a device over time t. The calculation formula is:

[0146] EMA(t) = α * number of visits(t) + (1-α) * EMA(t-1)

[0147] Where α is the smoothing coefficient, t is time, and the number of visits (t) is the number of visits within the preset time period.

[0148] The preset time period can be set reasonably according to business needs.

[0149] α: Smoothing factor, used to calculate the exponential moving average access rate. A larger α value gives greater weight to recent access frequency, meaning the calculation of device access rate pays more attention to recent changes. A smaller α value gives greater weight to historical access frequency, meaning the calculation of device access rate is smoother. The smoothing factor can be adjusted according to actual business needs.

[0150] Here, Σ(r_i*y_i) is the risk score component, representing the device's score under different risk factors. r_i is the weight coefficient of risk factor i, and y_i is the device's score under risk factor i. (1 / (1+exp(-k*(permission score-x0)))) is the permission score component, representing the impact of the device's role, historical behavior, and reputation score on the risk score. k is the slope parameter, and x0 is the threshold offset parameter. Σ(w_i*x_i) is the data access weight component, representing the device's access behavior score under different scenarios. w_i is the weight coefficient of the device under different scenarios, and x_i is the device's access behavior score under scenario i. Data sensitivity is the data sensitivity assessment component, representing the impact of data type, frequency, and purpose on the risk score. Data sensitivity can be calculated based on data type information, using entropy to assess data sensitivity. EMA(t)*α is the time window access restriction component, representing the impact of the device's access rate over a period of time on the risk score. EMA(t) is the device's exponential moving average access rate at time t, and α is the smoothing coefficient.

[0151] The risk score is used to assess the risk and authorization level of device access requests, thereby enabling more granular access control. This improves the accuracy of access control while ensuring system security.

[0152] In one embodiment, a specific example is given to illustrate how to use the above risk scoring formula to control external devices' access to financial form data.

[0153] The external device is a client application of a bank, and the data requested by the external device is a financial transaction report.

[0154] First, a risk score is calculated based on factors such as the device's role, historical behavior, and reputation score.

[0155] The permission score includes: a higher role weight (0.8) for the client application, a lower historical behavior weight (0.1) and a higher reputation score weight (0.9). The weight coefficients are w1 = 0.4, w2 = 0.3, and w3 = 0.3, respectively. The permission score = 0.4 * 0.8 + 0.3 * 0.1 + 0.3 * 0.9 = 0.63.

[0156] Then calculate the probability of abnormal behavior: the number of historical abnormal behaviors of the device is 2, and the total number of historical behaviors of the device is 50. The probability of abnormal behavior = (2+1) / (50+2) = 0.057.

[0157] Determine the access control threshold: k = 3, x0 = 0.5. Access control threshold = 1 / (1 + exp(-3*(0.63-0.5))) = 0.710.

[0158] Determine data sensitivity: The sensitivity score for financial transaction reports is 0.8.

[0159] Access frequency limit determined: The initial access frequency of the external device is 10 times / day, with a decay rate of 0.1. On the 3rd day, the access frequency limit = 10 * exp(-0.1 * 3) = 7.44 times / day.

[0160] Determine the reputation penalty: The external device has a historical rejection count of 1, the penalty coefficient α = 0.2, and the rejection count threshold β = 2. Reputation penalty = 1 / (1 + exp(-0.2 * (1-2))) = 0.450.

[0161] Determine the data access weight: The device's weight coefficient in the financial transaction reporting scenario is 0.7, and the access behavior score is 0.9. Data access weight = 0.7 * 0.9 = 0.63.

[0162] Determine the access limit within the time window: smoothing coefficient α = 0.1. The device accessed the device 5 times the previous day, and the EMA value of the previous day was 8 times. EMA(t) = 0.1 * 5 + (1 - 0.1) * 8 = 7.3 times / day.

[0163] Finally, calculate the risk score based on all the parameters determined above, and substitute each parameter into the risk score formula:

[0164] Risk score = Σ(r_i*y_i)*(1 / (1+exp(-k*(permission score-x0))))+Σ(w_i*x_i)*data sensitivity-EMA(t)*α

[0165] In this access request, there are two risk factors: the probability of abnormal behavior (0.057) and the reputation penalty (0.450), with weight coefficients r1 = 0.6 and r2 = 0.4, respectively. Therefore, Σ(r_i*y_i) = 0.6*0.057 + 0.4*0.450 = 0.234.

[0166] Substituting into the formula, we get:

[0167] Risk score = 0.234*(1 / (1+exp(-3*(0.63-0.5))))+0.63*0.8-7.3*0.1=0.234*0.710+0.504-0.73=-0.06.

[0168] Since the risk score determined in this access request is less than 0, it means that the device's request to access the financial transaction report is considered low-risk. Therefore, the smart contract will allow the access request.

[0169] Furthermore, if the risk score is greater than 0, it means that the device's request to access financial transaction reports is considered high-risk. In this case, the smart contract will reject the access request.

[0170] In one embodiment, the sub-chain in which the external device resides can be adjusted based on a threshold number of access denials. This includes setting a threshold number of denials for each sub-chain containing the external device and the general storage service server. When the number of denials for an external device in the current sub-chain exceeds the threshold, the external device will be downgraded to a sub-chain with lower privileges.

[0171] First, assign a threshold for the number of access denials to each subchain. For example: Subchain 1: threshold = 3; Subchain 2: threshold = 5; Subchain 3: threshold = 8. The smart contract records the number of times each device's access request is denied in the current subchain. Whenever a device's access request is denied, its denial count is updated. Whenever a device's denial count exceeds the current subchain's threshold, the device is removed from the current subchain and added to a subchain with lower permissions.

[0172] This approach ensures that only devices with good performance can access subchains with higher privileges, thereby improving the security of the entire system.

[0173] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0174] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0175] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0176] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0177] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0178] The preferred embodiments of the present invention have been described above to make the spirit of the present invention clearer and easier to understand, and are not intended to limit the present invention. All modifications, substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope summarized by the appended claims.

Claims

1. A blockchain-based method for processing financial form data, the method comprising: When an external device sends an access request to financial form data, the general storage server receives the request. The general storage server sends the access request to the authorization server for authentication and authorization; The permission server checks the credentials of the external device and determines whether to allow access to the requested data based on predefined roles and permissions; If the access request is authorized, the permission server will send the request to the secure storage server to obtain the required data; The secure storage server extracts sensitive and non-sensitive data according to the request type, and the secure storage server sends encrypted sensitive data to the verification server for verification. The verification server uses homomorphic encryption to verify the authenticity of the encrypted sensitive data without decrypting the data; Once the verification is successful, the secure storage server will send the sensitive data to the secure processing server for de-identification. The secure processing server uses differential privacy and data masking techniques to process sensitive data, generate de-identified data, and send it to the secure storage server. The secure storage server merges the desensitized data with the non-sensitive data to form a complete dataset. The secure storage server sends the merged dataset back to the general storage server, which then sends the financial form data as a response to the external device.

2. The blockchain-based financial form data processing method as described in claim 1, characterized in that, In the case of a single access request or an occasional access request, the general storage server sends the access request to the authorization server for authentication and authorization. The authorization server then generates an access token based on the user's permissions. This token contains the range of data that the user can access and the type of operation, and sends the token to the external device.

3. The blockchain-based financial form data processing method as described in claim 1, characterized in that, Use a multi-layered blockchain structure to control and manage external devices and access requests; The multi-layered blockchain structure includes a main chain and multiple sub-chains; The plurality of subchains includes at least a permission subchain, and a plurality of subchains for external devices and general storage service servers; In this process, multiple sub-chains are created for external devices based on different permission levels. External devices are assigned to the corresponding sub-chains according to their permissions. The sub-chains are responsible for recording data access and operation logs under their respective permissions. When the access permissions of an external device change, the smart contract will automatically switch the device from the current subchain to another subchain. The permission subchain records and manages these subchain switching operations.

4. The blockchain-based financial form data processing method as described in claim 1, characterized in that, In scenarios with multiple access requests, when an external device not on the blockchain initiates an access request for financial form data, the permission server queries the external device's access permissions based on the external device's identity information. If the external device does not have access permissions, the request will be rejected.

5. The blockchain-based financial form data processing method as described in claim 1, characterized in that, For external devices that have passed authentication and authorization verification, the authorization server will evaluate the access request, and the authorization server will assess the risk of the access request based at least on the request type, device reputation score, and access frequency.

6. The blockchain-based financial form data processing method as described in claim 1, characterized in that, When data interaction occurs between the secure storage server and the general storage server, zero-knowledge proof technology is used for verification. When the secure storage server sends encrypted data to the general storage server, it includes a zero-knowledge proof. Upon receiving the encrypted data and the proof, the general storage server verifies the correctness of the proof without decrypting the data.

7. The blockchain-based financial form data processing method as described in claim 1, characterized in that, The permission server assesses the risk of the external device's access request based on a risk score. If the risk score determined in the access request is less than 0, it indicates that the external device's access request to the financial transaction report is low-risk, and the smart contract will allow the access request. If the risk score is greater than 0, it indicates that the external device's request to access the financial transaction report is high-risk, and the smart contract will reject the access request.

8. A blockchain-based financial form data processing device, wherein the device is a secure storage server, an authorization server, a verification server, a secure processing server, or a general-purpose storage server, and the system is used to execute the financial form data processing method of claims 1-7 in response to access requests from external devices.

9. An electronic device for processing financial form data based on blockchain, the electronic device comprising a memory and a processor, the memory storing computer program code, the electronic device being used to implement the functions of a secure storage server, an authorization server, a verification server, a secure processing server, or a general storage server as described in claims 1-7.

10. A storage medium storing computer program code, wherein a processor performs calculations and executes the program code in the storage medium to implement the functions of a secure storage server, authorization server, verification server, secure processing server, or general-purpose storage server as described in claims 1-7.

Images