KR102664379B1 - A decentralized data sharing system and Collusion-Resistant Multi-Authority Attribute-Based Encryption Scheme based on a Blockchain - Google Patents

Abstract

The present invention relates to a system that allows participants to share various data without the participation of a central trust agency that mutually trusts each other. More specifically, it relates to a decentralized data sharing system and a multi-agency safe from collusion attacks based on blockchain technology. It is about an attribute-based encryption system. To this end, in a multi-agency attribute-based encryption method that is safe from collusion attacks based on a decentralized data sharing system and blockchain technology, the central agency 30 distributes a smart contract (SC) on the blockchain network 10. (S1); A step (S2) in which the user deposits a deposit in response to a smart contract (SC) through the user terminal 12; A step (S3) in which the central organization 30 issues keys to a plurality of attribute organizations 50; A step (S4) in which a plurality of attribute agencies (50) each issue a unique attribute secret key (70) based on the issued key; A step (S5) in which the user secret key (uGID) 25 is selected by the user, and the hash operation result of the user secret key (uGID) 25 becomes the withdrawal condition (hvalue) 60 of the deposit; And the user terminal 12 combines the unique attribute secret keys 70 to generate an organization secret key (cGID) 22, and the organization secret key (cGID) 22 is combined with a user secret key (uGID) 25. A multi-agency attribute-based encryption method that is safe from collusion attacks based on blockchain technology and a decentralized data sharing system comprising a step (S6) of combining attribute secret keys (GID) 20 is provided. do.

Description

A decentralized data sharing system and Collusion-Resistant Multi-Authority Attribute-Based Encryption Scheme based on a Blockchain}

The present invention relates to a system that allows participants to share various data without a central trust agency that mutually trusts each other. More specifically, it relates to a system that can strengthen the security of passwords based on the properties of multiple organizations in a decentralized data sharing system. It is about a decentralized data sharing system and a multi-agency attribute-based encryption system that is safe from collusion attacks based on blockchain technology.

In general, if a user belongs to only one organization, a password model based on the attributes of a single organization can be implemented. However, if a user belongs to more than one organization, there are cases where unique attributes are verified and used by each organization. At this time, a cryptographic model based on the properties of multiple organizations is implemented. In addition, the user holds unique attribute secret keys (plural attributes) granted by each organization of the multi-organization, and the user can create a new attribute secret key by combining these unique attribute secret keys.

Similarly, data can also be encrypted with attributes managed by the organization. For example, decryption of specific data may require (1) belonging to a government agency, (2) a position of manager or higher, and (3) holding a specific qualification (e.g. driver's license), and the user may be required to obtain (1) from government agency A in the system. ), obtain the attribute secret key corresponding to (2), and issue the attribute secret key corresponding to (3) from the organization (e.g., Road Traffic Authority) that manages the relevant certificate (e.g. driver's license), and combine them You can create a new attribute secret key corresponding to the attributes (1), (2), and (3).

However, a collusion attack is possible in which a user (e.g. a collusion attacker) who does not actually possess the attributes required for data decryption obtains the corresponding unique attribute secret key from users who possess the attributes, combines them, and then accesses the data. . In the single agency model, the agency has “user identity information and attribute issuance information,” so it is difficult to implement a collusion attack that uses attributes that are not owned by the user in the decryption process. In other words, it knows who has issued which attribute and uses cryptographic methods to ensure that only attribute values belonging to the same user can be combined. However, in the case of a multi-agency model, each organization does not have the verification information of other organizations, so the collusion attack prevention method based on the identification information provided to the user by each organization during the process of combining the corresponding attribute values for decryption is not applicable.

For example, in the previous example, when the data is encrypted as (1) belonging to a government agency, (2) holding a manager-level or higher position, and (3) holding a specific qualification (e.g. driver's license), the colluding attacker is a manager-level or higher position in government agency A. Although it satisfies the properties of (1) and (2) and has the corresponding unique property secret key, it may not possess the specific certificate (3) required for decryption. At this time, the colluding attacker receives the corresponding unique attribute secret key from another user holding the certificate (e.g. driver's license) of (3) and uses the attribute secret key corresponding to the attributes of (1), (2), and (3). You can create a new one.

