TW202318239A - Data read authority control system based on block chain and zero-knowledge proof mechanism, and related data service system - Google Patents

Abstract

A data read authority control system is disclosed, including: a block chain system; a data owner device arranged to operably generate a target data, and to operably generate a proof using a proof key; a data source system arranged to operably generate a sensitive data corresponding to the target data; a data service system arranged to operably receive the target data and the proof, and to operably request the block chain system to verify the proof; and a data requester device arranged to operably generate and transmit a sensitive data request corresponding to the target data to the data service system. The block chain system can execute a zero-knowledge proof (ZKP) smart contract to verify the correctness of the proof, and can transfer a read token to the data service system. After acquiring the read token, the data service system transfers read token to the data source system to request the data source system to provide the sensitive data.

Description

Data access authority control system and related data service system based on blockchain and zero-knowledge proof mechanism

The invention relates to a data access authority control and management technology, in particular to a data access authority control and management system based on a block chain and a zero-knowledge proof mechanism, and a related data service system.

The General Data Protection Regulation (GDPR) formulated by the European Union not only has strict regulations on personal data protection and privacy, but also covers a wide range. Failure to meet the GDPR regulations will have a very significant impact or hindrance on business activities in many areas.

Since the traditional OAuth 2.0 data authorization framework cannot meet the various requirements of GDPR, the industry is actively developing various more complex data access authority control structures to cope. Various newly developed data access authority control frameworks, including UMA 2.0 (User-Managed Access 2.0), use a centralized authorization server (centralized authorization server) to manage the data access authority of individual data owners. Such a structure seems to meet the requirements of GDPR, but it is not transparent in the control of data access rights, and it is also difficult to prove to the data recipient (or other third parties) the authenticity of the relevant sensitive data of the data owner sex. Therefore, the existing data access authority control framework is not an ideal technical solution for many commercial applications (for example, carbon rights trading, various loan shortfall loans, electric vehicle charging reservation and payment, etc.).

In view of this, how to make the data access authority control system not only meet the various requirements of the EU GDPR, but also enable the authenticity of the relevant sensitive data of the data owner to be effectively verified is a problem to be solved.

This specification provides an embodiment of a data access authority control system, which includes: a block chain system; a data owner device, configured to receive data input by a target user to generate a target data, and can use A certification key generates a certification value; a data source system is configured to store a sensitive data corresponding to the target data; a data service system is configured to receive the target data generated by the data owner's device and The proof value, and may require the blockchain system to verify the proof value; a data requester device configured to generate and transmit a sensitive data request corresponding to the target data to the data service system; wherein, the area The block chain system is set to execute a zero-knowledge proof smart contract to use a verification key to check the correctness of the proof value, and when it is determined that the proof value is correct, send a verification success notification to the data service system ; Wherein, the block chain system is also configured to check the validity of an authorization token corresponding to the identification data of an authorization token, and when it is determined that the authorization token is valid, generate and transfer an access signal to the data service system; wherein the data service system is further configured to, after obtaining the access beacon, send the alert data request to the data source system and transfer the access beacon to the data source system; wherein, if the access beacon transferred by the data service system to the source data system is valid, the source data system may transmit the alert data corresponding to the target data to the data service system, and the The data service system may send the alert data to the data requester device.

This specification also provides an embodiment of a data service system used in a data access authority control system. The data access authority control system includes a data owner device, a data requester device, a data source system, and a block chain system. The data service system includes: a communication circuit configured to receive a target data and a certification value transmitted from the data owner's device, and to receive a target data corresponding to the target data transmitted from the data requester's device Sensitivity data request; a block chain operation circuit, set to act as one of the nodes of the block chain system, and can request the block chain system to verify the proof value, wherein, the block chain system will execute a zero The knowledge proof smart contract uses a verification key to check the correctness of the proof value; a database is configured to store the target data; and a web server is coupled to the communication circuit and the block chain calculation The circuit and the database are configured so that when the blockchain system determines that an authorization token corresponding to an authorization token identification data is valid, the blockchain can be obtained through the communication circuit or the blockchain computing circuit. An access beacon transferred by the system; wherein, the communication circuit is also configured to receive a verification success notification from the blockchain system when the blockchain system determines that the proof value is correct; wherein, The web server is also configured to transmit the sensitive data request to the data source system through the communication circuit after obtaining the access beacon, and transfer the access through the communication circuit or the blockchain computing circuit to the source data system; wherein, if the access beacon transferred from the data service system to the source data system is valid, the web server can also receive the A sensitivity data corresponding to the target data, and the sensitivity data may be transmitted to the data requester device through the communication circuit.

One of the advantages of the above-mentioned embodiment is that the blockchain subsystem is used to replace the traditional centralized authorization server, which can effectively improve the transparency of the decentralized data authorization control system in the control and control of data access rights, thereby reducing the number of data sources. Potential for disputes between the system and the data service system or data owner.

Another advantage of the above embodiment is that the blockchain system can use the zero-knowledge proof mechanism to check the correctness of the proof value, and the data service system can verify the target data according to the verification result of the blockchain system for the proof value The authenticity of all or part of the content.

Other advantages of the present invention will be explained in more detail with the following description and drawings.

Embodiments of the present invention will be described below in conjunction with related figures. In the drawings, the same reference numerals indicate the same or similar elements or method flows.

FIG. 1 is a simplified functional block diagram of a data access authority control and management system 100 according to an embodiment of the present invention. The data access authority control system 100 can be used to control the access authority of relevant data of multiple data owners of various types such as individuals or business organizations, and can adopt a zero-knowledge proof (ZKP) mechanism to verify The authenticity of the data provided by the data owner.

The data access authority control system 100 includes one or more data owner devices (for example, the exemplary data owner devices 110-120 shown in FIG. 1 ), one or more data requester devices (for example, FIG. 1), one or more data source systems (eg, the exemplary data source system 150 shown in FIG. 1), a data service system 160, a district The block chain node cluster 170 and a block chain system 180 jointly formed by the block chain node cluster 170 and other block chain computing circuits.

Multiple data owner devices 110-120 in the data access authority control system 100 belong to different data owners, and individual data owners can be individuals, various types of enterprises or corporate organizations, various foundations, legal persons, Various corporate legal persons, various non-profit organizations, various government agencies, etc.

Multiple data requester devices 130-140 in the data access authority control system 100 belong to different data requesters, and individual data requesters can be individuals, various types of enterprises or corporate organizations, various foundations, legal persons, Various corporate legal persons, various non-profit organizations, various government agencies, etc.

The data source system 150 is a system operated by a specific service provider that can provide digital storage services (for example, various online storage companies, banks, financial institutions, credit card issuers, government agencies, etc.), and is used to store data related to individual data. Various digital data related to or provided by individual data owners, such as various digital files, various program files, and/or various multimedia data, etc.

The data service system 160 is a specific service provider (for example, various A system operated by an online trading platform, an online book rental platform, an online multimedia rental platform, an NFT trading platform, etc.) to manage the use rights, data browsing rights, transaction rights, etc. of individual data owners and/or data requesters .

In addition, the blockchain system 180 is usually a blockchain system jointly operated and managed by a number of different entities, which is used to control the access authority of the data stored in the data source system 150, and can allow individual data The owner dynamically adjusts the data authorization policy through the corresponding data owner device.

In practical applications, various types of digital data stored in the data source system 150 may be transmitted to the data source system 150 by individual data owners through related devices (for example, data owner devices), or may be authorized The operator input to the data source system 150 may also be generated by the data source system 150 executing a predetermined computer program.

Individual data owners can log into the data service system 160 through corresponding data owner devices, and create specific target data (eg, specific documents, files, descriptive text, contract terms, transaction conditions, etc.). In addition, individual data owners can also transmit data authorization policies for different data requesters to the blockchain system 180 through the data owner device for storage and management, so as to prevent data authorization policies from being tampered with. The aforementioned data authorization policy may include authorized object, authorized data subject, authorized content, upper limit of authorized times, authorized period, authorized time limit, geographical area where the data is located, and identification information of the data source system 150 (for example, the data source system 150 Some or all of the parameters such as the address of the specific smart contract deployed by the operator in the blockchain system 180).

After the data service system 160 receives the target data from the device of the data owner, it can work with the blockchain system 180 to verify the authenticity of all or part of the content of the target data. During operation, the blockchain system 180 can execute a specific smart contract to use a zero-knowledge proof (ZKP) mechanism to check the correctness of a proof value (proof) generated by the data owner's device to indirectly verify the authenticity of the target data Authenticity of all or part of the content. In practice, the blockchain system 180 can execute specific smart contracts deployed by the data source system 150 to perform related zero-knowledge proof operations.

On the other hand, individual data requesters can control corresponding data requester devices to apply to the data service system 160 for specific data corresponding to specific data owners. At this point, the data service system 160 can apply to the blockchain system 180 for a data read token corresponding to specific data, and the blockchain system 180 will execute the relevant smart contract to determine the data service Whether the system 160 will provide the data access beacon to the data service system 160 .

After the data service system 160 obtains the data access token generated by the blockchain system 180 , it can send the relevant data request to the data source system 150 and transfer the data access token to the data source system 150 . At this time, the data source system 150 can use the blockchain system 180 to check the validity of the data access beacon. Only when the validity of the data access beacon can be verified by the blockchain system 180, the data source system 150 will provide the specific data content corresponding to the specific data owner to the data service system 160, and the data service System 160 is provided to associated data requester devices.

In addition, the blockchain system 180 can also record the relevant time information of individual data access beacons as evidence that the data service system 160 accesses specific data content.

In the data access authority control system 100, individual data owners can also dynamically adjust the data authorization policy stored in the blockchain system 180 as needed. For example, when an individual data owner adjusts the data authorization policy for the data service system 160, a specific data requester, or all data requesters due to various reasons, the updated data authorization policy can be updated by using the relevant data owner device It is sent to the blockchain system 180 for storage and management to replace the original version of the data authorization policy.

In order to meet the needs of certain commercial transactions or legal relationship management, different participants in the data access authority control system 100 can use traditional or digital methods to sign various appropriate agreements or contracts to further clarify the mutual legal relationship. For example, various appropriate transaction contracts, loan contracts, investment contracts, data hosting agreements, online storage space rental contracts, service agreements, etc. Intellectual property ownership agreement, data transmission agreement, privacy protection agreement, data sharing agreement, and/or personalized advertisement broadcast agreement, etc.

As another example, various appropriate transaction matching agreements, investment target matching agreements, loan matching agreements, data authorization agreements, and data sharing agreements can be signed between individual data owners and specific service providers operating the data service system 160. Agreement, Data Use Agreement, Data Audit Agreement, and/or Data Audit Agreement, etc.

For another example, various appropriate blockchain service agreements can be signed between individual data owners and specific service providers operating the blockchain system 180 .

As another example, various appropriate transaction agreements, investment agreements, loan agreements, data authorization agreements, data sharing agreements, data usage agreements, data inspection agreements, and/or agreements can be signed between individual data owners and individual data requesters. Or data audit protocol and so on.

For another example, various appropriate transaction matching agreements, investment target matching agreements, loan matching agreements, data index specification agreements, data Query agreement, data sharing agreement, data use agreement, data transmission agreement, and/or service agreement, etc.

As shown in FIG. 1 , the data owner device 110 includes a communication circuit 111 , a blockchain computing circuit 113 , a display device 115 , and a control circuit 117 . The data requester device 130 includes a communication circuit 131 , a display device 133 , and a control circuit 135 . The data source system 150 includes a communication circuit 151 , a blockchain computing circuit 153 , a database 155 , and a data server 157 . The data service system 160 includes a communication circuit 161 , a blockchain computing circuit 163 , a database 165 , and a web server 167 . The blockchain node cluster 170 includes a plurality of blockchain nodes (nodes), for example, the exemplary blockchain nodes 171 - 177 shown in FIG. 1 .

