Access control method and apparatus, electronic device, and storage medium

Abstract

The application discloses an access control method and device, equipment and a storage medium, and the method comprises the following steps: receiving an access request of a first user to a first file through an access management contract of a block chain; calling an attribute sub-chain of the block chain to determine attribute information of the first user through the access management contract based on a first attribute policy corresponding to the first file; calling an identity sub-chain of the block chain to determine identity information of the first user through the access management contract based on the identity; verifying the attribute information and the identity information of the first user through the access management contract; and authorizing the first user through a file access contract of the block chain in the case that the first user passes the verification. The application adopts a multi-chain structure, uses an attribute policy and identity authentication combined mode to authorize a data requester, and ensures safe and traceable security verification.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electronic devices, and relates to but is not limited to an access control method and device, an electronic device, and a storage medium. BACKGROUND

[0002] Attribute-based Access control (ABAC) based on user, resource, operation and running context attributes uses the attributes of the subject and object as the basic decision elements, flexibly uses the attribute set possessed by the requester to determine whether to grant access permission, and can well separate policy management and permission determination. Since the attributes are inherent in the subject and object and do not need to be manually assigned, and the access control is a many-to-many manner, the ABAC management is relatively simple. Moreover, the attributes can describe entities from multiple angles, and thus the policy can be changed according to actual conditions.

[0003] However, the identities and attribute information of various institutions are distributed in a decentralized manner. For example, a hospital has the identities of doctors and patients, and a financial institution has the attribute information of the property status of users. Therefore, when the blockchain platform centrally verifies, it is impossible to achieve unified user access control from the data silos. SUMMARY

[0004] The present application provides an access control method and device, an electronic device, and a storage medium, which at least solve the problem that the safe and traceable security verification of the related art cannot achieve unified user access control from the data silos when the blockchain platform centrally verifies.

[0005] The technical solution of the present application is as follows:

[0006] In a first aspect, the present application provides an access control method applied to a blockchain, and the method comprises the following steps:

[0007] receiving, by an access management contract of the blockchain, an access request of a first user to a first file; the access request comprising an identity of the user;

[0008] determining, by the access management contract, attribute information of the first user based on a first attribute policy corresponding to the first file, and calling an attribute subchain of the blockchain; the attribute subchain being a private chain for managing user attribute information;

[0009] determining, by the access management contract, identity information of the first user based on the identity, and calling an identity subchain of the blockchain; the identity subchain being a private chain for storing identity authentication records;

[0010] verify the attribute information and the identity information of the first user through the access management contract;

[0011] in a case where the first user passes the verification, grant the first user through a file access contract of the blockchain.

[0012] In a second aspect, the present application provides an access control device, comprising:

[0013] A first receiving module is configured to receive an access request of a first user to a first file through an access management contract of the blockchain; the access request comprises an identity of the first user;

[0014] A first determining module is configured to determine attribute information of the first user through an attribute subchain of the blockchain based on a first attribute policy corresponding to the first file and by invoking the access management contract; the attribute subchain is a private chain for managing user attribute information;

[0015] A second determining module is configured to determine identity information of the first user through an identity subchain of the blockchain based on the identity and by invoking the access management contract; the identity subchain is a private chain for storing identity authentication records;

[0016] An attribute verifying module is configured to verify the attribute information and the identity information of the first user through the access management contract;

[0017] An authorization module is configured to grant the first user through a file access contract of the blockchain in a case where the first user passes the verification.

[0018] In a third aspect, the present application provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program capable of running on the processor, and the processor implements the steps of the above access control method when executing the program.

[0019] In a fourth aspect, the present application provides a computer readable storage medium, which stores a computer program capable of being executed by a processor to implement the steps of the above access control method.

[0020] The technical solutions provided by the present application have at least the following beneficial effects:

[0021] In the embodiment of the present application, when a user requests file access permission from the blockchain, the attribute information and identity information are obtained from the attribute subchain and the identity subchain respectively through the access management contract on the blockchain for attribute verification, and the file access contract is notified of the successful attribute verification, and the user is authorized by the file access contract. The multi-chain structure is adopted in the embodiment of the present application, the attribute subchain stores the mapping relationship between the attribute policy and the file, and the identity management mapping is realized by the identity subchain (provided by the identity verification service provider), which realizes the expandable attribute allocation and ensures the safe and traceable security verification. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0023] Figure 1A The system framework of the blockchain data access control scheme based on the CP-ABE algorithm in the related art;

[0024] Figure 1B The flowchart of the blockchain data access control scheme based on the CP-ABE algorithm in the related art;

[0025] Figure 2 The flowchart of the access control method provided by the embodiment of the present application;

[0026] Figure 3 The flowchart of the access control method provided by the embodiment of the present application;

[0027] Figure 4 The flowchart of the access control method provided by the embodiment of the present application;

[0028] Figure 5 The flowchart of the access control method provided by the embodiment of the present application;

[0029] Figure 6 The overall block diagram of the access control method provided by the embodiment of the present application;

[0030] Figure 7 The composition structure diagram of the access control device provided by the embodiment of the present application;

[0031] Figure 8 The hardware entity diagram of the electronic device provided by the embodiment of the present application. DETAILED DESCRIPTION

[0032] In order to make the purposes, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some of the embodiments of the present application but not all the embodiments of the present application. The following embodiments are used to illustrate the present application but not to limit the scope of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0033] In the following description, "some embodiments" are related to a subset of all possible embodiments, but it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments and can be combined with each other without conflict.

[0034] It should be noted that the terms "first", "second", "third" involved in the embodiments of the present application are only to distinguish similar objects and do not represent a specific order of the objects. Understandably, "first", "second", "third" can be interchanged in a specific order or sequence as allowed, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0035] Those skilled in the art can understand that, unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meaning as generally understood by those skilled in the art to which the embodiments of the present application belong. It should also be understood that terms such as those defined in a general dictionary should be understood to have meanings consistent with those in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as such herein.

[0036] Blockchain: As a term in the field of information technology, blockchain is a new application mode of distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm and other computer technologies. Blockchain is an important concept of Bitcoin. It is essentially a decentralized database and at the same time as the underlying technology of Bitcoin, it is a series of data blocks associated using cryptographic methods, equivalent to the content of the ledger. Blockchain is a decentralized database, and each node data (or behavior) is recorded by others, so the data (or behavior) of each person on the blockchain can be tracked and restored. According to the classification of system control right and whether transaction information is public or not, blockchain can be divided into three categories: public (such as Bitcoin, Ethereum, etc.), private chain and consortium chain (such as Hyperledger, etc.).

[0037] Event: That is, a subscription or issuance event on the blockchain.

[0038] Transaction: An execution unit on the ledger.

[0039] Oracle: One of the infrastructures of the blockchain industry, a mechanism for writing information outside the blockchain into the blockchain. Events, data, payment messages, etc. that occur outside the blockchain can be written into the smart contract on the blockchain through the oracle, expanding the application scenarios of the smart contract.

[0040] Smart Contract: A computer protocol designed to disseminate, verify or execute contracts in an information-based manner. The smart contract is a collection of various business rules that run on the blockchain and are shared and verified by a group of stakeholders. The smart contract is very useful in the process of business automation and is honest and reliable, and it can enable stakeholders to process and verify contract terms in a group form. Hyperledger is a smart contract that executes the smart contract using chaincode, that is, all relevant terms in the smart contract are written in code and can be automatically settled, and in the future, it will be executed through signature or other triggering events.