This occurs because there is no way to check whether the unique attribute secret keys used for combining are all given to the same user. A representative way to solve this problem is to establish a central system management agency that is commonly trusted by all organizations in the system. Then, the central management agency can assign a global identifier to all users to check whether the users are the same. In addition, since all organizations use the user's global identifier to issue unique attribute secret keys, it can be guaranteed that all keys to be combined are generated from the same global identifier in the key combining stage. However, this method of having a central management agency as the system is not suitable for a decentralized system due to system scalability issues.

In other words, the method of assuming a trusted central authority causes the safety of the entire system to be completely dependent on the central authority, and when the assumption that the authority is absolutely safe from external threats (Fully Trusted) is judged to be unrealistic, it is judged to be unrealistic. There are issues (privacy violations, etc.) (single point failures), and there are issues with updating and sharing relevant information each time a new organization participates in the system (problems of scalability).

1. Republic of Korea Patent Registration No. 10-2170672 (Blockchain cryptocurrency transfer method using blockchain self-authentication process), 2. Republic of Korea Patent Registration No. 10-2298266 (Data access control method and system using attribute-based encryption for safe and efficient data sharing in a cloud environment),

Therefore, the present invention was created to solve the above problems, and the problem to be solved by the present invention is to enable participants to share various data without the participation of a central trust institution that they commonly trust, and to provide decentralized data. It provides a decentralized data sharing system that can strengthen the safety of passwords based on multi-agency attributes in a shared system and a multi-agency attribute-based encryption system that is safe from collusion attacks based on blockchain technology.

Additionally, it must be possible to distinguish whether an attribute has been granted to the same user by multiple organizations (normal) or an attribute has been granted to different users by multiple organizations (collusive attack). A global identifier (GID) is a unique identifier (GID) issued to each user by the administrator of the entire system in which multiple organizations participate, and each organization uses the corresponding GID to issue properties. The purpose is to cryptographically prevent the combination of attribute values.

However, the technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly apparent to those skilled in the art from the description below. It will be understandable.

In order to achieve the above technical task, in the multi-agency attribute-based encryption method that is safe from collusion attacks based on decentralized data sharing system and blockchain technology, the central agency 30 creates a smart contract ( Step (S1) of distributing SC); A step (S2) in which the user deposits a deposit in response to a smart contract (SC) through the user terminal 12; A step (S3) in which the central organization 30 issues keys to a plurality of attribute organizations 50; A step (S4) in which a plurality of attribute agencies (50) each issue a unique attribute secret key (70) based on the issued key; A step (S5) in which the user secret key (uGID) 25 is selected by the user, and the hash operation result of the user secret key (uGID) 25 becomes the withdrawal condition (hvalue) 60 of the deposit; And the user terminal 12 combines the unique attribute secret keys 70 to generate an organization secret key (cGID) 22, and the organization secret key (cGID) 22 is combined with a user secret key (uGID) 25. A multi-agency attribute-based encryption method that is safe from collusion attacks based on blockchain technology and a decentralized data sharing system comprising a step (S6) of combining attribute secret keys (GID) 20 is provided. do.

Additionally, in step S5, the user selects a user secret key (uGID) 25 for each of the plurality of attribute organizations 50.

Additionally, the attribute secret key (GID) 20 is used to encrypt or decrypt the user's data.

In addition, the smart contract (SC) has a first state that is updated and activated by a key; a second state that is deactivated by the user's withdrawal; a third state deactivated by a colluding attacker's withdrawal; a fourth state, deactivated by the central authority 30; and the fifth state when the validity period of the smart contract (SC) expires; It can transition to one of the following states:

Additionally, the deposit is a blockchain token.

Additionally, in step S5, the user can randomly select the user secret key (uGID) 25.