In the data owner device 110, the communication circuit 111 is configured to perform data communication with the data source system 150, the data service system 160, and/or the blockchain system 180 through the Internet or other networks. The block chain operation circuit 113 is coupled to the communication circuit 111 , used to act as one of the nodes of the block chain system 180 , and can be used as a communication bridge between the data owner device 110 and the block chain system 180 . The display device 115 is used for displaying text, data, and/or images. The control circuit 117 is coupled to the communication circuit 111, the blockchain operation circuit 113, and the display device 115, and is configured to control the operation of the aforementioned devices.

In the data requester device 130, the communication circuit 131 is configured to perform data communication with the data service system 160 through the Internet or other networks. The display device 133 is coupled to the communication circuit 131 for displaying text, data, and/or images. The control circuit 135 is coupled to the communication circuit 131 and the display device 133 and is configured to control the operation of the aforementioned devices.

Other data owner devices (for example, the data owner device 120 ) in the data access authority control system 100 may have a main structure similar to that of the data owner device 110, but the implementation is not limited to all data owners The devices must have exactly the same circuit architecture. Similarly, other data requester devices (for example, the data requester device 140) in the data access authority control system 100 may have a main structure similar to that of the data requester device 130, but the implementation is not limited to all The data requester devices must have the exact same circuit architecture.

In the data source system 150, the communication circuit 151 is configured to perform data communication with the data service system 160, the blockchain system 180, and/or individual data owner devices through the Internet or other networks. The block chain operation circuit 153 is coupled to the communication circuit 151 , used to act as one of the nodes of the block chain system 180 , and can be used as a communication bridge between the data source system 150 and the block chain system 180 . The database 155 is used for storing data respectively corresponding to different data owners. The data server 157 is coupled to the communication circuit 151, the blockchain computing circuit 153, and the database 155, and is configured to control the operation of the aforementioned devices.

In the data service system 160, the communication circuit 161 is configured to communicate with the data source system 150, the blockchain system 180, individual data owner devices, and/or individual data requester devices through the Internet or other networks. communication. The block chain computing circuit 163 is coupled to the communication circuit 161 , used to act as one of the nodes of the block chain system 180 , and can be used as a communication bridge between the data service system 160 and the block chain system 180 . The database 165 is used to store various data required by the data service system 160 for various applications. The web server 167 is coupled to the communication circuit 161, the blockchain computing circuit 163, and the database 165, and is configured to control the operation of the aforementioned devices.

In practical applications, the aforementioned data source system 150 may provide a single type of service (for example, online banking service, financial service, contract file management service, cloud storage service, multimedia file sharing service, life record sharing service, community service , financial management service, health information management service, etc.), or a system that provides multiple composite services (for example, cloud storage service with email service, multimedia data sharing service with instant messaging service, community service with multimedia streaming services, enterprise resource planning (ERP) cloud services with database services, etc.).

The blockchain system 180 in this embodiment is composed of the blockchain computing circuit 113 in the data owner device 110, the blockchain computing circuit 153 in the data source system 150, and the blockchain computing circuit in the data service system 160. The circuit 163 and a plurality of blockchain nodes 171-177 in the blockchain node cluster 170 are jointly formed.

In practice, the communication circuits 111, 131, 151, and 161 can be realized by using various appropriate circuits that comply with related network communication, wireless communication, or mobile communication specifications, such as network interface cards (Network Interface Card, NIC), Wireless transmission (Wi-Fi) circuit, or mobile communication circuit, etc. The block chain computing circuits 113, 153, 163, and the block chain nodes 171~177 can all be implemented by one or more processor modules or computer systems suitable for block chain consensus algorithm (consensus algorithm) operations. accomplish. Both the display devices 115 and 133 can be implemented by various screens, projection devices, televisions, and other devices capable of displaying text, data, images, and/or images. Both the databases 155 and 165 can be realized by using various relational databases or non-relational databases. Both the control circuits 117 and 135 can be implemented by one or more processor modules with appropriate computing capabilities, a single computer system, or a combination of multiple computer systems. Both the data server 157 and the web server 167 can be realized by a single server, or can be realized by a combination of multiple servers located in the same geographical area or in different geographical areas.

In some embodiments, the blockchain computing circuit 113 can be integrated into the control circuit 117 . Likewise, the blockchain computing circuit 153 can also be integrated into the data server 157 , and/or the blockchain computing circuit 163 can be integrated into the web server 167 .

Please note that the aforementioned data owner device 110, data requester device 130, data source system 150, and data service system 160 can be provided with other man-machine interface devices (for example, Display, keyboard, mouse, touch screen, voice control module, etc.), but for the sake of simplification of the content of the figure, these human-machine interface devices are not shown in Figure 1.

In the application environment where the data owner corresponding to the data owner device 110 is an individual, the data owner device 110 can be realized by using a terminal device with a networking function and suitable computing capability, such as a tablet computer, a desktop computer, a notebook personal computers, mobile communication devices (such as smart phones, wearable devices, etc.), or other similar devices. Similarly, in the application environment where the data requester corresponding to the data requester device 130 is an individual, the data requester device 130 can be realized by using a terminal device with a networking function and suitable computing capabilities, such as a tablet computer, a desktop computer, etc. Computers, laptops, mobile communication devices (eg, smartphones, wearable devices, etc.), or other similar devices.

In the application environment where the data owners corresponding to the data owner device 110 are various types of enterprises or corporate organizations, foundations, corporate legal persons, non-profit organizations, and government agencies, the data owner device 110 can use a network function and a suitable Terminal equipment or information systems with computing power, such as tablet computers, desktop computers, notebook computers, mobile communication devices, computer servers, management information systems (MIS), enterprise resource planning (ERP) systems, or other similar devices. Similarly, in the application environment where the data requesters corresponding to the data requester device 130 are various types of enterprises or corporate organizations, foundations, corporate legal persons, non-profit organizations, and government agencies, the data requester device 130 can utilize functions and suitable computing capabilities of terminal equipment or information systems, such as tablet computers, desktop computers, notebook computers, mobile communication devices, computer servers, management information systems, enterprise resource planning systems, or other similar equipment.

For convenience of description, the specific data owner corresponding to the data owner device 110 is referred to as the data owner D1 below, and the specific data owner corresponding to the data owner device 120 is referred to as the data owner D2. The specific data requester corresponding to the data requester device 130 is called a data requester R1, and the specific data requester corresponding to the data requester device 140 is called a data requester R2.

In practice, the aforementioned data owner device 110, data requester device 130, data source system 150, and data service system 160 can also be used as virtual machines installed on various cloud platforms, or various computing entities and storage entities Combination to achieve, and remote control by the respective users.

In addition, in some application environments, the blockchain system 180 can be implemented with various public chain architectures. In other application environments, the blockchain system 180 can be implemented with the architecture of a private chain or an alliance chain, so as to shorten the time required for related calculations and improve the operational efficiency of the blockchain system 180 .

The operation process of the data access authority control system 100 for data access authority control will be further described below with reference to FIG. 2 to FIG. 6 . 2 to 6 are simplified flowcharts of a data access authority control method according to an embodiment of the present invention.

In the flowcharts of FIG. 2 to FIG. 6 , the process in the column of a specific device represents the process performed by the specific device. For example, the part marked in the field of "data owner's device" is the process performed by one of the data owner's devices 110~120; the part marked in the field of "data requester's device" is performed by The process performed by one of the data requester devices 130-140; the part marked in the "data source system" column is the process performed by the data source system 150; marked in the "data service system" column The part in is the process carried out by the data service system 160; the part marked in the column of "block chain system" is the process carried out by the block chain system 180.

As mentioned above, the data access authority control system 100 can be used to control the access authority of relevant data of multiple data owners of various types such as individuals or business organizations, and can use the zero-knowledge proof (ZKP) mechanism to verify The authenticity of the data provided by the data owner. Therefore, the data access authority control system 100 can be used to implement applications in many different scenarios. For example, the data access authority control system 100 can be used to assist individual users to perform various loan gap lending activities.

As we all know, many individuals or enterprises need to apply for loans from financial institutions such as banks (for example, housing loans, land loans, car loans, credit loans, etc.) wait). However, based on various factors (for example, policy control, credit rating restrictions, or insufficient collateral), financial institutions such as banks may not be able to fully approve the loan amount of the loan applicant, making the loan applicant Facing a loan-gap situation.

In some loan scenarios, if the loan applicant fails to raise funds to fill the loan gap before the deadline required by the financial institution, it may even lead to the rejection of the loan application by the financial institution. However, filling loan gaps is not an easy task for many loan applicants, especially when there is time pressure. In this case, the data access authority control system 100 can be used to assist the loan applicant to initiate (initiate) a shortfall loan to other individuals or investment units (for example, the aforementioned data requester), so as to assist the loan applicant to process the loan shortage problem.

To facilitate understanding, the following will take the application scenario where the data access authority control system 100 assists a loan applicant to carry out home-loan-gap lending/housing-loan-gap lending through the data service system 160 as an example, The operation of the data access authority control of the data access authority control system 100 will be described.

Generally speaking, when individual loan applicants apply for housing loans (home loan/housing loan) from banks and other financial institutions, banks and other financial institutions will assess individual loan applicants' job nature, credit status, income status, debt repayment ability, and/or other conditions, and generate a corresponding credit evaluation report. In addition, financial institutions such as banks will also investigate and evaluate the condition and value of the relevant loan subject (that is, the house to be purchased by the loan applicant in this example), and generate a corresponding appraisal report.

After various evaluation procedures, if banks and other financial institutions think that they can lend to the loan applicant, they can generate and provide relevant loan contract documents (or loan contract draft documents) to the loan applicant. When the approved loan amount agreed by the financial institution is lower than the amount required by the loan applicant, a home loan gap (housing loan gap) Y occurs. For example, the aforementioned mortgage shortfall Y may be the amount obtained by subtracting the approved loan amount L from the house price (house price) (that is, Y=P-L). For another example, the aforementioned mortgage shortfall Y may be the housing price P minus the loan applicant's own down payment (down payment) D and approved loan amount L (that is, Y=P-D-L). As another example, the aforementioned mortgage shortfall Y may be the total amount of the house price P plus the estimated decoration fee (estimated decoration fee) C, minus the down payment D prepared by the loan applicant and the approved loan amount L amount (that is, Y=P+C-D-L). Some financial institutions also require loan applicants to find a way to fill the mortgage gap within a specified period, otherwise it may lead to the rejection of the housing loan application.

For convenience of description, it will be assumed that the aforementioned loan applicant (or borrower party) is the data owner D1 corresponding to the data owner device 110 , and that the aforementioned financial institution is the data source system 150 operating unit. In addition, the following also assumes that the investor (or called lender, lender party) that may lend money to the loan applicant is the data requester R1 corresponding to the aforementioned data requester device 130 and/or the data requester device 140 The corresponding data requester R2.

As mentioned above, when the data owner D1 applies for a housing loan from a financial institution (that is, the operating unit of the data source system 150), the operating unit of the data source system 150 can generate a credit evaluation report corresponding to the data owner D1, And an appraisal report corresponding to the loan object (that is, the house to be purchased by the data owner D1). If the operating unit of the data source system 150 considers that the loan can be given to the data owner D1 after evaluation, it can also generate a loan contract file/loan contract draft file corresponding to the data owner D1.