[0041] Inter-Planetary File System (IPFS) is a point-to-point (P2P) distributed file system that aims to supplement (or even replace) the Hypertext Transfer Protocol (HTTP) that currently dominates the Internet, connecting all computing devices with the same file system together.

[0042] Attribute-based Access Control (ABAC) based on user, resource, operation and running context attributes uses the attributes of the subject and object as the basic decision-making elements, and flexibly uses the attribute set possessed by the requester to determine whether to grant access rights, which can well separate policy management and permission judgment.

[0043] Since attributes are inherent to the subject and object and do not need to be manually assigned, and access control is a many-to-many approach, ABAC management is relatively simple. And attributes can describe entities from multiple angles, so policies can be changed according to actual conditions.

[0044] For example, the access control model based on the time characteristics proposed for time constraints introduces time constraints into the access control system by analyzing that users may have different identities at different times, and restricts the access operations of users through time attributes; for example, the usage-based access control model (UCON) introduces constraint conditions (such as system load, access time limit, etc.) that must be met for performing access control. In addition, the strong expansibility of ABAC enables it to be combined with data privacy protection mechanisms such as encryption mechanisms, to ensure that user data will not be analyzed and leaked on the basis of realizing fine-grained access control. For example, the attribute-based encryption (ABE) method.

[0045] A blockchain data access control scheme based on a ciphertext policy attribute-based encryption (CP-ABE, Ciphertext Policy Attribute-based Encryption) algorithm is proposed in the related art. The Fabric-CA module originally existing in the Hyperledger is combined to solve the data privacy security problem existing in the Hyperledger of the consortium chain. The scheme can realize user-level fine-grained secure access control of blockchain data, and can also realize secure distribution of user attribute keys in the CP-ABE scheme. The security analysis of the scheme shows that the scheme realizes the security goals of ABE user attribute private key secure distribution and data privacy protection, and the performance analysis part also shows that the scheme has good usability.

[0046] In the CP-ABE algorithm, the decryption strategy is embedded in the ciphertext when encryption, and the attributes of the user are embedded in the private key when the key is generated, that is, the access strategy is associated with the ciphertext. The system framework of the blockchain data access control scheme based on the CP-ABE algorithm is as follows: Figure 1AAs shown, the scheme includes three parts of a blockchain network (Fabric) 11, a certificate authority (Fabric-CA) 12 and a client (Client) 13, and the scheme is based on the existing blockchain network 11 and the certificate authority 12, and can be implemented by embedding the CP-ABE algorithm in the certificate authority 12, that is, the certificate authority 12 serves as a trusted third party in the CP-ABE scheme, and at this time, the certificate authority 12 not only manages the certificates required by the users in the original blockchain network 11, that is, implements user certificate management 121, but also has CP-ABE system initialization 122 and user attribute private key generation and distribution 123. The user realizes the interaction with the blockchain network 11 and the certificate authority 12 through the client (Client) 13, and the client 13 realizes the functions of initiating a transaction 131, receiving a user certificate 132, receiving a user attribute private key 133, and CP-APE data encryption and decryption 134. The blockchain network 11 realizes the functions of transaction endorsement 111, transaction ordering 112, transaction verification and chaining 113, and the like.

[0047] In implementation, the user registers with the certificate authority 12 to obtain the corresponding certificate and the user attribute private key of the CP-ABE scheme, encrypts the plaintext data using the obtained private key and the access control policy specified by the user, and then sends the ciphertext to the blockchain network 11 in the form of a transaction for storage of the encrypted data.

[0048] In order to more objectively show the implementation process of the scheme, as shown in Figure 1B As shown, taking the interaction between the client 13A corresponding to the user A and the client 13B corresponding to the user B as an example, the user A wants to encrypt and chain the private data, and the user B hopes to access the plaintext corresponding to the ciphertext. It is assumed that the user A interacts with the blockchain network 11 and the certificate authority 12 through the client 13A, and the user B interacts with the blockchain network 11 and the certificate authority 12 through the client 13B, including the steps of establishment (Setup), registration (KeyGen), encryption (Encrypt), update (Update), download (Download) and decryption (Decrypt). The main implementation steps of the process are shown in Figure 1B As shown, the overall workflow of the scheme can be roughly divided into three stages:

[0049] The key generation stage 21 includes the following steps:

[0050] Step S1, the certificate authority 12 generates the master key (MK) and public parameter (PK) in the CP-ABE scheme;

[0051] Step S2A, the client 13A sends a first user certificate request to the certificate authority 12;

[0052] Step S2B, the client 13B sends a second user certificate request to the certificate authority 12;

[0053] Step S3A, the certificate authority 12 generates a user certificate (U certA ) and an attribute key ciphertext (CT SKA ) according to the first user certificate request and returns them to the client 13A;

[0054] Step S3B, the certificate authority 12 generates a user certificate (U certB) and an attribute key ciphertext (CT SKB ) according to the second user certificate request and returns them to the client 13B;

[0055] Data encryption on-chain stage 22, which includes the following steps:

[0056] Step S4, the client 13A formulates an access control policy and constructs an access tree according to the access control policy; by inputting the public parameters, the on-chain privacy data plaintext, and the access tree, a transaction ciphertext (CTA) is generated;

[0057] Step S5, the client 13A sends the transaction ciphertext as the load of the transaction to the blockchain network 11 for endorsement, ordering, distribution, and verification operations of the encrypted transaction, and finally successfully on-chain the transaction ciphertext;

[0058] Access control stage 23: including

[0059] Step S6, the client 13B queries the transaction information of the transaction ciphertext from the blockchain network 11;

[0060] Step S7, the blockchain network 11 sends the transaction ciphertext corresponding to the transaction information to the client 13B;

[0061] Step S8, the client 13B decrypts the attribute ciphertext using the user private key to generate a plaintext attribute key (SKB); if the attributes contained in the plaintext attribute key satisfy the access control policy contained in the transaction ciphertext, the client 13B decrypts the encrypted data to generate the privacy data plaintext.

[0062] The above-mentioned CP-ABE-based blockchain data access control scheme still has the following problems:

[0063] 1) The decryption process of the CP-ABE algorithm involves complex operations, which is contradictory to the limited computing power of the client. The CP-ABE algorithm based on the ciphertext access policy consumes a lot of time and computing resources, which is not suitable for file storage on the actual application blockchain; especially when the number of attributes increases, the encryption and decryption time will increase sharply.

[0064] 2) Key-based attribute policy access control scheme is difficult to revoke the key to achieve dynamic adjustment. Most of the current attribute-based encryption scheme construction does not consider the revocation of attributes and users and outsourcing decryption, and the actual application scene often faces the phenomenon of user permission change and revocation, and the problems of attribute revocation and ciphertext update are inevitable.

[0065] 3) Only support Hyperledger, not suitable for the current heterogeneous blockchain actual scene. Although Hyperledger has very wide application, according to the current industry application, institutions and enterprises adopt a variety of different blockchain platforms according to different scene needs. Therefore, it is necessary to consider the access control policy supporting heterogeneous blockchain with wide applicability.

[0066] 4) Only support attribute policy without corresponding identity authentication. The distribution of the identity and attribute information of each party institution is scattered, for example, hospitals have the identity information of doctors and patients, and financial institutions have the attribute information of users' property status, therefore, when the blockchain platform centralized verification, it is impossible to realize unified user access control from the data silos.