Additionally, users are either sellers who sell their own data or buyers who purchase data from other users.

Additionally, the deposit deposit step (S2) further includes transitioning to a first state for activating the smart contract (SC).

The purpose of the present invention is another embodiment, in a data transaction method using an attribute secret key generated by the above-described encryption method, the cloud service provider 16 storing the seller's encrypted data is connected to the blockchain network 10. ) Step (S①) of distributing a transaction support smart contract (TSC) (90) on the platform; A step (S②) in which the buyer requests sharing of encrypted data with the seller terminal 12 through the buyer terminal 14; After the seller terminal 12 calculates the hash value (hproof) of the random value (R) selected by the seller, the hash value (hproof) is set as the access rights proof (hproof) to communicate with the buyer terminal 14 and the cloud service provider. Transmitting step (S③) in (16); A step (S④) in which the buyer deposits the sales amount into the transaction support smart contract (TSC) (90) through the buyer terminal (14); The seller terminal 12 submits a random value (R) to the transaction support smart contract (TSC) 90 to receive the sales payment, and the random value (R) is transmitted to the buyer terminal 14 and made public (S⑤) ); A step (S⑥) in which the purchaser terminal 14 submits a random value (R) to the cloud service provider 160 and obtains encrypted data; And a step (S⑦) in which the buyer terminal 14 decrypts the data encrypted with the buyer's attribute secret key (GID) 20. A data transaction method using an attribute secret key based on multi-institution attributes. This is provided.

Additionally, the Transaction Support Smart Contract (TSC) 90 is a hash time-lock contract.

In addition, in the disclosure stage (S⑤), the seller terminal 12 receives the sales payment by submitting the hash value (hproof) of the random value (R) to the transaction support smart contract (TSC) 90, and the random value (R ) of the hash value (hproof) is transmitted to the buyer terminal 14 and made public, and in the data acquisition step (S⑥), the buyer terminal 14 sends the hash value (hproof) of the random value (R) to the cloud service provider 160. ) to obtain encrypted data.

According to an embodiment of the present invention, in a decentralized data sharing system, the data owner shares data encrypted with specific attributes, and users prove the attributes they possess from various organizations existing in the system and provide the corresponding attribute secret key. It can be issued and used to decrypt data. In other words, encrypted data can be accessed by anyone who satisfies the properties specified by the data owner during the encryption process.

In addition, in the stage of combining several unique attribute secret keys, the withdrawal conditions of the deposit used for combination are exposed to the user attempting the combination (e.g. collusion attacker), thereby providing the attribute secret key to other users who want to carry out a collusion attack. It can make you hesitate or hesitate to do something. This is because if you provide your attribute secret key, you may lose your deposit. This has the effect of ensuring resistance to collusion attacks in a decentralized system by forcing users to bear the risk of losing their deposits.

In addition, the smart contract (SC) that holds the deposit is transitioned according to the state of the user's deposit, and the system can impose restrictions on the user's use of the system through the state transition of the contract.

In particular, because a blockchain smart contract (SC) is a program that runs on a blockchain network, it is subject to the reliability and security of the blockchain network, making intervention by a third party stochastically almost impossible.

Additionally, the present invention has the advantage of being able to be used not only in a Ciphertext-Policy Attribute-Based Encryption (CP-ABE) environment but also in systems that require control over the actions of various malicious users.

The attribute-based encryption used in the present invention uses specific attributes instead of secret keys for encryption, and in this case, the user can be expressed as a set of these attributes. At this time, the user's properties can be verified by the organization (institution) to which the user belongs and then issued as the result of a cryptographic operation using the organization's secret key. In the process of decrypting the ciphertext, the user cryptographically combines the property values required for decryption. It can be used as a decryption key (single agency attribute-based encryption system). Extending this, if there are multiple organizations in the system and a user can belong to multiple property organizations (multi-agency attribute-based password system), the user is managed with different identification information in each property organization and manages property verification and issuance (in this case, The attributes issued by each institution are fixed) and are performed individually by each institution, but it is possible to use all attribute values in the system during the encryption and decryption process.