Similarly, when other loan applicants (for example, the data owner D2 corresponding to the data owner device 120) apply for housing loans from the operating unit of the data source system 150, the operating unit of the data source system 150 can also generate relevant credit Appraisal report, appraisal report, and/or loan contract document/draft loan contract document.

The aforementioned credit evaluation report, appraisal report, and/or loan contract document/loan contract draft document related to individual loan applicants are sensitive data corresponding to individual loan applicants to some extent. Since the content of these sensitive data involves the personal information or privacy of individual loan applicants, individual loan applicants can also be regarded as the owner of relevant sensitive data from a certain perspective.

As shown in FIG. 2, when the operating unit of the data source system 150 generates sensitive data related to individual loan applicants (for example, the aforementioned credit evaluation report, appraisal report, and/or loan contract document/loan contract draft document) , the process 202 can be performed by using the data source system 150 .

In the process 202 , the manager or operator of the data server 157 can use the database 155 to store multiple sensitive data corresponding to different data owners (eg, different loan applicants). As can be seen from the foregoing description, the sensitivity data stored in the database 155 may be the aforementioned credit evaluation report, appraisal report, and/or loan contract document/loan contract draft document related to an individual loan applicant. In other words, the process 202 may be performed intermittently. Under normal circumstances, in order to ensure the rights and interests of loan applicants, the operating unit of the data source system 150 will not, without the consent of the loan applicant, store the aforesaid information related to the loan applicant stored in the database 155. Information provided to third parties.

In the process 204 , the data server 157 can establish a corresponding relationship between an individual data owner and a corresponding pair of proof key and verification key. For example, the data server 157 can establish a corresponding relationship between the data owner D1 and a pair of corresponding proof key PK1 and verification key VK1 . Similarly, the data server 157 can also establish a corresponding relationship between the data owner D2 and another pair of corresponding proof key PK2 and verification key VK2 . In practice, the key pairs corresponding to different data owners will be different.

As shown in Figure 2, the manager or operator of the data source system 150 can use the data source system 150 to cooperate with the block chain system 180 to perform process 206 to process 210, so as to deploy available data service systems in the block chain system 180 160 Check the relevant smart contracts required for the proof value (proof) generated by the device of the individual data owner.

In the process 206, the data server 157 can be controlled by its administrator or operator, according to a pairing relationship between the certification key and the verification key of an individual data owner, and a predetermined verification rule (predetermined verification rule), Establish one or more zero-knowledge proof smart contracts SC-ZKP. The foregoing predetermined verification rules may include one or more constraint items (constraint). In practice, the data server 157 can establish multiple different zero-knowledge proof smart contracts SC-ZKP for different data owners, or integrate the pairing relationship of key pairs corresponding to different data owners in the same A zero-knowledge proof smart contract SC-ZKP.

In this embodiment, the data server 157 can compile the pairing relationship between the certification key PK1 and the verification key VK1 corresponding to the data owner D1, and a first predetermined verification rule into a dedicated Zero-knowledge proof smart contract SC-ZKP. The aforementioned first predetermined verification rule may include one or more constraint items that only the data owner D1 and the operating unit of the data source system 150 know the correct information.

For example, the constraint item in the first pre-determined verification rule may be that the difference between a house price minus a loan amount will be equal to a pre-determined shortfall.

For another example, the constraint item in the first predetermined verification rule may be the result of performing a suitable hashing algorithm operation (hashing algorithm operation) on a house price and a first random value, which will be equal to a first predetermined hash value (first predetermined hash value), wherein the first random value is randomly selected by the data server 157 and will not be notified to the data owner D1.

For another example, the constraint item in the first predetermined verification rule may be the result of performing a suitable hash algorithm operation on a loan amount and a second random value, which will be equal to a second predetermined hash value (second predetermined hash value), wherein, the second random value is randomly selected by the data server 157 and will not be notified to the data owner D1.

For another example, the constraint item in the first predetermined verification rule may be that a password to be verified is equal to a unique password assigned to the data owner D1 by the operating unit of the data source system 150 .

For another example, the constraint item in the first predetermined verification rule may be that the identification data to be verified will be equal to a unique identification data corresponding to the data owner D1 (for example, the ID number, unified number, or is a file number of a loan file provided by the operating unit of the data source system 150 to the data owner D1).

For another example, the constraint item in the first predetermined verification rule may be that a house price will be equal to a first predetermined amount.

For another example, the constraint item in the first predetermined verification rule may be that a verified loan amount will be equal to a second predetermined amount.

In some embodiments, the first predetermined verification rule may only contain one of the aforementioned multiple different constraint items. In some other embodiments, the first predetermined verification rule may simultaneously contain multiple items among the aforementioned multiple different constraint items.

Similarly, the data server 157 can edit the pairing relationship between the proof key PK2 and the verification key VK2 corresponding to the data owner D2 and a second predetermined verification rule into another different zero-knowledge proof smart contract SC-ZKP.

Alternatively, the data server 157 can also share the pairing relationship between the certification key PK1 corresponding to the data owner D1 and the verification key VK1 and the corresponding first verification rule, and the certification key PK2 corresponding to the data owner D2 The pairing relationship with the verification key VK2 and the corresponding second verification rules are integrated in the same zero-knowledge proof smart contract SC-ZKP in an appropriate form.

In the process 208, the data server 157 can use the communication circuit 151 or the block chain operation circuit 153 to use a predetermined signal corresponding to the data source system 150 to generate one or more zero-knowledge proof smart contracts SC-ZKP Send it to the blockchain system 180, and instruct the blockchain system 180 to authenticate the aforementioned zero-knowledge proof smart contract SC-ZKP.

In this case, the blockchain system 180 will proceed to the process 210, using multiple nodes to execute a suitable consensus decision algorithm to authenticate the received zero-knowledge proof smart contract SC-ZKP. If the zero-knowledge proof smart contract SC-ZKP passes the authentication of the blockchain system 180, the blockchain system 180 will store the aforementioned zero-knowledge proof smart contract SC-ZKP in the form of a data block in the blockchain system 180. In the blockchain ledger, the procedure of deploying the aforementioned zero-knowledge proof smart contract SC-ZKP into the blockchain system 180 is completed.

On the other hand, the operator of the blockchain system 180 or a specific person with authority can use a suitable programming method to deploy relevant smart contracts required for subsequent data access authority control in the blockchain system 180 . In practical applications, the above-mentioned specific personnel with authority may be the operating unit of the blockchain system 180, the operating unit of the data source system 150, the operating unit of the data service system 160, relevant data owners, and/or relevant data Specific personnel in the working group formed by the requester, or specific personnel participating in the operation of the data access authority control system 100 .

For example, the operator or builder of the blockchain system 180 can edit and create a smart contract containing beacon management rules, and use a suitable communication device (such as a computer) to use the smart contract as a transaction message (transaction message) The form is transmitted to the blockchain system 180 and instructs the blockchain system 180 to authenticate the smart contract.

At this time, the block chain system 180 will proceed to the process 212, using multiple nodes to execute a suitable consensus decision algorithm to authenticate the smart contract including the beacon management rules. If the smart contract passes the authentication of the blockchain system 180, the blockchain system 180 will store the smart contract in the blockchain ledger of the blockchain system 180 in the form of a data block to complete the transfer of a message. The standard management smart contract SC-TM is deployed to the program of the blockchain system 180. In the subsequent operation stage, the blockchain system 180 can use the token management smart contract SC-TM to check and control the validity of different tokens corresponding to individual data owners.

Similarly, the operator or builder of the blockchain system 180 can edit and create a smart contract containing data authorization policy management rules, and use a suitable communication device (for example, a computer) to transmit the smart contract in the form of transaction information To the blockchain system 180, and instruct the blockchain system 180 to authenticate the smart contract.

At this time, the block chain system 180 can perform the process 214, using multiple nodes to execute a suitable consensus decision algorithm to authenticate the smart contract including the data authorization policy management rules. If the smart contract passes the authentication of the blockchain system 180, the blockchain system 180 will store the smart contract in the blockchain ledger of the blockchain system 180 in the form of a data block, so as to complete an authorization The procedure for deploying the policy smart contract SC-PL into the blockchain system 180. In the subsequent operation stage, the blockchain system 180 can use the authorization policy smart contract SC-PL to perform version control of the data authorization policy set by individual data owners.

In the process 216 , the data server 157 can transmit the certification key corresponding to an individual target user to the corresponding data owner device through the communication circuit 151 or the block chain operation circuit 153 . For example, the data server 157 can transmit the certification key PK1 corresponding to the data owner D1 to the corresponding data owner device 110 through the communication circuit 151 or the block chain operation circuit 153 . In this case, the data owner device 110 may perform the process 218 to use the communication circuit 111 to receive the certification key PK1 provided by the data source system 150 .

Similarly, the data server 157 can transmit the certification key PK2 corresponding to the data owner D2 to the corresponding data owner device 120 through the communication circuit 151 or the block chain operation circuit 153 . In this case, the data owner device 120 may perform the process 218 to receive the certification key PK2 provided by the data source system 150 .

In practice, the data source system 150 can transmit the relevant certification keys to different data owner devices at the same time point, or can transmit the relevant certification keys to different data owner devices at different time points.

In some embodiments, the data server 157 can also transmit the identification data corresponding to the verification key of an individual target user to the corresponding data owner device through the communication circuit 151 or the block chain operation circuit 153 . For example, the data server 157 can transmit the identification data corresponding to the verification key VK1 of the data owner D1 to the corresponding data owner device 110 through the communication circuit 151 or the block chain operation circuit 153 . In this case, the data owner device 110 can use the communication circuit 111 to receive the identification data of the verification key VK1 provided by the data source system 150 . Similarly, the data server 157 can transmit the identification data corresponding to the verification key VK2 of the data owner D2 to the corresponding data owner device 120 through the communication circuit 151 or the block chain operation circuit 153 . In this case, the data owner device 120 may receive the identification data of the verification key VK2 provided by the data source system 150 .

In another embodiment, the data server 157 can use the communication circuit 151 or the block chain operation circuit 153 to transfer the identification data of the data owner device corresponding to the individual target user and the verification key corresponding to the individual target user The identification information of the user, and/or the identification information corresponding to the individual target user, is transmitted to the data service system 160 and/or the block chain system 180. In this case, the communication circuit 161 of the data service system 160 and/or the blockchain system 180 can receive the aforementioned identification data provided by the data source system 150 .

As mentioned above, the data access authority control system 100 can assist the data owner D1 to initiate mortgage shortfall loans to other individuals or investment units through the data service system 160, so as to request other individuals or investment units to lend funds to the data Owner D1. As long as other individuals or investment units agree to lend sufficient funds to the data owner D1, they can assist the data owner D1 to solve the problem of housing loan shortfall.

When the target user wants to use the data service system 160 to perform a predetermined activity, the corresponding data owner device can perform the process 220 in FIG. 2 to require the target user to input some relatively low-sensitivity data (data of relatively low-sensitivity ), and one or more data to be verified (data to be verified), as the relevant data of the predetermined activity.

For example, in this embodiment, when the data owner D1 wants to use the data service system 160 to carry out a home loan shortfall loan activity, the data owner device 110 can be controlled to log into the data service system 160 to create a home loan shortfall loan case (home- loan-gap/housing-loan-gap lending case) to initiate a home-loan-gap/housing-loan-gap lending activity. In this case, the web server 167 of the data service system 160 can generate and send relevant data filling pages to the data owner device 110, and the communication circuit 111 of the data owner device 110 can receive the information sent by the web server 167. Fill in the information page.

At this time, the control circuit 117 can perform the process 220 to control the display device 115 to display the data filling page provided by the web server 167, so as to require the target user (for example, the data owner D1 in this embodiment) to input some relatively low Sensitivity data, and one or more data to be verified.