[0067] Embodiments of the present application provide an access control method, applied to an electronic device. The electronic device includes but is not limited to a mobile phone, a notebook computer, a tablet computer, a palm Internet device, a multimedia device, a streaming media device, a mobile Internet device, a wearable device or other types of electronic devices. The functions implemented by the method can be realized by calling program codes in the processor of the electronic device, and of course the program codes can be saved in the computer storage medium, so the electronic device at least includes a processor and a storage medium. The processor can be used for processing the access control process, and the storage can be used for storing the data required in the access control process and the generated data.

[0068] Figure 2 A flowchart of an access control method provided by an embodiment of the present application is shown in FIG. 1, which includes the following steps: Figure 2

[0069] Step S210, receiving an access request of a first user to a first file through an access management contract of the blockchain;

[0070] Here, the access management contract (Access Manager Contract) is a smart contract on the blockchain, which is used to verify the user's permission to access the file, and in the implementation, it is specifically performed according to the attribute policy corresponding to the file.

[0071] The access request includes the identity of the first user, such as the student ID of the college where the user is located, the work ID or ID number of the hospital where the user is located, etc.​

[0072] At step S220, based on the first attribute policy corresponding to the first file, the access management contract is called to determine the attribute information of the first user through the attribute subchain of the blockchain;

[0073] Here, the attribute subchain (A-Chain) is a private chain for managing the attribute information of a user, which maintains a hash attribute mapping table storing the correspondence between attribute policies and file hashes, so as to re-encrypt after updating the attribute policy. The hash attribute mapping table includes the file name, file hash value, and corresponding attribute policy.

[0074] When a user requests to access a file, the first file and the identity of the user to be accessed are submitted to the access management contract of the blockchain through an access request. The access management contract finds the first attribute policy corresponding to the first file from the pre-stored hash attribute mapping table, and finds the user attribute information corresponding to the first attribute policy from the attribute subchain. The user attribute information can be the personal information registered and saved by the user when registering the blockchain, for example, for a hospital blockchain platform, the user attribute information is the department and field of expertise of the doctor.

[0075] At step S230, based on the identity, the access management contract is called to determine the identity information of the first user through the identity subchain of the blockchain;

[0076] Here, the identity subchain (I-Chain) is a private chain for storing the identity authentication records of users, and all identity authentication records after authentication by various institutions and departments are recorded on the identity subchain.

[0077] The identity subchain pre-provides a method and identity verification process based on the European electronic signature and trust system (eIDAS). When the access management contract receives a request for file access permission from a user, it calls the identity subchain to obtain information about the digital identity from the service provider, such as title, license, qualification, age, etc., thereby determining the identity information of the user.

[0078] It is worth noting that this step may involve the privacy of the user, and the identity subchain can be private to a third party (bank, hospital, etc.) or government department, and the attribute can be confirmed through an external interface without directly exposing the identity subchain.

[0079] Through steps S220 and S230, it can be seen that in the access control scheme based on attribute processing provided in the embodiments of the present application, the attribute policy is maintained by the file platform party, and the identity policy is provided by the third-party service provider, which is suitable for scenarios with a large number of users; meanwhile, the identity verification and the attribute policy are separated, and the system security is stronger.

[0080] Step S240, verifying the attribute information and the identity information of the first user through the access management contract;

[0081] Here, the access management contract obtains all the attribute verification information of the user for verification, and sends an authorization message to the file access contract of the blockchain when the verification is successful.

[0082] Step S250, in the case that the first user passes the verification, authorizing the first user through the file access contract of the blockchain.

[0083] Here, the file access contract (Access File Contract) is used to grant the user a key corresponding to the first attribute policy when the attribute verification is successful, so that the user can decrypt the first file to be accessed based on the key.

[0084] The file access contract receives the authorization message of the successful attribute verification, calls an oracle (Oracle) to check the overall validity of the previous verification step of the access management contract. If the check is successful, the file access contract will issue a transaction and upload the transaction to the chain to confirm that the verification is completed.

[0085] In the embodiments of the present application, when a user requests file access permission from the blockchain, the access management contract on the blockchain obtains attribute information and identity information from the attribute subchain and the identity subchain respectively for attribute verification, and notifies the file access contract of the successful attribute verification, and the file access contract authorizes the user. The multi-chain structure is adopted in the embodiments of the present application, the attribute subchain stores the mapping relationship between the attribute policy and the key, and the identity subchain realizes identity management mapping (provided by the identity verification service provider), which realizes expandable attribute allocation, and is more friendly in dynamic updating compared with the traditional attribute encryption method.

[0086] Figure 3 A flowchart of an access control method provided in the embodiments of the present application is shown in FIG. 1. Figure 3 As shown in FIG. 1, the method further includes the following steps:

[0087] Step S310, receiving an access request of a first user to a first file through an access management contract of the blockchain;

[0088] Here, the first file is stored in a distributed file system such as IPFS, and the access request includes an identity of the user.

[0089] The embodiment of the present application considers the storage overhead of the blockchain, and proposes to use the blockchain as a file sharing platform, and use IPFS as a file storage platform to reduce the time overhead and calculation cost of the blockchain. In implementation, the file to be shared is stored in IPFS, and the blockchain records the hash value of the file in IPFS, saves the storage space of the blockchain, and improves the throughput of the blockchain. At the same speed of block generation, more transactions can be processed. In addition, the peer-to-peer characteristics and the characteristics of the distributed hash table of IPFS make the utilization of storage space more reasonable.

[0090] In step S320, the access management contract obtains the hash value of the first file in the distributed file system;

[0091] Here, the attribute subchain of the blockchain records the file name, hash value, publisher and other information in IPFS, and the hash value of the first file can be found in the attribute subchain by calling the attribute subchain through the access management contract.

[0092] In step S330, the access management contract determines the first attribute policy corresponding to the first file from the preset hash attribute mapping table based on the hash value of the first file.

[0093] Here, the attribute subchain maintains a preset hash attribute mapping table, which is used to record the corresponding relationship between the file hash value and the attribute policy.

[0094] In step S340, the attribute information of the first user is determined by calling the attribute subchain of the blockchain through the access management contract based on the first attribute policy corresponding to the first file.

[0095] Here, the attribute subchain is a private chain for managing the attribute information of the user. The attribute subchain stores the attribute policy corresponding to each category of file and the specific attribute information of the user corresponding to the attribute policy.

[0096] The hash attribute mapping table is maintained in the attribute subchain. In some embodiments, a file conforming to the XACML (Extensible Access Control Markup Language) standard is generated to specify a new attribute policy for file A, and the new attribute policy is updated to the hash attribute mapping table. In another embodiment, the attribute policy corresponding to file B can be found based on the hash attribute mapping table.

[0097] In step S350, if the attribute information of the first user exists in the attribute subchain, the access request is forwarded to the identity subchain of the blockchain through the access management contract.

[0098] Here, the identity subchain is a private chain for storing identity authentication records of users.

[0099] The access management contract first verifies the user attribute information stored in the attribute subchain, and then

[0100] Step S360, based on the identity identifier, determining the identity information of the first user through the identity subchain;

[0101] Step S370, verifying the attribute information and the identity information of the first user through the access management contract;

[0102] Step S380, in the case that the first user passes the verification, authorizing the first user through the file access contract of the blockchain.

[0103] Here, after the attribute verification succeeds, the access management contract receives the authorization message and verifies the validity of the authorization operation process, that is, the user can be authorized, that is, the first attribute policy corresponding key is extracted from the attribute subchain to the user, and the user can decrypt the first file to access using the key.

[0104] At the same time, the access management transaction will issue a transaction and chain the transaction. The process of publishing the transaction and chaining the transaction can be realized through the following steps:

[0105] Step S3801, in the case that the first user passes the verification, determining the first key corresponding to the first attribute policy through the file access contract;

[0106] Here, the first key is used to decrypt the ciphertext corresponding to the first file. That is, the first file is stored in the IPFS in the form of ciphertext, and the attribute subchain stores the first attribute policy of the first file and the first key corresponding to the ciphertext when forming the ciphertext, so that the attribute policy and the key are one-to-one.

[0107] Step S3802, encrypting the first key with the public key of the first user through the file access contract to obtain a second key;

[0108] Here, encrypting the first key with the public key of the user to obtain the second key can make the user the only one who can use his own private key to decrypt the second key.

[0109] Step S3803, initiating a transaction request through the file access contract with the second key as input and submitting the transaction request to the attribute subchain to realize the authorization of the first user.

[0110] Here, the second key is used by the user to decrypt the first key with his own private key. After the user decrypts the first key, the first file corresponding to the ciphertext can be further decrypted using the first key, thereby obtaining the plaintext file of the first file.

[0111] In the embodiment of the present application, when a user requests file access permission from the blockchain, attribute information and identity information are obtained from the attribute subchain and the identity subchain respectively through the access management contract on the blockchain for attribute verification. After the attribute verification is passed, the key corresponding to the attribute policy is extracted from the attribute subchain by the file access contract to the user, and the user can decrypt the file for access. The embodiment of the present application uses a private chain to store the attribute policy and the identity policy, ensuring the security and privacy of the attribute policy. It supports massive user access and makes the key access traceable and manageable. At the same time, the file publishing and access use two smart contracts, the file access contract and the access management contract, respectively. The file access contract can verify the previous operation, further ensuring the data confidentiality.

[0112] Figure 4 A flowchart of an access control method provided by the embodiment of the present application is shown in FIG. 1, which includes the following steps: Figure 4

[0113] Step S410, in response to receiving a storage request for storing a second file, the second file is encrypted by a storage management contract of the blockchain to obtain ciphertext corresponding to the second file;

[0114] Here, the storage management contract (Store Manager Contract) is a smart contract on the blockchain, which is used to encrypt the stored file and is responsible for adding attribute policies to the file.

[0115] After the user issues a file storage request, the storage management contract needs to associate the to-be-stored file with the corresponding attribute policy. Then, the second file is encrypted using the key required by the attribute policy to obtain the ciphertext corresponding to the second file, i.e., the encrypted file.

[0116] The encryption process of the to-be-stored second file can be implemented by the following steps:

[0117] Step S4101, the second attribute policy corresponding to the second file is found from the attribute subchain by the storage management contract;

[0118] Here, the attribute subchain stores the attribute policy corresponding to each category of file. In implementation, the second attribute policy corresponding to the hash value of the second file can be found based on the hash attribute mapping table in the attribute subchain.

[0119] ​Step S4102, determining, by the storage management contract, a third key corresponding to the second attribute policy;

[0120] Here, the storage management contract can obtain the third key required by the second attribute policy from the attribute subchain when querying the second attribute policy corresponding to the second file.

[0121] Step S4103, encrypting, by the storage management contract, the second file by using the third key to obtain ciphertext corresponding to the second file.

[0122] Here, the symmetric encryption technology such as the Advanced Encryption Standard (AES) is used to encrypt the file by using the key of the attribute policy matched with the file.

[0123] Compared with the CP-ABE algorithm based on the ciphertext access policy in the related art, the time consumption and the computing resource consumption are large, and the file storage on the blockchain is not suitable for actual application. The access control scheme based on the attribute policy provided in the embodiment of the application uses the symmetric encryption technology to encrypt the shared data file such as the second file, so that the time consumption of the access control can be saved, and the actual application of multiple different verification entities can be further adapted.

[0124] In some embodiments, the attribute subchain does not store the attribute policy of the second file for the file category, and the storage management contract needs to generate a file in accordance with the XACML standard to specify the policy. Meanwhile, the second file is published on the distributed file system, and after the hash value is obtained, it is added to the attribute subchain as a transaction. In the implementation, the following steps can be used to achieve the above-mentioned process:

[0125] Step S4104, generating, by the storage management contract, a new second attribute policy in the case that the second attribute policy corresponding to the second file is not found in the attribute subchain;

[0126] Here, the attribute policy generated this time can be used as the second attribute policy mentioned above when storing the second file of the same category next time.

[0127] Step S4105, associating, by the storage management contract, the new second attribute policy with the second file to obtain an association relationship;

[0128] Step S4106, storing, by the storage management contract, the association relationship in the hash attribute mapping table of the attribute subchain.

[0129] Here, after generating a new second attribute policy each time, the storage management contract regards the process as a transaction and records it in the attribute subchain.

[0130] Step S420, publishing the ciphertext on the distributed file system by executing a file publishing operation of the file storage contract of the blockchain;

[0131] Here, the file storage contract (Store File Contract) is a smart contract for storing files on the blockchain. In implementation, the file can be published to a distributed file system such as IPFS, and the corresponding file hash on IPFS is recorded on the blockchain.

[0132] The distributed file system is used to store the ciphertext and determine the hash of the ciphertext, so that the time overhead and computational cost of the blockchain are reduced by using the distributed file system as a file storage platform.

[0133] Step S430, recording the file publishing operation as a transaction in the blockchain by the file storage contract.

[0134] Here, the file storage contract publishes the second file on the distributed file system, and the file publishing operation is stored as a transaction on the blockchain. At the same time, the hash value of the second file, the publisher, and other information are recorded in the hash attribute mapping table of the attribute subchain, so that the next time the new second attribute policy is generated to encrypt other files of the same category.

[0135] In the embodiment of the application, first, in response to receiving a storage request for storing a second file, the second file is encrypted by the storage management contract of the blockchain to obtain the ciphertext corresponding to the second file; then, the ciphertext is published on the distributed file system by executing a file publishing operation of the file storage contract of the blockchain; finally, the file publishing operation is recorded as a transaction in the blockchain by the file storage contract. The application encrypts shared data files using symmetric encryption technology, and realizes the simultaneous identity and attribute policy through two private chains, which can be securely and traceably verified, and has better expandability than the original scheme.

[0136] Figure 5 A flowchart of an access control method provided by the embodiment of the application is shown in FIG. 8, which includes the following steps: Figure 5

[0137] Step S510, verifying the identity of the participant of the attribute subchain when the participant applies to change the third attribute policy in the attribute subchain by the access management contract;

[0138] Here, the participant of the attribute subchain represents all users registered with the blockchain.

[0139] ​The third attribute policy is any attribute policy in the attribute subchain, which can be the same as at least one of the first attribute policy and the second attribute policy, or different from the first attribute policy and the second attribute policy. It should be understood that the attribute policies of different types of files are different.

[0140] The process of verifying the identity of the participant by the access management contract can be seen from the description of steps S120 to S140.

[0141] Step S511, in the case where the identity of the participant is verified, the changed third attribute policy is published to the attribute subchain by the storage management contract;

[0142] Here, the storage management contract updates the changed third attribute policy to the hash attribute mapping table in the attribute subchain, facilitating subsequent encryption of the corresponding file based on the hash attribute mapping table.

[0143] Step S512, the fourth key corresponding to the changed third attribute policy is generated by the storage management contract and stored in the attribute subchain;

[0144] In some embodiments, in order to prevent other participants from seeing the key, the public key of the blockchain is used for encryption, and only the blockchain can obtain the real key. Step S513 can be implemented in the following way: the fourth key is encrypted by the storage management contract with the public key of the blockchain to obtain a fifth key; and the fifth key is stored in the attribute subchain by the storage management contract.