However, the effects that can be obtained from the present invention are not limited to the effects mentioned above, and other effects not mentioned above will be clearly understood by those skilled in the art from the description below. You will be able to.

The following drawings attached to this specification illustrate preferred embodiments of the present invention, and serve to further understand the technical idea of the present invention together with the detailed description of the invention described later. Therefore, the present invention includes the matters described in such drawings. It should not be interpreted as limited to only .
Figure 1 is a system block diagram of a multi-agency attribute-based encryption system that is safe from collusion attacks based on blockchain technology and a decentralized data sharing system according to an embodiment of the present invention;
Figure 2 is an explanatory diagram showing the setting of a deposit in one embodiment of the present invention;
Figure 3 is an explanatory diagram showing the process of obtaining ciphertext in one embodiment of the present invention;
Figure 4 is a state diagram showing the state transition model of a smart contract (SC) according to the present invention.

Below, with reference to the attached drawings, embodiments of the present invention will be described in detail so that those skilled in the art can easily implement the present invention. However, since the description of the present invention is only an example for structural or functional explanation, the scope of the present invention should not be construed as limited by the examples described in the text. In other words, since the embodiment can be modified in various ways and can have various forms, the scope of rights of the present invention should be understood to include equivalents that can realize the technical idea. In addition, the purpose or effect presented in the present invention does not mean that a specific embodiment must include all or only such effects, so the scope of the present invention should not be understood as limited thereby.

The meaning of terms described in the present invention should be understood as follows.

Terms such as “first” and “second” are used to distinguish one component from another component, and the scope of rights should not be limited by these terms. For example, a first component may be named a second component, and similarly, the second component may also be named a first component. When a component is referred to as being “connected” to another component, it should be understood that it may be directly connected to the other component, but that other components may also exist in between. On the other hand, when a component is referred to as being “directly connected” to another component, it should be understood that there are no other components in between. Meanwhile, other expressions that describe the relationship between components, such as "between" and "immediately between" or "neighboring" and "directly neighboring" should be interpreted similarly.

Singular expressions should be understood to include plural expressions, unless the context clearly indicates otherwise, and terms such as “comprise” or “have” refer to the specified features, numbers, steps, operations, components, parts, or them. It is intended to specify the existence of a combination, and should be understood as not excluding in advance the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

All terms used herein, unless otherwise defined, have the same meaning as commonly understood by a person of ordinary skill in the field to which the present invention pertains. Terms defined in commonly used dictionaries should be interpreted as consistent with the meaning they have in the context of the related technology, and cannot be interpreted as having an ideal or excessively formal meaning unless clearly defined in the present invention.

Hereinafter, the configuration of the preferred embodiment will be described in detail with reference to the attached drawings. Figure 1 is a system block diagram of a decentralized data sharing system and a multi-agency attribute-based encryption system that is safe from collusion attacks based on blockchain technology according to an embodiment of the present invention.

System configuration

As shown in FIG. 1, the central authority (Central Authority) 30 may be a server device for system management, collaborates with the attribute authority (50) to issue keys to users (12, 14), and periodically exchanges the keys. Perform renewal and disposal of . Additionally, the central agency 30 distributes a deposit smart contract (SC) to each user 12 and 14.

The attribute agency 50 verifies the attributes of the belonging users 12 and 14 and issues a corresponding unique attribute secret key 70. For example, the attribute agency 50 may be a government agency 50a, a driver's license agency 50b, etc.

Users can be sellers and buyers of data, and specifically, the seller terminal 12 owned by the seller and the buyer terminal 14 owned by the buyer. The seller terminal 12 and the buyer terminal 14 may be mobile phones, laptops, tablets, PCs, client computers, etc. An application program (app) that can be operated according to the present invention is installed and executed on the user terminals 12 and 14. Users can participate in the system of the present invention through the seller terminal 12 or the buyer terminal 14. Additionally, the user must deposit a deposit into the smart contract (SC) 40.