The aforementioned relatively low-sensitivity information may include user nickname, total borrowing amount, loan period, loan interest rate, interest payment cycle, principal amortization cycle, and/or other loan conditions, etc. General information about the personal privacy of the applicant D1. In some embodiments, the aforementioned relatively low-sensitivity data may also include basic data of a loan target (for example, in this example, the house to be purchased by the data owner D1), such as geographic area, house age, floor wait.

In one embodiment, the aforementioned data to be verified is a housing price. In another embodiment, the aforementioned data to be verified is a loan amount. In another embodiment, the aforementioned data to be verified are a house price and a loan amount. In another embodiment, the aforementioned data to be verified is a unique password assigned to the data owner D1 by the operating unit of the data source system 150 . In another embodiment, the aforementioned data to be verified is a unique identification data corresponding to the data owner D1 (for example, the ID number of the data owner D1, the unified number, or the information provided by the operating unit of the data source system 150 a document number of a loan document for data owner D1).

In some embodiments, the data to be verified that the display device 115 requires the data owner D1 to input may only include one of the above-mentioned multiple different data items. In some other embodiments, the data to be verified required by the display device 115 to be input by the data owner D1 may simultaneously include multiple items among the aforementioned multiple different data items.

In practical applications, the data owner D1 can input the aforementioned relatively low-sensitivity data and the data to be verified into the data owner device 110 through various suitable input interfaces (not shown in the figure). In this case, the control circuit 117 of the data owner device 110 can perform the process 222 to receive the relatively low-sensitivity data input by the target user (for example, the data owner D1 in this embodiment) through the corresponding input interface. and pending verification.

In the process 224 , the control circuit 117 can generate a corresponding target data according to the received relatively low-sensitivity data. During operation, the control circuit 117 can organize and/or encode the received relatively low-sensitivity data into a suitable format, so as to generate a corresponding target data, as a basis for the mortgage default loan case initiated by the data owner D1 Descriptive information.

In some embodiments, the data filling page provided by the web server 167 may additionally require the data owner D1 to input some relatively high-sensitivity data (data of relatively high-sensitivity) related to the personal information of the data owner D1 , such as name, occupation, age, gender, income level, marital status, number of children, and/or credit rating.

In this case, the data owner D1 can input the aforementioned relatively low-sensitivity data, data to be verified, and relatively high-sensitivity data into the data owner device 110 through various suitable input interfaces. In this embodiment, the control circuit 117 may also receive the relatively high-sensitivity data input by the data owner D1 through various suitable input interfaces in the process 222 . In addition, in the process 224 , the control circuit 117 may also include the aforementioned relatively high-sensitivity data into the target data.

It can be seen from the foregoing description that the target data generated by the control circuit 117 in the process 224 may only include relatively low-sensitivity data corresponding to the data owner D1, or additionally include relatively high-sensitivity data corresponding to the data owner D1. material.

In the process 226, the control circuit 117 can use the proof key PK1 to generate a proof value PF1 according to the received data to be verified. In practice, the control circuit 117 can execute a proof value generation program provided in advance by the data source system 150 (or the data server 157) (or a proof value generation rule preset according to the data server 157), A proof value PF1 is generated by using the proof key PK1 according to the received data to be verified. During operation, the control circuit 117 can use the proof key PK1 to perform various suitable zero-knowledge proof algorithms (zero-knowledge proof algorithm) operations on one or more data to be verified provided by the data owner D1 to generate other devices A corresponding proof value PF1 of the content cannot be parsed out. In the data access authority control system 100, only the blockchain system 180 can use the corresponding zero-knowledge proof smart contract SC-ZKP to verify whether the proof value PF1 is correct.

It can be seen from the foregoing description that the proof value PF1 is essentially generated based on one or more constraint items that only the data owner D1 and the operating unit of the data source system 150 know correct information. If the data to be verified input by the data owner D1 are all correct, then the proof value PF1 generated by the control circuit 117 can be used to prove the authenticity of the identity of the data owner D1.

As shown in FIG. 2 , when the data owner D1 wants to enable the data access control service of the data access control system 100 , the data owner device 110 can be used to perform a process 228 . In this case, the blockchain system 180 will proceed to the process 230 accordingly.

In the process 228 , the control circuit 117 of the data owner device 110 generates an authorization service activation request, and transmits the authorization service activation request to the blockchain system 180 through the communication circuit 111 or the blockchain computing circuit 113 .

In the process 230, the blockchain system 180 will execute the aforementioned beacon management smart contract SC-TM according to the authorization service activation request to generate a corresponding an authorization token, and transfer the authorization token to the data owner device 110 . In one embodiment, the token management smart contract SC-TM can also set one or more corresponding validity check parameters for the authorization token, for example, a valid time-slots of use, a valid Expiration period, a valid geographic region, a valid owner, and/or a valid source network address, etc.

At this time, the communication circuit 111 or the block chain operation circuit 113 of the data owner device 110 can perform the process 302 in FIG. The owner device 110 becomes the current owner of the authorization token.

In process 304, the control circuit 117 of the data owner device 110 can encrypt the data authorization policy agreed by the target user under the control of the target user (data owner D1 in this example) to generate a corresponding The encrypted data authorization policy. For example, the control circuit 117 can set a corresponding data authorization policy for the data service system 160 according to the control of the data owner D1. The aforementioned data authorization policy may include the authorized object (for example, in this example, the identification data of the data service system 160), the subject of the authorized data, the content of the authorization, the upper limit of the number of authorizations, the period of authorization, the time limit of the authorization, the geographical area where the data is located, and the storage Some or all of the multiple parameters such as the identification information of the data source system 150 (for example, the address of a specific smart contract deployed in the blockchain system 180 by the operator of the data source system 150 ) and other parameters of the sensitive data.

In some embodiments, the control circuit 117 can also set corresponding data authorization policies for other data requesters. During operation, the control circuit 117 can use a predetermined encryption key to encrypt individual data authorization policies to generate a corresponding data authorization policy ciphertext.

In practice, the control circuit 117 may use the same encryption key or use different encryption keys when encrypting different data authorization policies.

In the process 306 , the control circuit 117 can utilize the communication circuit 111 or the blockchain operation circuit 113 to transmit the generated one or more data authorization policy ciphertexts to the blockchain system 180 by using the authorization token. In addition, the control circuit 117 can also use the communication circuit 111 or the block chain operation circuit 113 to transmit one or more target keys that can be used to decrypt the one or more data authorization policy ciphertexts to The blockchain system 180 or the data service system 160 .

In the process 308, the block chain system 180 can record one or more data authorization policy ciphertexts transmitted from the data owner device 110 in the aforementioned authorization policy smart contract SC-PL, as a data owner device 110 corresponds to a current data authorization policy (current data authorization policy).

It can be seen from the foregoing description that the data authorization policy ciphertext generated by the data owner device 110 and including the data authorization policy will be recorded in the blockchain system 180 . In this way, only a device that has the correct decryption key and has the right to access the blockchain system 180 can read and decrypt the data authorization policy ciphertext from the blockchain system 180 . Such an approach can greatly reduce the possibility of the data authorization policy set by the data owner device 110 being stolen or tampered with by malicious persons.

In the data access authority control system 100, users corresponding to other data owner devices (for example, the data owner D2 corresponding to the data owner device 120) can use the relevant data owner device in the same manner as described above, Encrypt the data authorization policy for the data service system 160 (or for the data service system 160 and other data requesters) to generate one or more corresponding data authorization policy ciphertexts, and encrypt the generated data authorization policies The document is transmitted to the blockchain system 180, and is recorded in the authorization policy smart contract SC-PL by the blockchain system 180.

In practice, the blockchain system 180 can only establish a single authorization policy smart contract SC-PL, and record multiple data authorization policy ciphertexts generated by different data owners in the same authorization policy smart contract SC-PL middle.

Alternatively, the blockchain system 180 can also establish different authorization policy smart contracts SC-PL for different data owners. For example, the blockchain system 180 can establish a dedicated authorization policy smart contract SC-PL for the data owner D1 to record one or more data authorization policy ciphertexts generated by the data owner D1, and provide D2 establishes another different authorization policy smart contract SC-PL to record one or more data authorization policy ciphertexts generated by the data owner D2.

In the process 310 , the control circuit 117 of the data owner device 110 can use the communication circuit 111 to transmit the aforementioned target data and the proof value PF1 to the data service system 160 . In practice, the control circuit 117 can use the communication circuit 111 to transmit the target data and the proof value PF1 to the data service system 160 at the same time. Alternatively, the control circuit 117 can also use the communication circuit 111 to transmit the target data and the proof value PF1 to the data service system 160 at different time points.

At this time, the communication circuit 161 of the data service system 160 can perform the process 312 to receive the target data and the proof value PF1 transmitted from the data owner device 110 . The web server 167 can store the target data received by the communication circuit 161 into the database 165 .

In some embodiments, the control circuit 117 of the data owner device 110 can also use the communication circuit 111 to transmit the identification data corresponding to the verification key VK1 of the data owner D1 to the data service system 160 . In this case, the communication circuit 161 of the data service system 160 can also receive the identification data of the verification key VK1 transmitted from the data owner device 110 .

In practice, the control circuit 117 can use the communication circuit 111 to simultaneously transmit the target data and the proof value PF1 to the data service system 160 . Alternatively, the control circuit 117 can also use the communication circuit 111 to transmit the target data and the proof value PF1 to the data service system 160 at different time points.

As shown in FIG. 3 , after the data service system 160 receives the target data and the proof value PF1 from the data owner device 110 , it can cooperate with the blockchain system 180 to verify the authenticity of all or part of the content of the target data.

For example, in the process 314, the web server 167 can use the communication circuit 161 or the block chain operation circuit 163 to transmit the proof value PF1 generated by the data owner device 110 to the block chain system 180, and send a proof value verification request ( proof verification request) to the blockchain system 180 to require the blockchain system 180 to verify the proof value PF1. In some embodiments, the aforementioned certification value verification request may include an identification data corresponding to the data owner device 110, an identification data corresponding to the data owner D1, or a verification key corresponding to the data owner D1 An identification data of VK1.

In the process 316, the blockchain system 180 can receive the proof value PF1 from the data service system 160, and the related proof value verification requirements.

In the process 318, the blockchain system 180 can execute the corresponding zero-knowledge proof smart contract SC-ZKP to check the correctness of the proof value PF1. For example, the block chain system 180 can be based on the identification data corresponding to the data owner's device 110 sent by the data server 157, the identification data corresponding to the verification key VK1 of the data owner D1, and/or the identification data corresponding to the data owner's device 110. An identification data of the user D1 to find out the corresponding zero-knowledge proof smart contract SC-ZKP. For another example, the blockchain system 180 can extract an identification data corresponding to the data owner device 110, an identification data corresponding to the data owner D1, or a verification corresponding to the data owner D1 from the certification value verification request. An identification data of the key VK1, and find out the corresponding zero-knowledge proof smart contract SC-ZKP according to the extracted identification data. Next, the blockchain system 180 can execute the zero-knowledge proof smart contract SC-ZKP to find out the corresponding verification key VK1 according to the aforementioned identification information, and use the verification key VK1 to perform a suitable zero-knowledge proof on the proof value PF1 The verification algorithm (zero-knowledge proof verification algorithm) operates to determine whether the proof value PF1 satisfies the aforementioned first predetermined verification rule, thereby checking the correctness of the proof value PF1.