[0145] Step S513, in the case where the attribute subchain and the blockchain are in an updated attribute policy state, receiving a file access request of a second user by the access management contract of the slave chain;

[0146] Here, the updated attribute policy state indicates that the participant of the attribute subchain applies to change any attribute policy in the attribute subchain.

[0147] Step S514, in response to the file access request, the blockchain generates a slave chain with the same structure;

[0148] Here, the blockchain and the slave chain have the same structure, and the slave chain is parallel to the blockchain. While the blockchain updates the key for the purpose of ensuring forward revocation, the slave chain can access the attribute subchain through the access management contract, so that the current request can be verified according to the latest attribute policy.

[0149] Step S515, in the case where the second user passes the verification, publishing the file access request as a transaction on the slave chain by the file access contract of the slave chain;

[0150] Here, the second user is verified and the file access request is processed by the off-chain access management contract; the transaction on the off-chain is recorded by the off-chain file access contract and published on the off-chain.

[0151] Step S516, in the case that the update attribute policy state is exited on the blockchain, the transaction on the off-chain is merged to the blockchain.

[0152] Here, after the update of the blockchain is completed, the transaction on the off-chain is merged to the blockchain, and since it is considered that the blockchain can have multiple attribute updates in the life cycle of an off-chain, the attribute policy needs to be verified when the transaction is merged to determine whether it conforms to the current latest attribute policy.

[0153] In some embodiments, the transaction on the attribute sub-chain is viewed by the file storage contract of the blockchain to determine at least one changed attribute policy; the file corresponding to the at least one changed attribute policy is determined from the hash attribute mapping table by the file storage contract; and the file corresponding to the at least one changed attribute policy is re-encrypted by the storage management contract using the fourth key.

[0154] The file storage contract of the blockchain views the transaction on the attribute sub-chain to find the corresponding modified (added, updated, deleted) attribute policy, and re-encrypts the file corresponding to the modified attribute using a new key according to the file-attribute mapping table. Since the number of users is huge, it is impossible to update the attribute of each user in real time, and therefore the attribute sub-chain will automatically update the key corresponding to the attribute policy after a fixed time to ensure that the key previously obtained by the user is invalid, thereby realizing dynamic revocation of attribute access control by updating the key.

[0155] The above access control method will be described below in combination with a specific embodiment, however, it should be noted that the specific embodiment is only used to better illustrate the present application and does not constitute an improper limitation on the present application.

[0156] Considering that the attribute set possessed by the requester is flexibly used to determine whether to grant the requester access, the present embodiment adopts an attribute policy based access control scheme. At the same time, in order to save the time overhead of access control, while realizing the attribute policy based access control, the off-chain structure and symmetric encryption technology are further adopted to adapt to the actual application of multiple different verification entities. The present application uses symmetric encryption to encrypt the shared data file, and realizes identity and attribute policy through two private chains, which can realize secure and traceable security verification and has better expansibility. Finally, considering the storage overhead of the blockchain, the blockchain is used as a file sharing platform, and the IPFS is used as a file storage platform to reduce the time overhead and calculation cost of the blockchain.

[0157] As Figure 6 shown in the following figure, the embodiments of the present application define the following entities: a participant 601 (i.e., a user), an identity subchain 602, an attribute subchain 603, a file 604, a storage management contract 605, a file storage contract 606, an access management contract 607, a file access contract 608, an IPFS 609, a blockchain 610, and a sidechain 611, wherein:

[0158] The participant 601 is a user requesting access;

[0159] The identity subchain 602 is a private chain for identity verification, and all identity verifications by various institutions and departments are recorded on the identity subchain 602;

[0160] The attribute subchain 603 is a private chain for attribute management and verification, and is jointly maintained by the file sharing platform party and relevant institutions;

[0161] The file 604 is various types of files (such as medical cases, industrial data, etc.) that need to be shared;

[0162] The storage management contract 605 is responsible for encrypting the document and adding attribute policies;

[0163] The file storage contract 606 is a smart contract for storing files, which is published to the IPFS 609 and records the corresponding file hash on the attribute subchain;

[0164] The access management contract 607 is used for verification and authorization of user access to the file, that is, verification of attribute policies;

[0165] The file access contract 608 grants the corresponding user the key k to decrypt the file when the verification is successful;

[0166] The hash-attribute mapping table records the mapping relationship between the file hash and the attribute policy, including the file name, the IPFS file hash (hi), and the corresponding attribute policy p. The user can see all the file names, IPFS file hashes, and attribute policies in the blockchain browser;

[0167] The IPFS 609 is used to store data in a distributed manner;

[0168] The blockchain 610 is the main chain, which can be a blockchain supporting smart contracts such as Ethereum, Hyperledger, etc.;

[0169] From the side chain 611 (Sidechain), the side chain is attached to the blockchain 610 to interact with the main chain. In the process of updating the attribute policy of the attribute subchain 603 and the blockchain 610, the user can initiate a transaction request to the side chain 611, so that the main chain can use the original backup to normally trade when updating.

[0170] The embodiments of the present application realize file storage, access and attribute policy update through a multi-blockchain structure and IPFS.

[0171] In some embodiments, file storage is realized by the following process:

[0172] Step S621, determine the attribute policy corresponding to the file to be stored through the storage management contract;

[0173] When the user issues a file storage request, the storage management contract associates the document fi with the policy p (query the attribute subchain, and the attribute subchain stores different policies for each category to find the attribute policy corresponding to the file category). If p does not exist, the storage management contract will generate a file that conforms to the XACML standard to specify the policy. After generating a new policy each time, the storage management contract publishes the new attribute policy as a transaction in the attribute subchain 603.

[0174] Step S622, encrypt the file to be stored based on the key required by the attribute policy, to obtain the ciphertext;

[0175] When the storage management contract queries the policy p corresponding to fi, it can also take the key pk required by the corresponding policy from the attribute subchain (p and pk are one-to-one), and then use the symmetric encryption function (such as AES) to encrypt fi to obtain the encrypted document, that is, the ciphertext ei.

[0176] Step S623, upload the ciphertext to the IPFS network through the file storage contract;

[0177] After obtaining the ciphertext ei, the file storage contract uploads it to the IPFS network to obtain the corresponding file hash record hi.

[0178] In the embodiments of the present application, when the user needs to store a file, the storage management contract submits the file for encryption (finds the key of the attribute policy corresponding to the file hash from the attribute subchain); then, the storage management contract hands over the encrypted file to the file storage contract; the file storage contract publishes on the IPFS, and the publishing file operation is considered as a transaction stored on the blockchain 610, and records the file hash, publisher and other information, and maintains a hash-attribute mapping table, so as to re-encrypt after the attribute policy is updated.

[0179] In some embodiments, file access is realized by the following process:

[0180] Step S631, the user sends a file access request to the access management contract;

[0181] The file access request includes the file name to be accessed, the user's identity, and the attribute information required for file access.

[0182] Step S632, the access management contract forwards the file access request to the identity subchain, and obtains attribute verification information based on the identity information obtained from the identity subchain;