An operation program called a smart contract 40 is executed in the blockchain network 10. The smart contract (40) does not operate on a single server device, but is executed and verified by all nodes (participants) existing in the blockchain network (10), and the results are reflected by consensus, providing reliable results. It can be returned. In one embodiment of the present invention, there is a smart contract 40 that manages the user's deposit and a trade support smart contract (TSC, 90) that handles transaction management between users in the system. In particular, transaction support smart contracts (TSC, 90) have an expiration date as Hashed Time Lock Contracts.

Cloud Service Provider (160) is used for data trading (sharing), and data trading is not done through direct data sharing between users, but through trading access rights to data stored in the cloud server. The buyer (14), who obtained data access rights through a transaction, proves access rights to the cloud server, obtains the corresponding ciphertext, and decrypts the ciphertext using his attribute secret key. The cloud server distributes a transaction support smart contract (TSC) to the blockchain network (10) to support users' transactions.

Setting the deposit and generating the attribute secret key

Figure 2 is an explanatory diagram showing the setting of a deposit in one embodiment of the present invention. As shown in Figure 2, first, the central agency 30 distributes the smart contract 40 on the blockchain network 10 (S1).

Next, the user deposits a deposit (e.g. blockchain token) in response to the smart contract (SC) through the user terminal 12 (S2). Then, the smart contract (SC) transitions to the first state, meaning activation.

Next, the central organization 30 issues a key to each of the plurality of attribute organizations 50 (S3).

Next, the plurality of attribute agencies 50 each issue a unique attribute secret key 70 based on the issued key (S4).

Next, the user secret key (user Group Identifier, uGID, 25) is selected by the user, and the hash operation result of the user secret key (uGID) (25) becomes the deposit withdrawal condition (hvalue) (60) (S5 ). Specifically, the user randomly selects a secret key for each of the plurality of attribute organizations 50 and combines them to generate a user secret key (uGID) 25. The user secret key (uGID) 25 is composed of a set of secret keys for the attributes held by the user, and the hash operation result of the user secret key (uGID) 25 is the withdrawal condition (hvalue) of the deposit as follows. It becomes (60). In other words, in order to withdraw the deposit, the user secret key (uGID) (25) must be submitted to the smart contract (40).

[Equation 1]

hvalue = Hash(uGID)

Since only the hvalue, which is the hash operation result of the user secret key (uGID, 25), is recorded in the blockchain state database of the smart contract (40), except for collusion attacks, no one in the system can know the user secret key (uGID, 25). .

Next, the user terminal 12 combines all of the unique attribute secret keys 70 to generate an organization secret key (cGID) 22, and the user secret key (cGID) 22 is added to the generated organization secret key (cGID) 22. The attribute secret key (GID) (20) is generated by combining the uGID (25) again (S6). This attribute secret key (GID) 20 is used to encrypt or decrypt the user's data.

Figure 4 is a state diagram showing the state transition model of a smart contract (SC) according to the present invention. As shown in Figure 4, a smart contract (SC) can transition to one of several states after the deposit is set (e.g., deposited). For example, the first state is periodically updated and activated by a key, the second state is deactivated by the user's withdrawal (Close), the third state is deactivated by the collusion attacker's withdrawal (Close), and the central authority (30) It can be transferred to one of the fourth state (Revoke, discard), where use is discontinued, and the fifth state (Revoke, discard), when the validity period of the smart contract (SC) expires.

Obtaining the ciphertext

Figure 3 is an explanatory diagram showing the process of obtaining ciphertext in one embodiment of the present invention. As shown in Figure 3, the seller terminal 12 encrypts the data to be traded using the seller's attribute secret key. Then, the encrypted data is stored on the cloud server of the cloud service provider 16. Then, the cloud service provider 16 distributes the transaction support smart contract (TSC) 90 on the blockchain network 10 (S①).

Next, the buyer who has seen the transaction support smart contract (TSC) 90 requests sharing (purchase) of the encrypted data with the seller terminal 12 through the buyer terminal 14 (S②).