It can be seen from the foregoing description that the proof value PF1 is essentially generated based on one or more constraint items that only the data owner D1 and the operating unit of the data source system 150 know correct information. Therefore, the blockchain system 180 can execute the zero-knowledge proof smart contract SC-ZKP, and use the verification key VK1 to perform an appropriate zero-knowledge proof verification algorithm on the proof value PF1 to determine whether the proof value PF1 satisfies the aforementioned first predetermined verification All constraint items in the rule.

If all the data to be verified provided by the data owner D1 to the data owner device 110 are correct, then the zero-knowledge proof verification algorithm executed by the zero-knowledge proof smart contract SC-ZKP can obtain a representative proof value PF1 that satisfies Verification results of all constraint items in the aforementioned first predetermined verification rule. In this case, the blockchain system 180 can determine that the proof value PF1 is correct without analyzing the content of the proof value PF1.

On the contrary, if the control circuit 117 of the data owner device 110 generates the proof value PF1 based on the data to be verified is wrong, then the zero-knowledge proof verification algorithm executed by the zero-knowledge proof smart contract SC-ZKP can obtain a representative The proof value PF1 cannot satisfy the verification results of all constraint items in the aforementioned first predetermined verification rule. In this case, the blockchain system 180 can determine that the proof value PF1 is incorrect without analyzing the content of the proof value PF1.

As shown in FIG. 3 , if the blockchain system 180 determines that the proof value PF1 is incorrect, the process 320 can be performed. On the contrary, if the blockchain system 180 determines that the proof value PF1 is correct, the process 322 can be performed.

In the process 320 , the blockchain system 180 may send a proof-failed notification to the data service system 160 .

In the process 322 , the blockchain system 180 may send a verification success notification to the data service system 160 .

In the process 324 , the web server 167 of the data service system 160 can receive the proof value error notification from the blockchain system 180 through the communication circuit 161 or the blockchain computing circuit 163 .

In the process 326, the web server 167 can notify the data owner device 110 through the communication circuit 161, so that the data owner D1 can know that the data to be verified provided by it has not passed the check of the zero-knowledge proof mechanism.

In the process 328 , the web server 167 can receive the verification success notification from the blockchain system 180 through the communication circuit 161 or the blockchain computing circuit 163 . When the web server 167 receives the verification success notification, it means that the proof value PF1 generated by the data owner device 110 has passed the verification of the zero-knowledge proof (ZKP) mechanism adopted by the blockchain system 180 . Therefore, the web server 167 can determine that the authenticity of the identity of the data owner D1 who created the target data has passed the verification based on the verification result of the blockchain system 180 (that is, it means that the data owner D1 is really directed to the data source system 150 The person who applied for a housing loan from the operating unit of the target company), and based on this, it can be further judged that the total loan amount in the target data is information supported by facts.

In this case, the web server 167 can perform the process 330 to mark the target data. For example, the web server 167 may assign an identifiable symbol, pattern, annotation, label, or eye-catching mark to the target data as a mark of the target data. In practical applications, the web server 167 may display the above-mentioned mark at the same time when displaying the target data, so that people who browse the target data can know that the authenticity of all or part of the target data has passed the authentication.

For another example, the web server 167 can assign the target data to a specific data category, so that people who browse the target data can know the authenticity of all or part of the target data passed through the blockchain. Authentication of the system 180 .

In some embodiments, the web server 167 may also store the target data sent by the data owner device 110 into the database 165 after receiving the verification success notification from the blockchain system 180 . In this case, the aforementioned process 330 can be omitted.

As mentioned above, in some embodiments, the aforementioned first predetermined verification rule may also include a constraint item that the difference between a house price minus a loan amount will be equal to a predetermined shortfall. In this case, the proof value verification request sent by the web server 167 to the blockchain system 180 in the process 314 may also include the total loan amount in the target data. On the other hand, when the blockchain system 180 executes the zero-knowledge proof smart contract SC-ZKP in the aforementioned process 318, the zero-knowledge proof smart contract SC-ZKP can also set the total amount of loans transmitted from the web server 167 to the aforementioned Constrain the predetermined gap in the items, and use the verification key VK1 to perform a suitable zero-knowledge proof verification algorithm operation on the proof value PF1 to determine whether the proof value PF1 satisfies all the constraint items in the first predetermined verification rule.

As can be seen from the above description, if all the data to be verified provided by the data owner D1 are correct, then the zero-knowledge proof verification algorithm executed by the zero-knowledge proof smart contract SC-ZKP can obtain a representative proof value PF1 that satisfies Verification results of all constraint items in the aforementioned first predetermined verification rule. In this way, the blockchain system 180 can determine that the proof value PF1 is correct without analyzing the content of the proof value PF1.

In this case, the web server 167 can further confirm the correctness of the loan amount in the target data created by the data owner D1 according to the verification result of the blockchain system 180 .

It can be seen from the foregoing description that when the data owner D1 encounters a problem of a mortgage shortfall, the data owner device 110 can be manipulated to log into the data service system 160 to create a descriptive data (that is, the aforementioned target data) of a mortgage shortfall loan case. Initiate a housing loan gap loan activity. After the data service system 160 receives the target data from the data owner's device 110, it can request the blockchain system 180 to verify the proof value PF1 generated by the data owner's device 110 and corresponding to the target data, so as to verify the target Authenticity of information.

The blockchain system 180 can execute the zero-knowledge proof smart contract SC-ZKP deployed by the data source system 150 to check the correctness of the proof value PF1 by using a zero-knowledge proof (ZKP) mechanism. The data service system 160 can verify the authenticity of all or part of the content of the target data according to the verification result of the proof value PF1 by the blockchain system 180 .

During the operation of the blockchain system 180 executing the zero-knowledge proof smart contract SC-ZKP to check the proof value PF1, the data service system 160 does not need to provide too much information related to the data owner D1 (for example, house price and verification value). loan amount) to the blockchain system 180. Such a method can minimize the amount of information required by the blockchain system 180 to verify the proof value PF1, so as to greatly reduce the possibility of leakage of relevant data of the data owner D1.

In addition, during the operation of the blockchain system 180 executing the zero-knowledge proof smart contract SC-ZKP to check the proof value PF1, the blockchain system 180 does not need to interact with the data owner device 110 or the data source system 150, so The operation burden of the data owner device 110 and the data source system 150 will not be increased. Such a method can also effectively reduce the degree of involvement of the data owner D1 or the operating unit of the data source system 150 , thereby reducing the risk of leakage of sensitive data by the data owner D1 or the operating unit of the data source system 150 .

On the other hand, when the investor (or called the lender) wants to know whether there is any mortgage shortfall loan activity initiated by the borrower on the data service system 160 , he can control the corresponding data requester's device to log into the data service system 160 . For convenience of description, it is assumed below that the aforementioned investor is the data requester R1 corresponding to the data requester device 130 .

When the data requester R1 wants to know whether there is any shortfall mortgage loan activity initiated by any borrower on the data service system 160 , the corresponding data requester device 130 can be controlled to log into the data service system 160 .

In this case, the control circuit 135 of the data requester device 130 can perform the process 402 in FIG. 4 to send a data browsing request to the data service system 160 through the communication circuit 131 .

At this time, the web server 167 of the data service system 160 can perform the process 404 to receive the data browsing request from the data requester device 130 through the communication circuit 161 .

In the process 406 , the web server 167 may use the communication circuit 161 to transmit one or more candidate data including the aforementioned target data created by the data owner D1 to the data requester device 130 .

In the process 408, the control circuit 135 can receive the candidate data from the data service system 160 through the communication circuit 131, and can control the display device 133 to display the candidate data. The data requester R1 can browse the content of the candidate data to evaluate whether there is a target case worthy of further research. It can be seen from the foregoing description that the target data among the candidate data sent by the data service system 160 to the data requester device 130 is the descriptive data of the mortgage shortfall loan case created by the data owner D1.

In general, investors may need to study some further information or documents about the target case before deciding whether to lend money to the borrower corresponding to the target case. For example, the aforesaid stored in the database 155 of the data source system 150, sensitive data related to individual loan applicants (for example, credit evaluation reports, appraisal reports, and/or loan contract documents/loan contract draft documents, etc.), It may be an auxiliary material worthy of further reading and research by investors when evaluating relevant housing loan shortfall loan cases.

For the convenience of explanation, it is assumed that the data requester R1 is interested in the shortfall mortgage loan case corresponding to the target data, and thus wants to obtain the specific sensitive data corresponding to the target data stored in the data source system 150 (for example, related to the data owned by the data) Credit evaluation report, appraisal report, and/or loan contract document/loan contract draft document related to or D1) for further reading and research.

In this case, the data requester R1 can issue a selection command corresponding to the target data to the data requester device 130 through various suitable input interfaces (not shown in the figure). At this time, the control circuit 135 of the data requester device 130 can perform the process 410 to generate a sensitive data request corresponding to the target data. The aforementioned sensitive information request can be used to request certain specific sensitive information (for example, credit evaluation report, appraisal report, and/or loan contract documents related to the data owner D1) corresponding to the target information. /loan contract draft document).

In the process 412 , the control circuit 135 can use the communication circuit 131 to transmit the alert data request to the data service system 160 .

In the process 414 , the web server 167 may receive the sensitive data request from the data requester device 130 through the communication circuit 161 .

In this embodiment, after the web server 167 receives the sensitive data request from the data requester device 130, it will not immediately provide the corresponding smart data to the data requester device 130, but will further check Whether the data requester device 130 has the corresponding data access qualification. Therefore, after the web server 167 receives the sensitive data request from the data requester device 130 , the process 416 can be performed.

In the process 416, the web server 167 may generate a data access request (data read request) corresponding to the target requester (for example, in this example, the data requester R1) and the aforementioned sensitive data request, and may Using the communication circuit 161 or the block chain operation circuit 163, the data access request is sent to the data owner device 110 corresponding to the data owner D1.

In the process 418 , the control circuit 117 of the data owner device 110 can receive the data access request from the data service system 160 through the communication circuit 111 or the blockchain computing circuit 113 .

In the process 420 , the control circuit 117 may ask the target user (for example, the data owner D1 in this example) whether to accept the data access request from the data service system 160 through a suitable mechanism.

For example, the control circuit 117 can control the display device 115 to display an inquiry screen including relevant information of the data access request, so as to ask the data owner D1 whether to accept the data access request. For another example, the control circuit 117 can control the sound generating circuit (not shown in the figure) in the data owner device 110 to generate a related voice prompt message to ask the data owner D1 whether to accept the data access request.

If the data owner D1 rejects the data access request from the data service system 160 , the data owner device 110 may proceed to the process 422 . On the contrary, if the data owner D1 accepts the data access request from the data service system 160 , the data owner device 110 can proceed to the process 424 .

In the process 422 , the control circuit 117 can use the communication circuit 111 or the blockchain computing circuit 113 to send a rejection notification to the data service system 160 .

In the process 424, the control circuit 117 can use the communication circuit 111 or the block chain operation circuit 113 to transmit an identification data of the authorization token corresponding to the data owner device 110 (hereinafter referred to as the authorization token identification data, authorization token identification data) to the data service system 160.

In the process 426, the web server 167 can receive the rejection notification from the data owner device 110 through the communication circuit 161 or the block chain operation circuit 163, and use the communication circuit 161 to send a corresponding rejection message to the data requester device 130.

In the process 428, the control circuit 135 can receive the rejection message from the data service system 160 through the communication circuit 131, and can control the display device 133 to display the rejection message for the data requester R1 to know the relevant information.

In the process 430 , the web server 167 can receive the authorization beacon identification data transmitted from the data owner's device 110 through the communication circuit 161 or the blockchain computing circuit 163 .