[0183] When the user requests file access permission from the access management contract, the attribute subchain and the identity subchain are pre-configured with a method based on the European Electronic Signature and Trust System (eIDAS) and an identity verification process. The information about the digital identity (such as title, license, qualification, age, etc.) is obtained from the service agency providing identity verification. The user first requests from the access management contract and submits his own identity information, which includes the attribute information required for file access; through the architecture of SAML2 (Security Assertion Markup Language), the access management contract forwards the request to the identity subchain. Then, the access management contract obtains the proof of the corresponding attribute of the user from the identity information obtained from the identity subchain and the attribute subchain; at this point, the access management contract has obtained all the attribute verification information.

[0184] Finally, the file access contract receives the message of successful attribute verification, calls the Oracle to check the overall validity of the previous steps of the access management contract. If the check is successful, the file access contract will issue a transaction to confirm the completion of the verification.

[0185] Step S633, the file access contract receives the authorization message and extracts the corresponding attribute policy key from the attribute subchain to the user.

[0186] Before sending the transaction, the file access contract should encrypt the key pk to prevent it from being leaked to all blockchain participants. The file access contract encrypts pk using the user's public key to obtain EU pk(k), and the file access contract initiates a transaction with EU pk(k) as input data and submits it to the blockchain. Finally, the user becomes the only one who can decrypt EU pk(k) using his own private key. After the user decrypts pk, the user can further decrypt the ciphertext ei using pk to obtain the plaintext file di.

[0187] In an embodiment of the present application, when a user requests to access a file, he first submits the file he needs to access and his identity to the access management contract of the blockchain. The access management contract finds the attribute policy corresponding to the file from the hash-attribute mapping table, and finds the specific attributes corresponding to the attribute policy from the attribute subchain, and queries the identity attributes owned by the user through the identity subchain access (this step may involve user privacy issues. The identity subchain can be privately owned by a third party or government department, and the attributes are confirmed through an external interface instead of being directly disclosed to the public). After all the attributes of the user are successfully verified, the file access contract receives the authorization message and verifies the validity of the authorization operation process. It extracts the key corresponding to the attribute policy from the attribute subchain and gives it to the user. The user can then decrypt the file for access.

[0188] In some embodiments, since key distribution is used for access control, key revocation needs to be implemented by rekeying. The global key index is in the attribute subchain, so the attribute subchain is also needed to implement the key update operation. The detailed steps are as follows:

[0189] After a fixed time t, the miner of the attribute subchain initiates a blockchain transaction (forming a new mapping of attribute policy p to key pk). After the global key index table is constructed, the blockchain is notified to automatically execute the transaction. The storage management contract retrieves the modified attribute policy and re-encrypts the corresponding file. At this point, all users who previously obtained the key need to re-apply for the key to access the file corresponding to the IPFS hash.

[0190] Since the attribute subchain and blockchain cannot verify the current user identity during the attribute policy update phase, a slave chain is introduced to respond to access requests from the attribute subchain and blockchain when updating the attribute policy. In the design, the slave chain has the same structure as the blockchain and is parallel to the blockchain. While the blockchain is updating the key to ensure forward revocation requirements, the slave chain can access the attribute subchain through the access management contract, so that the current request can be verified according to the latest attribute policy. The detailed process is as follows:

[0191] Step S641: The user makes an access request. If the blockchain is currently in the attribute policy update state, the blockchain is forked to generate a parallel slave chain.

[0192] Step S642: The user and subsequent users who initiate requests are received by the access management contract of the slave chain and initiate verification;

[0193] Step S643: After the blockchain update is completed, merge the transactions on the slave chain with the blockchain.

[0194] Since it is considered that the main chain can have multiple attribute updates in a lifetime of a chain, it is necessary to verify whether the attribute policy meets the current latest attribute policy when merging transactions.

[0195] The following table 1 and table 2 respectively show the transaction record tuples of the blockchain and the attribute sub-chain, and it can be seen that the transaction record tuples of the blockchain include a hash pointer, a file name, a user identifier, an IPFS hash value, attribute processing, and a timestamp of a transaction, and the transaction record tuples of the attribute sub-chain include a hash pointer, a participant identifier, an attribute policy, and included attribute 1, attribute 2, etc., and further include a policy key and a timestamp of a transaction:

[0196] Table 1

[0197]

[0198]

[0199] Table 2

[0200]

[0201] In the embodiments of the present application, when a participant of the attribute sub-chain applies to change a certain attribute policy, a transaction is initiated on the attribute sub-chain. After the participant is authenticated by the certificate authority, the participant can publish the new attribute policy to the attribute sub-chain, and generate a new key, that is, the newly generated key is encrypted using the public key of the blockchain, and the encrypted key is added to the blockchain, and the blockchain is informed of the attribute policy modification. It should be noted that, in order to prevent other participants from seeing the key, the public key of the main chain is used for encryption, and only the main chain can obtain the real key.

[0202] The file storage contract on the blockchain views the transaction on the attribute sub-chain, finds out the corresponding modified (added, updated, deleted) attribute policy, and re-encrypts the file corresponding to the modified attribute using the new key according to the hash attribute mapping table. It should be noted that, due to the huge number of users, it is impossible to update the attributes of each user in real time, and therefore the attribute sub-chain can automatically update and replace the key after a fixed time to ensure that the key previously obtained by the user is invalid.

[0203] The embodiments of the present application adopt a multi-chain structure, and the blockchain includes two private chains, that is, the attribute sub-chain and the identity sub-chain, wherein the attribute sub-chain stores the mapping relationship between the attribute policy and the key, and the identity sub-chain realizes identity management mapping (provided by an identity authentication service provider), and realizes expandable attribute allocation, which is more friendly in dynamic updating than the traditional attribute encryption method.

[0204] The parallel chain structure of the side chain and the main chain is used to realize dynamic updating and revocation, that is, while the main chain updates the key to ensure the forward revocation requirement, the slave chain can access the attribute sub-chain through the access management contract, so that the current access request can be verified according to the latest attribute policy. The attribute sub-chain updates the attribute policy, and in the attribute sub-chain update state, the blockchain forks the slave chain to perform transactions according to the original attribute policy backup, merges the slave chain after the update is completed and performs verification, which ensures normal transactions during the policy update period, and also revokes the key distribution during the update period, realizes forward security and backward security.

[0205] Compared with the related art, the embodiments of the application have at least the following technical advantages: the private chain is used to store the attribute policy and the identity policy, ensuring the security and privacy of the attribute policy. A large number of user accesses are supported, and the key access is traceable and manageable; the symmetric encryption algorithm is used instead of the CP-ABE encryption algorithm, greatly improving the read-write efficiency of large files. The encryption algorithm is efficient, saving computing and time overheads, and the encryption and decryption time of large file storage and multiple attributes can meet the actual application; the attribute policy is maintained by the file sharing platform, and the identity policy is provided by a third party service provider (government departments, banks and hospitals and related institutions). It is suitable for scenarios with a large number of users (because government departments, banks and hospitals and related institutions have a large number of users); at the same time, the identity verification and the attribute policy are separated, and the system security is stronger; IPFS is used as a file storage platform, and the blockchain is used to record the IPFS file hash, saving the blockchain storage space and improving the blockchain throughput. At the same speed of block generation, more transactions can be processed.

[0206] Based on the foregoing embodiments, the embodiments of the application further provide an access control device, which includes the modules included and the units included by the modules, and can be implemented by a processor in an electronic device; of course, it can also be implemented by a specific logic circuit; in the implementation process, the processor can be a central processing unit (CPU), a micro processing unit (MPU), a digital signal processor (DSP) or a field programmable gate array (FPGA).

[0207] Figure 7 The composition structure diagram of an access control device provided by the embodiments of the application is shown in Figure 7 The device 700 includes a first receiving module 710, a first determining module 720, a second determining module 730, an attribute verification module 740 and an authorization module 750, wherein:

[0208] The first receiving module 710 is configured to receive, by the access management contract of the blockchain, an access request for a first file from a first user; the access request includes an identity of the first user;

[0209] The first determining module 720 is configured to determine, by the access management contract, attribute information of the first user based on a first attribute policy corresponding to the first file, by calling an attribute subchain of the blockchain; the attribute subchain is a private chain for managing user attribute information.

[0210] The second determining module 730 is configured to determine, by the access management contract, identity information of the first user based on the identity, by calling an identity subchain of the blockchain; the identity subchain is a private chain for storing identity authentication records.

[0211] The attribute verification module 740 is configured to verify, by the access management contract, the attribute information and the identity information of the first user.

[0212] The authorization module 750 is configured to authorize, by a file access contract of the blockchain, the first user in the case where the first user passes the verification.

[0213] In some possible embodiments, the first file is stored in a distributed file system, and the apparatus 700 further includes an obtaining module and a third determining module, where: the obtaining module is configured to obtain, by the access management contract, a hash value of the first file in the distributed file system; and the third determining module is configured to determine, by the access management contract, the first attribute policy corresponding to the first file based on the hash value of the first file, from a preset hash attribute mapping table; the hash attribute mapping table is configured to record a corresponding relationship between a file hash value and an attribute policy.

[0214] In some possible embodiments, the second determining module includes a forwarding unit and a first determining unit, where: the forwarding unit is configured to forward, by the access management contract, the access request to the identity subchain of the blockchain in the case where the attribute information of the first user exists in the attribute subchain; and the first determining unit is configured to determine, by the identity subchain, the identity information of the first user based on the identity.

[0215] In some possible embodiments, the authorization module includes a second determination unit, a first encryption unit and a transaction issuance unit, wherein: the second determination unit is used to determine the first key corresponding to the first attribute policy through the file access contract when the first user passes the verification; the first key is used to decrypt the ciphertext corresponding to the first file; the first encryption unit is used to encrypt the first key with the public key of the first user through the file access contract to obtain a second key; the transaction issuance unit is used to initiate a transaction request with the second key as input through the file access contract and submit the transaction request to the attribute subchain to realize authorization of the first user; wherein, the second key is used by the first user to decrypt with his own private key to obtain the first key.

[0216] In some possible embodiments, the device further includes a first file encryption module, a file publishing module and a first transaction recording module, wherein: the first file encryption module is used to, in response to receiving a storage request to store the second file, encrypt the second file through the storage management contract of the blockchain to obtain the ciphertext corresponding to the second file; the storage management contract is used to associate the file to be stored with the corresponding attribute policy; the file publishing module is used to execute a file publishing operation through the file storage contract of the blockchain to publish the ciphertext on the distributed file system; wherein the distributed file system is used to store the ciphertext and determine the hash of the ciphertext; the first transaction recording module is used to record the file publishing operation as a transaction in the blockchain through the file storage contract.

[0217] In some possible embodiments, the first file encryption module includes a search unit, a third determination unit, and a second encryption unit, wherein: the search unit is used to search the second attribute policy corresponding to the second file from the attribute subchain through the storage management contract; the third determination unit is used to determine the third key corresponding to the second attribute policy through the storage management contract; and the second encryption unit is used to encrypt the second file with the third key through the storage management contract to obtain the ciphertext corresponding to the second file.

[0218] In some possible embodiments, the first file encryption module further includes a generating unit, an associating unit and a first storage unit, wherein: the generating unit is configured to, in a case where the second attribute policy corresponding to the second file is not found in the attribute subchain, generate a new second attribute policy through the storage management contract; the associating unit is configured to associate the new second attribute policy with the second file through the storage management contract to obtain an association relationship; and the first storage unit is configured to store the association relationship in the hash attribute mapping table of the attribute subchain through the storage management contract.

[0219] In some possible embodiments, the apparatus 700 further includes a policy updating module, a policy publishing module and a key updating module, wherein: the policy updating module is configured to, in a case where a participant of the attribute subchain applies to change a third attribute policy in the attribute subchain, verify the identity of the participant through the access management contract; the policy publishing module is configured to, in a case where the identity of the participant is verified, publish the changed third attribute policy to the attribute subchain through the storage management contract; and the key updating module is configured to generate a fourth key corresponding to the changed third attribute policy and store the fourth key to the attribute subchain through the storage management contract.

[0220] In some possible embodiments, the apparatus 700 further includes a second receiving module, a generating module, a second transaction recording module and a merging module, wherein: the second receiving module is configured to, in a case where the attribute subchain and the blockchain are in an attribute policy updating state, receive a file access request of a second user through the access management contract of the slave chain; the generating module is configured to, in response to the file access request, generate a slave chain with the same structure as the blockchain; the second transaction recording module is configured to, in a case where the second user is verified, publish the file access request as a transaction on the slave chain through the file access contract of the slave chain; and the merging module is configured to, in a case where the blockchain exits the attribute policy updating state, merge the transaction on the slave chain to the blockchain.

[0221] In some possible embodiments, the apparatus 700 further includes a fourth determining module, a fifth determining module and a second file encryption module, wherein: the fourth determining module is configured to view the transaction on the attribute subchain through the file storage contract, and determine at least one changed attribute policy; the fifth determining module is configured to determine the file corresponding to the at least one changed attribute policy from the hash attribute mapping table through the file storage contract; and the second file encryption module is configured to re-encrypt the file corresponding to the at least one changed attribute policy with the fourth key through the storage management contract.

[0222] It should be noted that the above device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0223] It should be noted that in the embodiments of the present application, if the above access control method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the embodiments of the present application can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a plurality of instructions for causing an electronic device (which can be a smart phone with a camera, a tablet computer, etc.) to execute all or part of the method described in the embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk, and various media that can store program codes. Thus, the embodiments of the present application are not limited to any specific hardware and software combination.

[0224] Correspondingly, the embodiments of the present application provide a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the access control method in any of the above embodiments. Correspondingly, the embodiments of the present application also provide a chip, which includes a programmable logic circuit and / or program instructions, and when the chip is running, it is used to implement the steps of the access control method in any of the above embodiments. Correspondingly, the embodiments of the present application also provide a computer program product, which is used to implement the steps of the access control method in any of the above embodiments when the computer program product is executed by a processor of an electronic device.

[0225] Based on the same technical concept, the embodiments of the present application provide an electronic device for implementing the access control method described in the above method embodiments. Figure 8 A hardware entity diagram of an electronic device provided by the embodiments of the present application is shown in FIG. 8, which includes a memory 810 and a processor 820. The memory 810 stores a computer program that can run on the processor 820, and the processor 820 implements the steps of the access control method in any of the embodiments of the present application when executing the program. Figure 8

[0226] ​The memory 810 is configured to store instructions and applications executable by the processor 820, and can also cache data (e.g., image data, audio data, voice communication data, and video communication data) to be processed by the processor 820 and modules in the electronic device, and can be implemented by FLASH or Random Access Memory (RAM).

[0227] The processor 820 implements the steps of any of the access control methods described above when executing a program. The processor 820 generally controls overall operations of the electronic device 800.

[0228] The processor described above can be at least one of an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a Central Processing Unit (CPU), a controller, a microcontroller, or a microprocessor. It can be understood that the electronic device implementing the functions of the processor described above can also be other, and the embodiments of the present application are not limited specifically.