Next, the seller terminal 12 calculates the hash value (hproof) of the random value (R) selected by the seller as shown in [Equation 2], and then sets the hash value (hproof) as the access rights proof (hproof). This is transmitted from the purchaser terminal 14 and the cloud service provider 16, respectively (S③).

[Equation 2]

hproof = Hash(R)

Next, the sales price is deposited into the transaction support smart contract (TSC) (90) through the buyer terminal (14) (S④).

Next, the seller terminal 12 receives the sales payment by submitting the hash value (hproof) of the random value (R) to the transaction support smart contract (TSC) 90, and at the same time automatically The hash value (hproof) of the random value (R) is transmitted to the buyer terminal 14 and made public (S⑤). Since the Transaction Support Smart Contract (TSC) 90 is a Hashed Time Lock Contract, it ensures that the receipt of the sales payment and the disclosure of the random value (R) occur simultaneously. The data trading and actual data sharing of the present invention occur at different times because they do not go through a trusted intermediary. In other words, permission is obtained and the actual ciphertext is obtained later. The hash time lock contract is intended to resolve the unfairness that arises here, and occurs sequentially between three people, including the cloud server. The seller (data owner) makes a profit when selling access rights to the buyer, but the buyer can only profit from the transaction after paying a price to the seller, obtaining permission, and obtaining the data stored on the server. In other words, the steps in which the two participants in a transaction obtain profits are not synchronized. The hash time lock technology of the present invention is used to synchronize the timing of obtaining profits (buyer-data, seller-sale payment) from the transaction.

Next, the buyer terminal 14 submits the hash value (hproof) of the random value (R) to the cloud service provider 160 and obtains the encrypted data (S⑥). In other words, the conditions for proving authority for obtaining encrypted data and for obtaining sales proceeds are the same.

Next, the buyer terminal 14 decrypts the encrypted data with the buyer's attribute secret key (GID) 20 (S⑦). Through this process, buyers can receive the desired data.

A detailed description of preferred embodiments of the invention disclosed above is provided to enable any person skilled in the art to make or practice the invention. Although the present invention has been described above with reference to preferred embodiments, those skilled in the art will understand that various modifications and changes can be made to the present invention without departing from the scope of the present invention. For example, a person skilled in the art may use each configuration described in the above-described embodiments by combining them with each other. Accordingly, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

The present invention may be embodied in other specific forms without departing from the spirit and essential features of the present invention. Accordingly, the above detailed description should not be construed as restrictive in all respects and should be considered illustrative. The scope of the present invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the present invention are included in the scope of the present invention. The present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. In addition, claims that do not have an explicit reference relationship in the patent claims can be combined to form an embodiment or included as a new claim through amendment after filing.

10: Blockchain network,
12: user terminal,
14: Buyer terminal,
16: Cloud service provider,
20: attribute secret key,
22: Institutional secret key (cGID),
25: user secret key,
30: Central agency,
40: Smart Contract (SC),
50: attribute agency,
50a: government agency,
50b: Driver's licensing agency,
60: Withdrawal conditions (hvalue).
70: Unique attribute secret key,
90: Transaction Support Smart Contract (TSC).

Claims (11)