It can be seen from the foregoing description that when the web server 167 receives the authorization beacon identification data transmitted from the data owner device 110 , it represents the data owner D1 accepting the data access request generated by the data service system 160 . Therefore, the web server 167 can perform the process 432 to generate a read token request (read token request) including the authorization token identification data corresponding to the data owner device 110, and can utilize the communication circuit 161 or the block chain The computing circuit 163 transmits the access beacon request to the blockchain system 180 . The aforementioned access token request is used to request the blockchain system 180 to provide an access token (read token) corresponding to specific sensitive data related to the target data.

In this case, the block chain system 180 can perform the process 502 in FIG. 5 to receive the beacon access request from the data service system 160 . Please note that after receiving the access beacon request from the data service system 160, the blockchain system 180 will not immediately provide the corresponding access beacon to the data service system 160, but will further check the data service Whether the system 160 has corresponding data access authority.

In the process 504, the blockchain system 180 can execute the authorization policy smart contract SC-PL to check whether the request for obtaining the beacon conforms to the predetermined authorization policy. During operation, the blockchain system 180 can obtain a corresponding authorization token identification data according to the access token request. Since only the data owner device 110 has the right to use the authorization beacon corresponding to the authorization beacon identification data, the blockchain system 180 can find out the authorization policy smart contract SC-PL based on the authorization beacon identification data. The data authorization policy ciphertext generated by the data owner device 110 .

The blockchain system 180 can use the aforementioned target key to decrypt the ciphertext of the data authorization policy to obtain the decrypted data authorization policy. Next, the block chain system 180 can judge whether the access beacon request complies with the data authorization policy set by the data owner D1 according to the content of the decrypted data authorization policy.

If the data service system 160 does not belong to the authorized object agreed by the decrypted data authorization policy, or the specific sensitive data corresponding to the access signal request does not belong to the authorized data object, the blockchain system 180 can determine that the access signal The mark request does not comply with the data authorization policy set by the data owner D1. In this case, the blockchain system 180 can proceed to process 506 .

Conversely, if the data service system 160 belongs to the authorized object agreed by the decrypted data authorization policy, and the specific sensitive data corresponding to the access beacon request belongs to the authorized data object, then the block chain system 180 can determine that the access beacon The request complies with the data authorization policy set by the data owner D1. In this case, the blockchain system 180 can proceed to process 510 .

In the process 506 , the blockchain system 180 can generate and send an ineligibility notification to the data service system 160 . At this time, the web server 167 can perform the process 508 to receive the ineligibility notification from the blockchain system 180 through the communication circuit 161 or the blockchain computing circuit 163, and accordingly reject the alertness proposed by the data requester device 130. Data request.

In the process 510, the blockchain system 180 can execute the token management smart contract SC-TM to check the validity of an authorization token corresponding to the authorization token identification data. For example, the beacon management smart contract SC-TM can check whether the relevant parameters of the authorized beacon are consistent with the validity checking parameters previously set by the beacon management smart contract SC-TM in the process 230 .

In one embodiment, the token management smart contract SC-TM can determine the authorization token as invalid (inactive) when the local parameters of the authorization token do not meet the validity check parameters set in the aforementioned process 230 ) beacon. In another embodiment, the token management smart contract SC-TM will judge the authorization token as invalid only when all the parameters of the authorization token do not meet the validity check parameters set in the aforementioned process 230 , otherwise the authorized beacon will be determined as an active beacon.

If the token management smart contract SC-TM determines that the authorization token is an invalid token, the token management smart contract SC-TM will proceed to process 512 . On the contrary, if the token management smart contract SC-TM determines that the authorization token is a valid token, the token management smart contract SC-TM will proceed to the process 518 .

In the process 512 , the token management smart contract SC-TM can generate and send an authorization token invalidation notification to the data service system 160 . At this time, the web server 167 can perform the process 514 to receive the authorization token invalidation notification through the communication circuit 161 or the block chain operation circuit 163 . In this case, the web server 167 may perform the process 516 to reject the sensitive data request from the data requester device 130 .

In the process 518 , the token management smart contract SC-TM can generate and transfer a read token corresponding to the authorization token to the data service system 160 . During operation, the beacon management smart contract SC-TM can set a corresponding expiry date for the access token, for example, 5 days, 10 days, 1 week, 2 weeks, 1 month and so on. The validity period set by the token management smart contract SC-TM for the access token will be equal to or shorter than the validity period of the authorization token. In practice, the token management smart contract SC-TM can establish an appropriate data association or validity association between the access token and the authorization token, and can jointly and jointly Deactivate the Access Beacon.

In the process 520 , the web server 167 can obtain the access token transferred from the blockchain system 180 through the communication circuit 161 or the blockchain computing circuit 163 .

In the process 522 , the web server 167 can use the communication circuit 161 or the blockchain computing circuit 163 to send a sensitive data request to the data source system 150 , and transfer the access token to the data source system 150 . The aforementioned sensitive information request can be used to request certain specific sensitive information (for example, credit evaluation report, appraisal report, and/or loan contract documents related to the data owner D1) corresponding to the target information. /loan contract draft document). In practice, the sensitive data request sent by the data service system 160 to the data source system 150 in the process 522 may be exactly the same as the sensitive data request received by the data service system 160 in the process 414, or may be in the data format or Other aspects that do not affect its main function are different.

In this case, the data source system 150 can perform the process 524 .

In the process 524, the data server 157 can receive the sensitive data request from the data service system 160 through the communication circuit 151 or the block chain operation circuit 153, and obtain the access token transferred from the data service system 160 .

Please note that the block chain system 180 can also reverse the order of the judgment process of the aforementioned process 504 and process 510 . In other words, after the blockchain system 180 receives the beacon access request from the data service system 160, it may first perform the process 510, and only proceed to the process 504 when it determines that the authorized token is a valid beacon. In this case, after the blockchain system 180 determines in the process 504 that the access beacon request complies with the authorization policy, the aforementioned process 518 can be performed.

From the flow chart in Figure 5, it can be seen that only when the beacon management smart contract SC-TM determines that the authorized token corresponding to the data owner D1 is a valid beacon, the beacon management smart contract SC-TM will generate an authorization token corresponding to the data owner D1. The authorization beacon has an associated access beacon and transfers the access beacon to the data service system 160 .

In other words, if the blockchain system 180 sends the authorization token corresponding to the data owner's device 110 due to various reasons (for example, the data owner D1 terminates the service of the data access authority control system 100, or is suspended) If deactivated, the blockchain system 180 will no longer provide access beacons to the data service system 160 or other data requesters to access the sensitive data of the data owner D1. Apparently, such a mechanism can avoid the possibility of improper access to the sensitive data of the data owner D1, and help to improve the degree of protection of the sensitive data of the data owner D1.

In addition, only when the blockchain system 180 determines that the request for accessing the beacon conforms to the data authorization policy set by the data owner D1, the beacon management smart contract SC-TM will generate a token associated with the authorized beacon. Access the beacon, and transfer the access beacon to the data service system 160 . Therefore, even if the access beacon request generated by the data service system 160 is intercepted by other malicious devices that do not comply with the data authorization policy, the blockchain system 180 will not transfer the access beacon to these malicious devices.

Please note that after receiving the sensitive data request from the data service system 160, the data source system 150 will not immediately provide the corresponding sensitive data to the data service system 160, but will request the blockchain system 180 to verify the data. The validity (activity) of the access beacon is used to confirm whether the data service system 160 has the corresponding data access authority.

Therefore, the data source system 150 may perform the process 602 in FIG. 6 after performing the process 524 .

In the process 602, the data server 157 can use the communication circuit 151 or the blockchain operation circuit 153 to transfer the access token to the blockchain system 180, and request the blockchain system 180 to verify the validity of the access token. sex. In this case, the blockchain system 180 may proceed to process 604 accordingly.

In the process 604 , the blockchain system 180 can obtain the access token transferred from the data source system 150 .

Then, the block chain system 180 can perform the process 606 to execute the token management smart contract SC-TM to verify the validity of the token. As mentioned above, the beacon management smart contract SC-TM can set a corresponding validity period for the access token in the aforementioned process 518 . Therefore, in the process 606 , the token management smart contract SC-TM can check whether the time when the blockchain system 180 obtains the access token exceeds the validity period set in the process 518 .

If the time for the blockchain system 180 to obtain the access token has exceeded the validity period set by the beacon management smart contract SC-TM in process 518, the beacon management smart contract SC-TM can use the access token It is determined as an invalid (inactive) beacon, and go to process 608 .

Conversely, if the time when the blockchain system 180 obtains the access token has not exceeded the validity period set by the beacon management smart contract SC-TM in process 518, the beacon management smart contract SC-TM can use the access token The beacon is determined to be an active beacon, and the process 614 is performed.

In another embodiment, when the blockchain system 180 executes the token management smart contract SC-TM to verify the validity of the access token, it will check the access token before it is transferred to the blockchain system 180, Whether it is transferred from the data service system 160 to the data source system 150, and also check whether a point in time when the data source system 150 transfers the access token to the blockchain system 180 exceeds the validity period. In this embodiment, only when the block chain system 180 obtains the access token has not exceeded the validity period, and the access signal is transferred to the block chain system 180 by the data service system 160 In the case of the data source system 150 , the beacon management smart contract SC-TM will determine the access beacon as a valid beacon, and proceed to process 614 . Otherwise, the token management smart contract SC-TM will determine the access token as an invalid token, and proceed to process 608 .

In the process 608 , the beacon management smart contract SC-TM can generate and send a verification failure notification to the data source system 150 . At this time, the data server 157 can correspondingly perform the process 610 to receive the verification failure notification through the communication circuit 151 or the block chain operation circuit 153 . Next, the data server 157 can perform the process 612 to reject the sensitive data request from the data service system 160 , and can use the communication circuit 151 or the block chain operation circuit 153 to send a corresponding rejection notice to the data service system 160 .

In the process 614, the beacon management smart contract SC-TM can generate and send a verification success notification to the data source system 150, and optionally deactivate the access beacon. In this case, the data server 157 can correspondingly perform the process 616 to receive the verification success notification through the communication circuit 151 or the block chain operation circuit 153 .

In the process 618, the data server 157 can find out the sensitive data corresponding to the target data (for example, the credit evaluation report, appraisal report, etc. report, and/or loan contract document/loan contract draft document), and can use the communication circuit 151 or block chain computing circuit 153 to transmit the sensitive data corresponding to the target data to the data service system 160. At this time, the web server 167 can correspondingly perform the process 620 to receive the sensitive data transmitted from the data source system 150 through the communication circuit 161 or the block chain operation circuit 163 . In addition, the web server 167 can also use the communication circuit 151 or the blockchain computing circuit 153 to transmit the sensitive data to the data requester device 130 .

At this time, the control circuit 135 of the data requester device 130 can perform the process 622 to receive the alert data from the data service system 160 through the communication circuit 131 .

In the process 624, the control circuit 135 can control the display device 133 to display the sensitive data corresponding to the target data (for example, the credit evaluation report, the appraisal report, and/or the loan contract document/loan contract related to the data owner D1 draft document). In this way, the data requester R1 can study the aforesaid sensitivity data to evaluate whether to lend money to the borrower of a specific mortgage shortfall loan case (that is, in this embodiment, the data owner D1 corresponding to the target data ).

After the data requester R1 decides to lend money to the data owner D1, the data service system 160 can adopt various known appropriate mechanisms to assist the data requester R1 and the data owner D1 to realize the processing of related information flow and/or cash flow Operation.

In practical applications, the data service system 160 can adopt various known appropriate mechanisms to match the borrowing needs of different borrowers and the investment needs of different investors, so as to help more borrowers to use the data service system 160 Assistance in obtaining the required funds.