[0229] The computer storage medium / memory described above can be a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Ferromagnetic Random Access Memory (FRAM), a Flash Memory, a magnetic surface memory, an optical disc, or a Compact Disc Read-Only Memory (CD-ROM), etc. The computer storage medium / memory can also be various electronic devices including one or any combination of the above memories, such as a mobile phone, a computer, a tablet device, a personal digital assistant, etc.

[0230] It should be noted that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium and device embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

[0231] It should be understood that the "one embodiment" or "an embodiment" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that the size of the sequence number of each process in various embodiments of the present application does not mean the order of execution, and the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. The sequence number of the above embodiments of the present application is only for description, not representing the advantages and disadvantages of the embodiments.

[0232] It should be noted that in this document, the term "comprising" or "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or includes elements inherent to such process, method, article or device. Without more limitations, the element defined by the statement "including a" does not exclude the presence of additional identical elements in the process, method, article or device including the element.

[0233] In several embodiments provided by the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The above-described device embodiments are only schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored, or not executed. In addition, the coupling or direct coupling or communication connection between the various components shown or discussed can be indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0234] The units described as separate components above can or can not be physically separate, and the components shown as units can or can not be physical units; they can be located in one place or distributed on multiple network units; and part or all of the units can be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0235] In addition, each functional unit in each embodiment of the present application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be realized in the form of hardware or in the form of hardware plus software functional unit.

[0236] Alternatively, the integrated unit of the present application, if realized in the form of a software function module and sold or used as an independent product, can also be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the embodiments of the present application can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for causing an apparatus to perform all or part of the methods described in the embodiments of the present application. The foregoing storage medium includes mobile storage devices, ROM, magnetic or optical disks, and various media that can store program codes.

[0237] The methods disclosed in the several method embodiments of the present application can be combined arbitrarily without conflict to obtain new method embodiments.

[0238] The features disclosed in the several method or device embodiments of the present application can be combined arbitrarily without conflict to obtain new method embodiments or device embodiments.

[0239] The above is only an implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. An access control method characterized by, The method is applied to a blockchain, and the method comprises: receiving, by an access management contract of the blockchain, an access request of a first user to a first file; the access request comprises an identity of the first user; determining, by the access management contract, attribute information of the first user based on a first attribute policy corresponding to the first file, by calling an attribute subchain of the blockchain; the attribute subchain is a private chain for managing user attribute information; and the attribute policy is maintained by a file platform party; determining, by the access management contract, identity information of the first user based on the identity, by calling an identity subchain of the blockchain; the identity subchain is a private chain for storing identity authentication records; and identity authentication is provided by a third-party service provider; verifying, by the access management contract, the attribute information and the identity information of the first user; in a case where the first user passes the verification, determining, by a file access contract, a first key corresponding to the first attribute policy; the first key is used for decrypting a ciphertext corresponding to the first file; encrypting, by the file access contract, the first key with a public key of the first user to obtain a second key; and initiating a transaction request by taking the second key as input, and submitting the transaction request to the attribute subchain, so as to realize authorization of the first user; wherein the second key is used for the first user to decrypt the first key with a private key of the first user.

2. The method of claim 1, wherein, The first file is stored in a distributed file system, and the method further comprises: obtaining, by the access management contract, a hash value of the first file in the distributed file system; determining, by the access management contract, the first attribute policy corresponding to the first file from a preset hash attribute mapping table based on the hash value of the first file; the hash attribute mapping table is used for recording a corresponding relationship between a file hash value and an attribute policy.

3. The method of claim 1, wherein, The method further comprises: in a case where the attribute information of the first user exists in the attribute subchain, forwarding, by the access management contract, the access request to the identity subchain of the blockchain; determining, by the identity subchain, the identity information of the first user based on the identity.

4. The method of claim 2, wherein, The method further comprises: in response to receiving a storage request of a second file, encrypting, by a storage management contract of the blockchain, the second file to obtain a ciphertext corresponding to the second file; the storage management contract is used for associating a to-be-stored file with a corresponding attribute policy; publishing, by a file storage contract of the blockchain, the ciphertext on the distributed file system by performing a publish file operation; wherein the distributed file system is used for storing the ciphertext and determining a hash of the ciphertext; recording, by the file storage contract, the publish file operation as a transaction record in the blockchain.

5. The method of claim 4, wherein, The method further comprises: encrypting, by the storage management contract of the blockchain, the second file to obtain the ciphertext corresponding to the second file, comprises: finding, by the storage management contract, a second attribute policy corresponding to the second file from the attribute subchain; determining, by the storage management contract, a third key corresponding to the second attribute policy; encrypting, by the storage management contract, the second file with the third key to obtain ciphertext corresponding to the second file.

6. The method of claim 5, wherein, The method further comprises: in the case where the second attribute policy corresponding to the second file is not found in the attribute subchain, generating a new second attribute policy by the storage management contract; associating, by the storage management contract, the new second attribute policy with the second file to obtain an association relationship; storing, by the storage management contract, the association relationship in a hash attribute mapping table of the attribute subchain.

7. The method of claim 2, wherein, The method further comprises: in the case where a participant of the attribute subchain applies to change a third attribute policy in the attribute subchain, verifying, by the access management contract, the identity of the participant; in the case where the identity of the participant is verified, publishing, by the storage management contract, the changed third attribute policy to the attribute subchain; generating, by the storage management contract, a fourth key corresponding to the changed third attribute policy and storing it to the attribute subchain.

8. The method of claim 7, wherein, The method further comprises: in the case where the attribute subchain and the blockchain are in an attribute policy updating state, receiving, by the access management contract from the chain, a file access request of a second user; in response to the file access request, the blockchain generates a slave chain with the same structure; in the case where the second user is verified, publishing, by the file access contract of the slave chain, the file access request as a transaction on the slave chain; in the case where the blockchain exits the attribute policy updating state, merging the transaction on the slave chain to the blockchain.

9. The method of claim 7, wherein, The method further comprises: viewing, by the file storage contract, the transaction on the attribute subchain to determine at least one changed attribute policy; determining, by the file storage contract, the file corresponding to the at least one changed attribute policy from the hash attribute mapping table; re-encrypting, by the storage management contract, the file corresponding to the at least one changed attribute policy with the fourth key.

10. An access control device, characterized in that The device comprises: a first receiving module configured to receive, by an access management contract of a blockchain, an access request of a first user to a first file; the access request includes an identity of the first user; a first determining module configured to determine, by the access management contract, attribute information of the first user based on a first attribute policy corresponding to the first file; the attribute subchain is a private chain for managing user attribute information; the attribute policy is maintained by a file platform party; a second determining module configured to determine, by the access management contract, identity information of the first user based on the identity; the identity subchain is a private chain for storing identity authentication records; identity verification is provided by a third party service provider; An attribute verification module is configured to verify attribute information of the first user and the identity information by the access management contract; An authorization module is configured to, in a case where the first user passes the verification, determine a first key corresponding to the first attribute policy by a file access contract, the first key being used for decrypting a ciphertext corresponding to the first file, encrypt the first key by a public key of the first user by the file access contract to obtain a second key, initiate a transaction request by taking the second key as an input by the file access contract, and submit the transaction request to the attribute subchain to realize authorization of the first user, wherein the second key is used for the first user to decrypt the first key by a private key of the first user.

11. An electronic device comprising a memory and a processor, said memory storing a computer program operable on the processor, characterized in that, The processor implements the steps in the method of any one of claims 1 to 9 when executing the program.

12. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program implements the steps in the method of any one of claims 1 to 9 when executed by the processor.

Images