In the multi-agency attribute-based encryption method that is safe from collusion attacks based on decentralized data sharing system and blockchain technology,
A step (S1) in which the central agency 30 distributes a smart contract (SC) on the blockchain network 10;
A step (S2) of the user depositing a deposit in response to the smart contract (SC) through the user terminal 12;
A step (S3) of the central organization 30 issuing keys to a plurality of attribute organizations 50;
A step (S4) in which each of the plurality of attribute agencies (50) issues a unique attribute secret key (70) based on the issued key;
A step (S5) in which a user secret key (uGID) 25 is selected by the user, and the hash operation result of the user secret key (uGID) 25 becomes the withdrawal condition (hvalue) 60 of the deposit; and
The user terminal 12 combines the unique attribute secret keys 70 to generate an organization secret key (cGID) 22, and the user secret key (uGID) is added to the organization secret key (cGID) 22. A decentralized data sharing system and multi-institution attribute-based encryption that is safe from collusion attacks based on blockchain technology, comprising a step (S6) of combining (25) to generate an attribute secret key (GID) (20); method. According to claim 1,
In step S5, the user selects the user secret key (uGID) 25 for each of the plurality of attribute institutions 50 and is safe from collusion attacks based on blockchain technology and a decentralized data sharing system. Multi-agency attribute-based encryption method. According to claim 1,
The attribute secret key (GID) 20 is a multi-agency attribute-based encryption method that is safe from collusion attacks based on a decentralized data sharing system and blockchain technology, characterized in that it is used to encrypt or decrypt the user's data. According to claim 1,
The smart contract (SC) is,
a first state updated and activated by the key;
a second state deactivated by the user's withdrawal;
a third state deactivated by a colluding attacker's withdrawal;
a fourth state in which use is discontinued by the central agency 30; and
A fifth state in which the validity period of the smart contract (SC) expires; A decentralized data sharing system that can transition to one of the following states and a multi-agency attribute-based encryption method that is safe from collusion attacks based on blockchain technology. According to claim 1,
A decentralized data sharing system in which the deposit is a blockchain token and a multi-agency attribute-based encryption method that is safe from collusion attacks based on blockchain technology. According to claim 1,
In step S5, the user randomly selects the user secret key (uGID) 25. A multi-agency attribute-based encryption method that is safe from collusion attacks based on a decentralized data sharing system and blockchain technology. According to claim 1,
A multi-agency attribute-based encryption method that is safe from collusion attacks based on a decentralized data sharing system and blockchain technology, characterized in that the user is a seller who sells the data he or she owns or a buyer who purchases the data of other users. According to claim 1,
The depositing step (S2) of the deposit further includes a step of transitioning to a first state activating the smart contract (SC). A multi-agency safe from collusion attacks based on a decentralized data sharing system and blockchain technology. Attribute-based encryption method. In a data transaction method using an attribute secret key generated by the encryption method according to any one of claims 1 to 8,
A step (S①) in which the cloud service provider (16), which stores the seller's encrypted data, distributes a transaction support smart contract (TSC) (90) on the blockchain network (10);
A step (S②) in which the buyer requests sharing of the encrypted data with the seller terminal 12 through the buyer terminal 14;
After the seller terminal 12 calculates the hash value (hproof) of the random value (R) selected by the seller, the hash value (hproof) is set as the access right proof (hproof) to the buyer terminal 14. and a transmission step (S③) from the cloud service provider 16;
A step (S④) of the buyer depositing the sales amount into the transaction support smart contract (TSC) 90 through the buyer terminal 14;
The seller terminal 12 receives the sales payment by submitting the random value (R) to the transaction support smart contract (TSC) 90, and the random value (R) is transmitted to the buyer terminal 14. Step where it is made public (S⑤);
A step (S⑥) of the buyer terminal 14 submitting the random value (R) to the cloud service provider 16 to obtain the encrypted data; and
A step (S⑦) of the buyer terminal 14 decrypting the encrypted data using the buyer's attribute secret key (GID) 20; data using a multi-agency attribute-based attribute secret key, comprising: How to trade. According to clause 9,
The transaction support smart contract (TSC) 90 is a data transaction method using a multi-agency attribute-based attribute secret key, characterized in that it is a hash time lock contract. According to clause 9,
In the disclosure step (S⑤),
The seller terminal 12 receives the sales amount by submitting the hash value (hproof) of the random value (R) to the transaction support smart contract (TSC) 90,
The hash value (hproof) of the random value (R) is transmitted to the purchaser terminal 14 and made public, and
In the data acquisition step (S⑥), the buyer terminal 14 submits a hash value (hproof) of the random value (R) to the cloud service provider 16 to obtain the encrypted data. Data transaction method using attribute secret key based on institutional attributes.

Images