On the other hand, as shown in FIG. 6 , after the beacon management smart contract SC-TM determines that the access beacon is a valid beacon, it can also proceed to process 626 to record an acquisition time of the access beacon (for example, Occurrence time of process 604) or a verification time (eg, occurrence time of process 606 or process 614).

The relevant time information of the access beacon recorded by the blockchain system 180 in the process 626 can be used as evidence that the data source system 150 provides the relevant alert data of the data owner D1 to the data service system 160 .

It can be seen from the flow chart in FIG. 6 that only when the beacon management smart contract SC-TM also determines that the access beacon is a valid beacon, the data source system 150 will request the alert corresponding to the alert data request. The data is provided to the data service system 160 .

In other words, as long as the access beacon is invalid, the data source system 150 will not provide the relevant sensitive data of the data owner D1 to the data service system 160 . Therefore, the aforementioned data source system 150 uses the block chain system 180 to verify the validity of the access beacon, which can reduce the possibility of improper access to the sensitive data of the data owner D1 and help to improve the security of the data. The degree of protection of sensitive data related to owner D1.

In addition, based on the characteristics of the block chain system 180, the relevant time information of the access beacon recorded in the block chain system 180 is difficult to be tampered with, so it can be used as the data source system 150 to provide the relevant data owner D1. Evidence provided by the smart data to the data service system 160 helps reduce the possibility of disputes between the data source system 150 and the data service system 160 that are difficult to clarify.

Furthermore, theoretically, each time the data service system 160 provides sensitive data to the device of the data requester, it will generate a corresponding time record of accessing the beacon on the blockchain system 180 . Such a mechanism also helps to avoid the possibility that the data service system 160 leaks the sensitive data of the data owner to those who have no right to access the data without authorization.

In practice, in addition to transferring the access token to the blockchain system 180, the data source system 150 can also transmit the sensitive data request from the data service system 160 to the blockchain system 180, and request the area The blockchain system 180 verifies the validity of the alert data request.

For example, the data server 157 can use the communication circuit 151 or the block chain operation circuit 153 to transmit a sensitive data request to the block chain system 180, and request the block chain system 180 to execute the authorization policy smart contract SC-PL to verify Whether the sensitive data request complies with the intended authorization policy. Since the access token corresponds to the authorization token that the data owner device 110 is entitled to use, the blockchain system 180 can find the data generated by the data owner device 110 from the authorization policy smart contract SC-PL Authorization policy ciphertext.

The blockchain system 180 can use the aforementioned target key to decrypt the ciphertext of the data authorization policy to obtain the decrypted data authorization policy. Next, the blockchain system 180 can judge whether the sensitive data request complies with the data authorization policy set by the data owner D1 according to the content of the decrypted data authorization policy.

If the specific sensitive data corresponding to the sensitive data request belongs to the subject of authorized data, the blockchain system 180 may determine that the sensitive data request is a valid data request.

Conversely, if the specific smart data corresponding to the smart data request does not belong to the authorized data subject, the blockchain system 180 may determine that the smart data request is an invalid data request.

In one embodiment, the blockchain system 180 can first check whether the sensitive data request is a qualified data request according to the aforementioned method before performing the process 606, and after determining that the sensitive data request is a qualified data request, Only then proceed to process 606 . In this case, if the blockchain system 180 determines that the alert data request is an unqualified data request, the process 608 may be performed.

In another embodiment, the block chain system 180 may perform the process 606 first, and then check whether the alert data request is a qualified data request according to the aforementioned method after determining that the access beacon is a valid beacon. In this embodiment, the block chain system 180 will proceed to the process 614 only if it determines that the alertness data request is a qualified data request. If the blockchain system 180 determines that the alert data request is an unqualified data request, the process 608 can be performed.

In this way, only when the blockchain system 180 determines that the sensitive data request is a qualified data request, and the beacon management smart contract SC-TM also determines that the access beacon is a valid beacon, the data source system 150 Only then will the alert data corresponding to the alert data request be provided to the data service system 160 .

In other words, as long as the sensitive data request is not qualified or the access beacon is invalid, the data source system 150 will not provide the relevant sensitive data of the data owner D1 to the data service system 160 . Therefore, the aforementioned data source system 150 uses the blockchain system 180 to verify the eligibility of the sensitive data request and verify the validity of the access beacon, which can effectively prevent the relevant sensitive data of the data owner D1 from being improperly The possibility of access helps to greatly enhance the degree of protection of the relevant sensitive data of the data owner D1.

In some embodiments, the data access beacons used by the data service system 160 are finally deregistered by the blockchain system 180, which is equivalent to reclaiming these data access beacons by the blockchain system 180 at last, and These data access beacons are not retrieved by the data source system 150 . Such a structure can effectively reduce the possibility of disputes between the data source system 150 and the data service system 160 .

The data requester R1 can apply to the data service system 160 through the data requester device 130 for accessing relevant sensitive data of other data owners (for example, the data owner D2 ) by referring to the manners of FIGS. 4 to 6 .

In the data access authority control system 100, other data requester devices (for example, the data requester device 140 corresponding to the data requester R2) can also send data to the data service system 160 through the corresponding data requester device in the aforementioned manner. Apply for access to relevant sensitive data of data owner D1 (or other data owners).

Similarly, the data service system 160 can use the blockchain system 180 to check the data access authority of the relevant data requester's device, so as to prevent the sensitive data of the data owner from being easily leaked.

In the data access authority control operation performed by the aforementioned data access authority control system 100, the data source system 150 has significantly fewer processes than the data service system 160, and the data source system 150 provides individual data owners with Before sending sensitive data to the data service system 160, the relevant data request or access beacon request will go through the block chain system 180, and even the related data owner's device will be checked. Such an approach can effectively ensure the legitimacy of the data source system 150 providing the sensitive data of individual data owners to the data service system 160 .

Therefore, from another perspective, adopting the aforementioned data access authority control method can greatly reduce the system operation burden of the data source system 150 and the related data access authority check responsibility.

It can be seen from the above description that during the process of the borrower initiating a home loan shortfall loan activity to the investor through the data service system 160, the data service system 160 can not only promote the demand matching between the borrower and the lender, but also work with the blockchain system 180 to effectively Control access to sensitive data of borrowers. Obviously, the data service system 160 has played a very important role in the aforementioned online matchmaking application for mortgage shortfall loans.

In this way, in the structure where the data source system 150 and the data service system 160 belong to different operators, the data access authority control operation performed by the data service system 160 in conjunction with the blockchain system 180 can greatly reduce the data access authority. The legal responsibilities of the operator of the source system 150. Such a mechanism will help promote the development of online matching applications for mortgage shortfall loans.

It can be known from the foregoing description that the historical version of the data authorization policy ciphertext generated by the data owner device 110 and including the data authorization policy will be recorded in the blockchain system 180 . A device with the correct decryption key and the right to access the blockchain system 180 can read and decrypt the historical version of the data authorization policy ciphertext set by the data owner D1 from the blockchain system 180 . On the one hand, such a mechanism can ensure that the data owner's data authorization policy has sufficient confidentiality, and on the other hand, it can enhance the transparency of the data owner's data authorization policy to interested parties. It is the best of both worlds and will not be too biased towards any party Balance architecture.

Individual data owners can dynamically adjust the data access authority of the data service system 160 or other data service providers through their respective data owner devices. In other words, individual data owners can flexibly adjust the data scope, data type, and/or data content they are willing to authorize to the data service system 160 or other data service providers.

It can be seen from the foregoing description that after receiving the target data from the data owner device 110, the data service system 160 can request the blockchain system 180 to verify the proof value PF1 generated by the data owner device 110 and corresponding to the target data, In order to verify the authenticity of the target data.

The blockchain system 180 can execute the zero-knowledge proof smart contract SC-ZKP deployed by the data source system 150 to check the correctness of the proof value PF1 by using a zero-knowledge proof (ZKP) mechanism. The data service system 160 can verify the authenticity of all or part of the content of the target data according to the verification result of the proof value PF1 by the blockchain system 180 .

During the operation of the blockchain system 180 executing the zero-knowledge proof smart contract SC-ZKP to check the proof value PF1, the data service system 160 does not need to provide the blockchain system 180 with too much information related to the data owner D1. Such a method can minimize the amount of information required by the blockchain system 180 to verify the proof value PF1, so as to greatly reduce the possibility of leakage of relevant data of the data owner D1.

In addition, during the operation of the blockchain system 180 executing the zero-knowledge proof smart contract SC-ZKP to check the proof value PF1, the blockchain system 180 does not need to interact with the data owner device 110 or the data source system 150, so The operation burden of the data owner device 110 and the data source system 150 will not be increased. Such a method can also effectively reduce the degree of involvement of the data owner D1 or the operating unit of the data source system 150 , thereby reducing the risk of data leakage by the data owner D1 or the operating unit of the data source system 150 .

A device that has the right to access the blockchain system 180 and has the correct decryption key can decrypt and check the ciphertext of the data authorization policy recorded in the blockchain system 180 . Therefore, using the blockchain system 180 to replace the traditional centralized authorization server can effectively improve the transparency of the authorization policy management of the data access authority control system 100, thereby reducing the number of conflicts between the data source system 150 and the data owner or data request. the possibility of disputes between them.

Another advantage of the aforementioned data access authority control system 100 is that it can meet various requirements of EU GDPR, and can allow data owners to dynamically adjust their data authorization policies at any time according to their needs, which has higher authorization policy adjustment flexibility.

In addition, the data authorization policy of individual data owners is stored in the blockchain system 180 in an encrypted form, and only devices with the correct decryption key and the right to access the blockchain system 180 can access the data from the blockchain system. 180 to read and decrypt the relevant data authorization policy ciphertext. Such an approach can greatly reduce the risk of data authorization policies set by individual data owners being stolen or tampered with by malicious persons.

Furthermore, the data access beacon used by the data service system 160 each time is finally deregistered by the blockchain system 180 . In other words, these data access beacons are finally recovered by the blockchain system 180 instead of the data source system 150 . Such a framework can effectively reduce the possibility of disputes between the data source system 150 and the data service system 160 .

On the other hand, the data access authority control method adopted by the data access authority control system 100 is to use the block chain system 180 with the framework of relevant smart contracts to automatically complete the application, transfer procedures and authorization of data access tokens. The effectiveness verification procedure of the beacon, the eligibility verification procedure of the smart data request, and the validity verification procedure of the access beacon can greatly improve the efficiency and accuracy of the data access authority control process, and at the same time greatly reduce the required It can effectively avoid the risk that the ciphertext of the relevant authorization policy and the time record of accessing the beacon stored in the blockchain system 180 will be tampered with by malicious people afterwards.

In practice, the number of data owner devices, the number of data requester devices, the number of data source systems 150, and the number of data service systems 160 in the aforementioned data access authority control system 100 can all be determined according to the actual application environment. The requirements are increased, and are not limited to the aspects shown in the foregoing embodiments.

In some embodiments, the aforementioned blockchain computing circuit 113 in the data owner device 110 can be omitted, or the display device 115 and/or the blockchain computing circuit 113 can be separated from the data owner device 110 .

In addition, in some embodiments, the aforementioned display device 133 in the data requester device 130 can be independent from the data requester device 130 .

Likewise, in some embodiments, the database 155 and/or the blockchain computing circuit 153 in the aforementioned data source system 150 can be independent from the data source system 150 .

Please note that the execution sequence of the processes in the foregoing flowcharts is only an exemplary embodiment, and does not limit the actual implementation of the present invention. For example, the process 212 and/or the process 214 in FIG. 2 may be adjusted to be performed before the process 210 or performed simultaneously with the process 210 .

For another example, the process 214 in FIG. 2 can be adjusted to be performed before the process 212 or performed simultaneously with the process 212 .

For another example, the process 216 in FIG. 2 can be adjusted to be performed before the process 206 or the process 208, or performed simultaneously with the process 206 or the process 208.

For another example, the process 220 , the process 222 , and the process 224 in FIG. 2 can be adjusted to be performed before the process 218 .

For another example, the process 228 and the process 230 in FIG. 2 can be adjusted to be performed before the process 218 , the process 220 , the process 222 , the process 224 , or the process 226 .

For another example, the process 310 and the process 312 in FIG. 3 can be adjusted to be performed before the process 302 , the process 304 , or the process 306 .

For another example, the process 304, the process 306, and the process 308 in FIG. 3 can be adjusted to any time point between the process 312 and the process 502.

For another example, in some embodiments, the control circuit 117 of the data owner device 110 may require the data owner D1 to input one or more The data is to be verified and the data owner D1 is required to input some relatively low-sensitivity data after the data owner D1 logs into the data service system 160 . In other words, the data owner D1 may input the aforementioned data to be verified and relatively low-sensitivity data into the data owner device 110 at different time points. In this case, the process 226 can be adjusted to be performed before the process 224 .

For another example, in some embodiments, the data owner device 110 may transmit the authorization beacon identification data to the data service system 160 before the process 416 . For example, the data owner device 110 may transmit the authorized beacon identification data to the data service system 160 in the process 310, or transmit the authorized beacon identification data to the data service system 160 in advance at other points of time. In this way, the process 416 to the process 430 in FIG. 4 can be omitted.

Certain terms are used in the description and patent application to refer to specific components, but those skilled in the art may use different terms to refer to the same components. This description and the scope of the patent application do not use the difference in name as a way to distinguish components, but use the difference in function of components as a basis for differentiation. The "comprising" mentioned in the specification and scope of patent application is an open term and should be interpreted as "including but not limited to". In addition, the term "coupled" herein includes any direct and indirect means of connection. Therefore, if it is described in the text that the first element is coupled to the second element, it means that the first element can be directly connected to the second element through electrical connection or signal connection means such as wireless transmission or optical transmission, or through other elements or connections. The means is indirectly electrically or signally connected to the second element.

The description of "and/or" used in the specification includes any combination of one or more of the listed items. In addition, unless otherwise specified in the specification, any singular term also includes a plural meaning.

The above are only preferred embodiments of the present invention, and all equivalent changes and modifications made according to the claims of the present invention shall fall within the scope of the present invention.

100: Data access authority control system (data read authority control system)

110, 120: data owner device (data owner device)

111: Communication circuit (communication circuit)

113:Block chain computing circuit

115: Display device (display device)

117: Control circuit (control circuit)

130, 140: data requester device (data requester device)

131: Communication circuit (communication circuit)

133: Display device (display device)

135: Control circuit (control circuit)

150:Data source system

151: Communication circuit (communication circuit)

153:Block chain computing circuit

155: database

157: data server (data server)

160:Data service system

161: Communication circuit (communication circuit)

163:Block chain computing circuit

165: database

167: Web server (web server)

170:Block chain node cluster

171~177: block chain node

180:Block chain system

202~230, 302~330, 402~432, 502~524, 602~626: operation process (operation)

FIG. 1 is a simplified functional block diagram of a data access authority control and management system according to an embodiment of the present invention.

2 to 6 are simplified flowcharts of a data access authority control method according to an embodiment of the present invention.

100:Data Access Authority Control System

110, 120: data owner device

111: Communication circuit

113: Blockchain operation circuit

115: display device

117: control circuit

130, 140: data requester device

131: Communication circuit

133: display device

135: control circuit

150:Data source system

151: Communication circuit

153: Blockchain operation circuit

155: database

157:Data server

160:Data service system

161: Communication circuit

163: Blockchain operation circuit

165: database

167:Web server

170:Blockchain node cluster

171~177: Blockchain nodes

180: Blockchain system

Claims (20)

A data access authority control system (100), comprising: A blockchain system (180); A data owner device (110), configured to receive data input by a target user to generate a target data, and generate a certification value using a certification key; a data source system (150) configured to store a sensitivity data corresponding to the target data; A data service system (160), configured to receive the target data and the certification value generated by the data owner's device (110), and request the blockchain system (180) to verify the certification value; a data requester device (130) configured to generate and transmit an alert data request corresponding to the target data to the data service system (160); Wherein, the blockchain system (180) is configured to execute a zero-knowledge proof smart contract to verify the correctness of the proof value by using a verification key, and send a verification key when the proof value is determined to be correct. Successfully notify the data service system (160); Wherein, the block chain system (180) is also configured to check the validity of an authorized token corresponding to the identification data of an authorized token, and can generate and transfer an authorized token when it is determined that the authorized token is valid. beaconing the data service system (160); Wherein, the data service system (160) is further configured to transmit the alert data request to the data source system (150) after obtaining the access beacon, and transfer the access beacon to the data source system (150); Wherein, if the access beacon transferred from the data service system (160) to the data source system (150) is valid, the data source system (150) may send the alert data corresponding to the target data to The data service system (160), and the data service system (160) can transmit the alert data to the data requester device (130). The data access authority control system (100) according to claim 1, wherein the data service system (160) is further configured to receive the sensitive data request from the data requester device (130) Afterwards, sending the authorized beacon identification data to the blockchain system (180). The data access authority control system (100) as claimed in claim 2, wherein the certification key used by the data owner device (110) and the authentication used by the blockchain system (180) Keys are all provided by the data source system (150). The data access authority control system (100) as described in claim 2, wherein the data owner device (110) is also configured to require the target user to input one or more data to be verified, and can use the The proof key generates the proof value according to the one or more pieces of data to be verified. The data access authority control system (100) as described in Claim 2, wherein the authorization token is generated by the blockchain system (180) and transferred to the data owner device (110). The data access authority control system (100) as described in Claim 5, wherein the blockchain system (180) is also configured to execute a token management smart contract to generate and transfer the authorization token to the data owner device (110); Wherein, the data owner device (110) is also configured to use the authorization beacon to transmit a data authorization policy ciphertext to the blockchain system (180), and the blockchain system (180) is also configured to Record the data authorization policy ciphertext in an authorization policy smart contract. The data access authority control system (100) as described in claim 2, wherein the blockchain system (180) is further configured to be identifiable upon receiving the authorization signal from the data service system (160) After the data is collected, an authorization policy smart contract is executed to check whether the data service system (160) complies with a predetermined authorization policy set by the target user. The data access authority control system (100) as described in claim item 7, wherein, the blockchain system (180) only determines whether the authorization signal is valid and whether the data service system (160) meets the predetermined The access beacon is generated and transferred to the data service system (160) only in the case of authorization policy. The data access authority control system (100) as described in claim 2, wherein the data service system (160) is further configured to receive the sensitive data request from the data requester device (130) Afterwards, generate and transmit a data access request corresponding to a target requester to the data owner device (110), and only if the target user accepts the data access request, the data service system (160 ) will transmit the authorized beacon identification data to the blockchain system (180). The data access authority control system (100) as described in claim item 9, wherein the data owner device (110) is also configured to ask the target user whether to accept the data access request, and can When the user accepts the data access request, the user sends the authorization beacon identification data to the data service system (160). The data access authority control system (100) as described in claim 2, wherein the data source system (150) is further configured to transfer the access signal to the area after obtaining the access signal block chain system (180); Wherein, the blockchain system (180) is also configured to check the validity of the access beacon after obtaining the access beacon, and generate and transmit a Notify the data source system of a successful verification (150); Wherein, the data source system (150) is further configured to transmit the alert data corresponding to the target data to the data service system (160) after receiving the verification success notification. The data access authority control system (100) as described in claim 11, wherein, the blockchain system (180) is further configured to set a corresponding period of validity; Wherein, when the blockchain system (180) checks the validity of the access token, it will check whether the access token is served by the data before being transferred to the blockchain system (180). The system (160) transfers to the data source system (150), and the blockchain system (180) also checks that the data source system (150) transfers the access token to the blockchain system (180 ) at a point in time, whether it exceeds the validity period. The data access authority control system (100) as described in claim 11, wherein the blockchain system (180) is further configured to record an acquisition time or a verification time of the access beacon. A data service system (160) used in a data access authority control system (100), wherein the data access authority control system (100) includes a data owner device (110), a data requester A device (130), a data source system (150), and a block chain system (180), the data service system (160) includes: A communication circuit (161), configured to receive a target data and a certification value transmitted from the data owner device (110), and to receive a target data corresponding to the target transmitted from the data requester device (130). Data Sensitivity Data Requests; A block chain operation circuit (163), which is set to act as one of the nodes of the block chain system (180), and can request the block chain system (180) to verify the proof value, wherein, the block chain system (180) A zero-knowledge proof smart contract will be executed to use a verification key to check the correctness of the proof value; a database (165), configured to store the target data; and A web server (167), coupled to the communication circuit (161), the block chain computing circuit (163), and the database (165), configured to determine a When an authorization token corresponding to the authorization token identification data is valid, an access message transferred from the blockchain system (180) is obtained through the communication circuit (161) or the blockchain computing circuit (163) mark; Wherein, the communication circuit (161) is also configured to receive a verification success notification from the blockchain system (180) when the blockchain system (180) determines that the proof value is correct; Wherein, the web server (167) is further configured to transmit the sensitive data request to the data source system (150) through the communication circuit (161) after obtaining the access beacon, and through the communication circuit ( 161) or the blockchain computing circuit (163) transfers the access beacon to the data source system (150); Wherein, if the access token transferred from the data service system (160) to the data source system (150) is valid, the web server (167) can also receive the data source through the communication circuit (161) A sensitivity data corresponding to the target data transmitted from the system (150), and the sensitivity data can be sent to the data requester device (130) through the communication circuit (161). The data service system (160) according to claim 14, wherein, the web server (167) is further configured to receive the alert from the data requester device (130) at the communication circuit (161) After the data request, send the authorized beacon identification data to the blockchain system (180). The data service system (160) as described in claim 15, wherein, the blockchain system (180) is further configured to execute the An authorization policy smart contract to check whether the data service system (160) complies with a predetermined authorization policy set by the target user. The data service system (160) according to claim 16, wherein only when the blockchain system (180) determines that the authorization token is valid and whether the data service system (160) complies with the predetermined authorization policy Only then will the web server (167) obtain the access token transferred from the blockchain system (180) through the communication circuit (161) or the blockchain computing circuit (163). The data service system (160) according to claim 15, wherein, the web server (167) is further configured to receive the alert from the data requester device (130) at the communication circuit (161) After the data request, generate a data access request corresponding to a target requester, and send the data access request to the data owner device (110) through the communication circuit (161), and only when the target user accepts In the case of the data access request, the web server (167) will send the authorization beacon identification data to the blockchain system (180) through the communication circuit (161) or the blockchain computing circuit (163). ). The data service system (160) as described in claim 18, wherein, the data owner device (110) will also ask the target user whether to accept the data access request, and only when the target user accepts the data access request The communication circuit (161) will receive the authorization beacon identification data transmitted from the data owner device (110) only if requested. The data service system (160) according to claim 15, wherein, the data source system (150) is further configured to transfer the access token to the blockchain system ( 180); Wherein, the blockchain system (180) is also configured to check the validity of the access beacon after obtaining the access beacon, and generate and transmit a Notify the data source system of a successful verification (150); Wherein, after the data source system (150) receives the verification success notification, the communication circuit (161) receives the alert data corresponding to the target data from the data source system (150).

Images