Medical data hierarchical access control and sharing method based on on-chain and off-chain collaboration

Abstract

The present invention discloses a medical data hierarchical access control and sharing method with on-chain and off-chain collaboration, including the following five functional modules: attribute authorization center, data owner, data user, interstellar file system, main-side chain module; the workflow is divided into 4 stages: initialization stage, ciphertext storage stage, on-chain stage and access stage. The method described in the present invention realizes fine-grained access control and hierarchical attribute encryption in the process of medical data sharing; hierarchical attribute encryption at three levels of high sensitivity, medium sensitivity and low sensitivity is implemented according to the sensitivity of medical data, and a data storage method combining on-chain and off-chain is adopted to solve the blockchain storage problem, and the main-side chain is divided into one main and three sides according to the data sensitivity to store the corresponding ciphertext address and symmetric key, and the multiplication homomorphic RSA cryptographic system is used to ensure the attribute privacy during the authorization verification period, and the P-TL smart contract is used on the side chain to verify the timeliness and correctness of the entire transaction.

Description

[0001] The present invention relates to the field of medical data security control, and in particular to a medical data hierarchical access control and sharing method that collaborates on-chain and off-chain. Background Art

[0002] In recent years, blockchain has been widely used in medical data sharing due to the immutability of its blocks. However, existing technologies have certain security issues. Whether combined with federated learning or cloud computing, they have undoubtedly improved efficiency to a certain extent, but they lack reasonable access control mechanisms and data encryption algorithms, are vulnerable to poisoning attacks and single point failures, and may cause data and privacy leaks, threatening the security of medical data.

[0003] Access control is one of the important methods of privacy protection, which can effectively prevent the leakage of medical information. The application of blockchain, attribute encryption and smart contracts has greatly improved the security of data sharing. However, at present, most access strategies have low intelligence and scalability levels. The storage space is limited when all medical data is uploaded to the chain, resulting in low storage efficiency, poor sharing efficiency and scalability. Summary of the invention

[0004] In view of the defects existing in the prior art, the present invention proposes a medical data hierarchical access control and sharing method (AC-CSS) that collaborates on-chain and off-chain. It combines attribute encryption of ciphertext strategy (CP-ABE) and AES symmetric encryption algorithm, performs hierarchical encryption according to different data sensitivities and stores the ciphertext on the InterPlanetary File System (IPFS). Then, the encrypted address and AES symmetric key are stored on the side chain according to the sensitivity, which is convenient for main chain indexing. Through vectorized access strategy, policy hiding is realized, and the combination of on-chain and off-chain is realized, which frees up the storage space of blockchain, realizes hierarchical access control, and improves security and efficiency.

[0005] On the other hand, the multiplicative homomorphic RSA cryptosystem is used to ensure attribute privacy during authorization verification, and the P-TL smart contract is utilized on the side chain to verify the timeliness and correctness of the entire transaction.

[0006] In order to achieve the above objectives, the medical data hierarchical access control and sharing method for on-chain and off-chain collaboration described in the present invention includes the following five functional modules:

[0007] ① Attribute Authorities, AA: responsible for managing user attributes and generating user attribute keys;

[0008] ②Data Owner, DO: is the publisher of the data; uses the access control algorithm MSC-CP-ABE based on the main side chain and hierarchical attribute encryption to implement the AES encryption algorithm for medical data, hierarchically encrypts and uploads the ciphertext of the file to the interstellar file system IPFS, and formulates access control policies for the data. In order to improve system efficiency, DO stores transactions Tb sto Send the storage ciphertext address and symmetric decryption key to the side chain;

[0009] ③ Data User, DU: First, get the ciphertext address and symmetric key from the side chain, then get the ciphertext from the interstellar file system IPFS, and decrypt the ciphertext indexed by the address; DU matches the attribute set with the hiding strategy locally and encrypts it using the RSA encryption algorithm cryptographic system; if the match is successful, it generates an access certificate without privacy leakage, and then broadcasts it to other nodes in the data chain for consensus verification; the matching and verification process is completed by the P-TL contract. After the verification is passed, DO generates an access storage transaction Tb sto The data chain is used for consensus verification; once authorized, the DU's attribute set satisfies the access policy and the access time period, and the address where the ciphertext is stored in the Interstellar File System IPFS is obtained, and then the key can be obtained from the DO to decrypt the ciphertext indexed by the address and obtain the data; in addition, the malicious DU obtains the key by forging a proof, but because its attribute set or access time period does not meet the access policy set by the DO, it cannot decrypt the ciphertext;

[0010] ④ Interstellar File System IPFS: stores all encrypted data of DO, realizes distributed storage of ciphertext data, reduces blockchain storage overhead, and facilitates DO storage and DU access;

[0011] ⑤Master side blockchain, MSC: It consists of the main chain and the side chain. The main chain is mainly used to index the side chain. The side chain is mainly used to set up the P-TL contract to verify the proof and save the index address and symmetric key of the ciphertext with different sensitivities of high, medium and low, verify the access rights and obtain the address information of resource storage, complete the verification on the chain, and perform storage transactions Tb sto and access transaction Tb acc Verification and communication, allowing DU to obtain the ciphertext address and symmetric key;

[0012] The AC-CSS workflow of the on-chain and off-chain collaborative medical data hierarchical access control and sharing method is divided into four stages, including the initialization stage, the ciphertext storage stage, the on-chain stage, and the access stage:

[0013] Initialization phase: DO and DU submit registration requests and submit relevant attributes and content to the attribute authorization center AA. After receiving the request, the attribute authorization center AA sends the keys PK, MSK, and BSK to the DO and DU. DO , BPK DO Return to DO, key PK, BSK Du , BPK Du Return to DU and initialize the parameters in the system;

[0014] Among them, PK is the public key, MSK is the master key, and BSK is the DO and BPK DO The private key and public key registered by DO in AA, BSK Du , BPK Du These are the private key and public key registered by DU in AA.

[0015] Ciphertext storage stage: In this stage, DO first generates an access policy based on a set of attributes, and stores the ciphertext in IPFS through the MSC-CP-ABE algorithm. Then IPFS returns the storage address u to DO. At this point, the data is securely stored.

[0016] On-chain stage: DO generates a storage transaction Tb by storing the ciphertext address and symmetric decryption key with the hidden strategy. sto Sent to the main side chain MSC; any DU that wants to access the data owned by DO must locally set the hidden access policy With a set of attributes If the match is successful, DU will use the RSA cryptographic system to generate Proof, submit it to the MSC main chain, and broadcast it to other nodes on the MSC side chain, thereby triggering the P-TL smart contract deployed in each node in the MSC side chain to verify the Proof and timeliness; if an agreement is reached, DO will generate a key and send it to MSC to access the transaction Tb acc , where access transaction Tb acc Used to record the access control history of DO, which is convenient for tracking, tracing and accountability;

[0017] in, is the vector generated by the access policy; is the vector generated by the attribute set;

[0018] Access phase: If the consensus process for access transactions is reached, DU will obtain the user's private key The key is stored locally in the DO and cannot be accessed by the MSC. It will be automatically distributed through secure communication channels without any human intervention; the DU obtains the ciphertext address, symmetric decryption key and user private key After that, the ciphertext will be obtained according to the ciphertext storage address, and then the symmetric decryption key and the user's private key will be used Decryption to obtain medical data;

[0019] Proof is an identification mark used to ensure that the hidden access policy and a set of attributes are successfully matched, which can be regarded as the authority to obtain the key; in order to protect the attribute privacy of DU and achieve trusted access, DU will match the hidden access policy with a set of attributes locally, that is, check If yes, a proof is generated by the RSA cryptosystem; after that, it is sent to other nodes in the MSC for verification; by exploiting the multiplicative homomorphism of RSA encryption, each node checks locally To judge the validity of the Proof; Obviously, since the attributes are encrypted and each verification process is performed locally, the privacy of any DU attribute can be protected;

[0020] In addition, in order to solve the storage limitations of blockchain, the ciphertext is stored on IPFS, and the ciphertext address, symmetric decryption key and integrity check code are sent to MSC to ensure the integrity of the stored data while improving the scalability and security of the system; Practical Byzantine Fault Tolerance (PBFT) is used to reach consensus on storage transactions and access transactions.

[0021] Preferably, the MSC-CP-ABE access control algorithm includes four stages: an initialization stage, an encrypted storage stage, an on-chain stage and a decryption stage.

[0022] Preferably, in the Master side blockchain, MSC module, the main chain and the side chain are a one-main-three-side structure, wherein the blocks on the main chain store the basic information of the side chain, and disclose information that does not involve privacy. The main chain stores the basic information of the low-sensitivity information chain, the medium-sensitivity information chain and the high-sensitivity information chain, including the side chain position and the side chain name; each side chain stores the address and symmetric key corresponding to the information of different sensitivity, and the P-TL contract is deployed on the three side chains. When the Proof of the DU is transmitted to the side chain by broadcasting through the node on the main chain, the Proof will automatically serve as the input condition of the contract, automatically execute the contract rules, and verify whether the DU has the authority to access the target resource.

[0023] Preferably, the data users (DU) are medical staff, research institutions and insurance companies.

[0024] Preferably, the hierarchical encryption is to perform symmetric encryption on medium and high sensitivity data and then perform attribute encryption, while low sensitivity data is directly encrypted by attributes.

[0025] Compared with the prior art, the present invention has the following beneficial effects:

[0026] This paper uses the existing blockchain technology, combines the attribute encryption of ciphertext strategy (CP-ABE) and the AES symmetric encryption algorithm to propose a medical data hierarchical access control and sharing model (AC-CSS) that collaborates on-chain and off-chain, and uses hierarchical encryption to achieve hierarchical access control. The blockchain storage problem is solved by using a data storage method that combines on-chain and off-chain, and the main side chain is divided into one main and three sides according to the sensitivity of the data to store the corresponding ciphertext addresses and symmetric keys. The multiplicative homomorphic RSA cryptosystem is used to ensure the attribute privacy during the authorization verification, and the P-TL smart contract is used on the side chain to verify the timeliness and correctness of the entire transaction.

[0027] In the MSC-CP-ABE model of the present invention, only the DO and DU in the MSC participate in the access control management as described above. The calculation process of encryption, decryption, data storage and matching is completed off-chain, so the security is very high. In addition, the use of IPFS to store data in the MSC-CP-ABE model can not only realize distributed and trusted access control, but also save local storage space and blockchain overhead, and protect the privacy of access policies and attributes. The feasibility, security and superiority of the model are verified through security analysis, functional comparison, algorithm performance comparison and simulation experiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 For: AC-CSS system model;

[0029] Figure 2 It is: CP-ABE access control tree structure;

[0030] Figure 3 For: AC-CSS model transaction process;

[0031] Figure 4 Schematic diagram of access control tree conversion;

[0032] Figure 5 For: main chain and side chain interaction mode;

[0033] Figure 6 It is composed of: P-TL smart contract; DETAILED DESCRIPTION

[0034] The present invention is further described in detail below in conjunction with specific implementation modes.

[0035] The medical data hierarchical access control and sharing method for on-chain and off-chain collaboration described in the present invention includes the following five functional modules:

[0036] ① Attribute Authorities (AA): AA is responsible for managing user attributes and generating user attribute keys.

[0037] ②Data Owner (DO): DO is the publisher of data. MSC-CP-ABE algorithm is used to implement AES hierarchical encryption of medical data and upload the ciphertext of the file to IPFS. At the same time, access control policies are formulated for the data. In order to improve system efficiency, DO stores transactions Tb sto Send the storage ciphertext address and symmetric decryption key to the side chain.

[0038] ③Data User (DU); DU is mainly medical staff, research institutions and insurance companies. DU first obtains the ciphertext address and symmetric key from the side chain, then obtains the ciphertext from IPFS, and then decrypts the ciphertext indexed by the address. DU matches the attribute set with the hidden strategy locally and encrypts it using the RSA cryptographic system. If the match is successful, an access proof with no privacy leakage is generated and then broadcast to other nodes in the data chain for consensus verification. Note that the matching and verification process is completed by the P-TL contract, which can improve the level of intelligent control. After verification, DO generates an access transaction Tb acc Access the data chain for consensus verification. Once authorized, when the DU's attribute set meets the access policy and the access time period, the address where the ciphertext is stored in IPFS can be obtained, and then the key can be obtained from the DO to decrypt the ciphertext indexed by the address and obtain the data. In addition, a malicious DU may obtain a key by forging a Proof, but because its attribute set or access time period does not meet the access policy set by the DO, it cannot decrypt the ciphertext.

[0039] ④ Interplanetary File System (IPFS); stores all encrypted data of DO, realizes distributed storage of ciphertext data, reduces blockchain storage overhead, and facilitates DO storage and DU access.

[0040] ⑤Master side blockchain (MSC); It consists of the main chain and the side chain. The main chain is mainly used to index the side chain. The side chain is mainly used to set up the P-TL contract to verify the proof and save the index address and symmetric key of the ciphertext with different sensitivities of high, medium and low, verify the access rights and obtain the address information of the resource storage, complete the verification on the chain, and perform Tb sto and Tb acc Verification and communication of transactions allow DU to obtain ciphertext addresses and symmetric keys.

[0041] In the MSC-CP-ABE model, only the DO and DU in the MSC participate in the access control management as described above. The calculation process of encryption, decryption, data storage and matching is completed off-chain, so the security of this model is very high. The use of IPFS to store data in the MSC-CP-ABE model can not only achieve distributed and trusted access control, but also save local storage space and blockchain overhead, and protect the privacy of access policies and attributes.

[0042] The AC-CSS model transaction process is divided into four stages: initialization stage, ciphertext storage stage, on-chain stage and access stage.

[0043] Initialization phase: In this phase, DO and DU submit registration requests and submit relevant attributes and content to AA. After receiving the request, AA sends the keys PK, MSK, and BSK to AA. DO , BPK DO Return to DO, key PK, BSK Du , BPK Du Return to DU and initialize the parameters in the system, such as the bilinear mapping group and RSA cryptosystem.

[0044] Ciphertext storage stage: In this stage, DO first generates an access policy based on a set of attributes, and stores the ciphertext in IPFS through the MSC-CP-ABE algorithm. Then IPFS returns the storage address u to DO. At this point, the data is securely stored.

[0045] On-chain phase: In this phase, DO generates a storage transaction Tb by storing the ciphertext address and symmetric decryption key with the hidden strategy. sto Any DU that wants to access data owned by the DO should locally store the hidden access policy. With a set of attributes If the match is successful, DU will use the RSA cryptographic system to generate Proof, submit it to the MSC main chain, and broadcast it to other nodes on the MSC side chain, thereby triggering the P-TL smart contract deployed in each node in the MSC side chain to verify the Proof and timeliness. If an agreement is reached, DO will generate a key and send it to MSC with an access transaction Tb acc , where access transactions are used to record the access control history of DO, which is convenient for tracking, tracing and accountability.

[0046] Access phase: In this phase, if the consensus process of the access transaction is reached, the DU will obtain Key. It should be noted that the key is stored locally in the DO and cannot be accessed by the MSC. It will be automatically distributed through a secure communication channel without any human intervention. The DU obtains the ciphertext address, symmetric decryption key and After the key is obtained, the ciphertext will be obtained according to the ciphertext storage address, and then the symmetric decryption key and The key is used to decrypt the medical data.

[0047] Proof is an identification mark used to ensure that the hidden access policy and a set of attributes are successfully matched, which can be regarded as the authority to obtain the key. As discussed above, the hidden policy has been stored and can be accessed by any node in the blockchain. In order to protect the attribute privacy of DU and achieve trusted access, DU will locally match the hidden access policy with a set of attributes, that is, check If yes, a proof is generated by the RSA cryptosystem. After that, it will be sent to other nodes in the MSC for verification. By leveraging the multiplicative homomorphism of RSA encryption, each node will check locally Obviously, since the attributes are encrypted and each verification process is performed locally, the privacy of any DU attributes can be protected.

[0048] In addition, in order to solve the storage limitation of blockchain, the ciphertext is stored on IPFS, and the ciphertext address, symmetric decryption key and integrity check code are sent to MSC to ensure the integrity of the stored data and improve the scalability and security of the system. Practical Byzantine Fault Tolerance (PBFT) is used in the model to reach consensus on storage transactions and access transactions.

[0049] Construction of medical data sharing scheme

[0050] Medical data from different sources and with different sensitivities are divided into the following three levels according to the risk level and importance of the "Guidelines for Health and Medical Data Security": high sensitivity, medium sensitivity and low sensitivity. High-sensitivity data mainly includes name, phone number, ID number, address, biometrics (fingerprint, retina, voice, gene, etc.), photos, beliefs, etc., which can identify personal identity or cause significant impact after exposure; medium-sensitivity data mainly includes age, region, family history, marriage and childbearing history, etc., which cannot identify personal identity and still have important medical significance after blurring, and the blurred results can be retained; low-sensitivity data mainly includes other medical data, such as age range, gender, disease, chief complaint, medicine, living habits, diagnosis results, surgical records, examination reports, etc. In addition, in order to achieve access control of medical data, it is divided according to the identity information of the user of the data, including the user's identity level, the user's professional level and the trust level of the user.

[0051] User identity levels are:

[0052]

[0053] in The user's professional level is:

[0054]

[0055] in User trust levels are:

[0056]

[0057] in There are three levels in total: identity level, professional level, and trust level, that is, n=3. The high level completely contains the content that can be viewed by the low level. The attribute encryption strategy is targeted at high, medium and low sensitive data M High , M Medium , M L o w There are three different access strategies, for example:

[0058] The low-sensitivity access policy is:

[0059]

[0060] All status levels are and Can access low-sensitivity data, such as Figure 4 (a);

[0061] The medium sensitive access policy is:

[0062]

[0063] That is, all identity levels are and And the professional level is Anyone can access, such as Figure 4 (b).

[0064] The highly sensitive access policy is:

[0065]

[0066] That is, the identity level is and Professional level is and trust level Only those who have Figure 4 (c).

[0067] In actual situations, the access policy of low-level sensitivity data often depends on the access policy of high-level sensitivity data. Therefore, the access control trees of high, medium and low sensitivity data in the present invention are merged, such as Figure 4 (d) The merging strategy is to use the entire low-sensitivity data access control tree as the left child of the left child of the root node of the access control tree, and use the professional level of the medium-sensitivity data access control policy as the right child of the left child of the root node of the access control tree. The left child node of the root node is connected using 2of2, and then the trust level of the high-sensitivity access control policy is used as the right child of the access control tree. The root node is connected using 2of2. Compared with the traditional access control tree, the leaf nodes are reduced by about 50%, which can effectively reduce the computing overhead.

[0068] Table 1 Variable definitions

[0069]

[0070]

[0071] The MSC-CP-ABE algorithm combines the symmetric encryption key and the CP-ABE algorithm to symmetrically encrypt medium and high sensitivity data before performing attribute encryption. For low sensitivity data, it directly encrypts the attributes, achieving hierarchical access control. When the amount of data is large, it effectively reduces the encryption and decryption time.

[0072] The MSC-CP-ABE access control algorithm includes four stages: initialization stage, encrypted storage stage, chain stage and decryption stage, including four algorithms: Setup, Enc, KeyGen and Dec.

[0073] (1) System initialization phase:

[0074] Input the security parameter α. DO executes the following initialization algorithm.

[0075] Setup(α)→(PK, MSK): Select a bilinear group with a prime order p and a generator g. Define a bilinear map

[0076] ①Generate a global public key:

[0077] ② The attribute authorization center randomly selects β, γ∈Z N , generate the master key and public key:

[0078] MSK=(g β ,γ)

[0079]

[0080] ③The final system public key is:

[0081] (2) Ciphertext storage stage

[0082] This stage mainly uses the Enc algorithm to encrypt and store data. Low For low-sensitivity data, in order to save AES keys and improve efficiency, M Low AES symmetric encryption is not performed. The encryption algorithm is as follows: Enc(PK, M High , M Medium , M Low ,δ) for the plaintext M High , M Medium , M Low Encrypt under access structure δ and output ciphertext CT. The encryption process is as follows:

[0083] ① Generate access control tree: same as CP-ABE algorithm.

[0084] ② Recursively calculate the access control tree: select a polynomial q for each node x x , polynomial q x Degree d x Than the threshold value k of the node x Less 1, that is, d x =k x -1. From the root node x High Start by selecting random numbers s High ∈Zn, the root node generator polynomial is q High , set q High (0) = s High , is the left child node x of the root node Medium The generating polynomial is q Medium , set q Medium (0) = s Medium =q Medium (index(x Medium )), is the left child node x of the left child of the root node Low The generating polynomial is q Low , set q Low (0) = s Low =q Medium (index(x Low )), for other nodes x, select polynomial q x , let q x (0) = q parent(x) (index(x)); parent(x) is the parent node of node x, randomly select d x points to fully define q x .

[0085] ③AES symmetric encryption: randomly select m High , As the AES symmetric encryption key pair m High , m Medium Encrypted ciphertext:

[0086] C=(C1 High =AES.encrypt(m High , M High ),

[0087] C1 Medium =AES.encrypt(m Medium , M Mediium ),

[0088] C1 Low =M Low )

[0089] In order to reduce the storage overhead of the blockchain, the ciphertext C is stored in IPFS, and then IPFS returns the ciphertext download link u.

[0090] ④ In order to achieve strategy hiding, the access structure δ is vectorized Embedded in the ciphertext.

[0091] ⑤ Calculate the ciphertext: Let the set of all leaf nodes in the access structure δ be Y, then the plaintext M High , M Medium , M Low The ciphertext under the access structure δ is:

[0092]

[0093] (3) Blockchain stage:

[0094] In order to perform trusted secure access control management, DO sends the ciphertext address with access policy to MSC through storage transaction, i.e.

[0095] Tx sto ={S, u, m, checkCode, sign}

[0096] Among them, S is used to identify the storage transaction, u represents the ciphertext download address, which is used to index the ciphertext C, m represents the symmetric encryption key, checkCode is the integrity check code of the ciphertext, and sign is the private key BSK registered by DO in AA DO The generated digital signature. Calculate the message digest of CT to generate the checkCode. The checkCode is generated by hashing the ciphertext. Calculate H(S, u, m, checkCode) to generate the message digest MD. Use BSKDO Cryptographic message digest (MD) Generate sign and generate storage transaction Tx sto ={S, u, m, checkCode, sign} Therefore, any DU can verify the integrity of the ciphertext through checkCode, and sign is used to prove that the transaction is sent by DO.

[0097] Tx sto After generation, it is broadcasted to other nodes of the MSC to verify the validity of the transaction through signature verification, and the ciphertext and symmetric decryption key are verified through checkCode. The details are shown in Algorithm 1.

[0098] Tx sto The validity is determined by placing the received Tx sto The generated message digest MD′ is combined with the public key BPK of DO DO The message digest MD generated by decrypting sign is compared to verify. If MD′=MD, then Tx sto In order to save the storage space of the blockchain, DO only sends the storage address u and the symmetric key m of the ciphertext to MSC. Therefore, in order to ensure the integrity of the ciphertext, it is necessary to further check whether the message digest checkCode related to u and m is equal to Tx sto The message digest checkCode in the , once verified successfully, will be packaged into a block for PBFT to reach consensus.

[0099] In order to obtain the key from DO and ensure the privacy of the attributes, DU generates a This was then combined with Matching is performed, once the If the match is successful, DU will generate a Proof to trigger the smart contract for verification.

[0100]

[0101] Where T represents the time when Proof is generated, BPK DU Indicates the public key registered by DU in AA, u indicates the ciphertext storage location that DU wants to access, The RSA cryptographic system is used The result of encrypting each element in , m represents the symmetric key to access the data, and sign is the digital signature of DU on Proof.

[0102]

[0103] After verifying that the signature of the Proof is valid, an access transaction can be generated for the DU that meets the hidden access policy defined by the DO. In addition, to ensure that any DU with a valid signature proof does have access rights, it broadcasts the proof to other nodes in the MSC and triggers each smart contract to verify whether the DU has access rights.

[0104] After that, DO generates an access transaction for a valid Proof. DO calculates the message digest of the transaction MD=H(A, BPK DU ,u,T stemp ), DO verifies the signature of MD Smart contract verifies access and generates access transactions

[0105] Tx acc ={A,T stemp , BPK DU ,u,sign} where A is used to identify the access transaction, Tstemp represents Tx acc The time of generation, sign is used to prove Tx acc It is indeed sent by DO. Note that Tx acc The publisher needs to acc The u owner of the data stored in the server remains consistent.

[0106] (4) Access phase

[0107] At this stage, the DU authorized by the MSC can obtain the key Key The data is generated by DO running the key generation algorithm KeyGen, and then DU performs the decryption algorithm Dec locally to obtain the data. Therefore, the access process can be described as follows.

[0108]

[0109] ①DO selects a random number x∈Z N , calculate g x , (S, K = g x ) is sent to the attribute authority.

[0110] ② The attribute authorization center selects a random r∈Z N , calculate D′=K (β+r) / γ =g x·(β+r) / γ , and send D to the user.

[0111] For each attribute j∈S, select a random r j ∈Z N . Then the key SK1 is calculated and returned to the user.

[0112]

[0113] ③ User calculation D = (D′) 1 / x =g (β+r) / γ

[0114]

[0115] And sent to the user through a secure channel.

[0116] The decryption algorithm combines the public key PK, the ciphertext CT, the attribute set S and the key As input, if the attribute set S satisfies the access policy δ, that is, Then output message I, otherwise, output the termination symbol #. The specific process is as follows:

[0117] ① Recursively calculate the access control tree: the same as the CP-ABE algorithm. Recursively calculate the left child node of the left child of the root node to obtain Recursively calculate the left child node of the root node to get Recursively calculate to the root node to get

[0118] ② Calculate the plaintext:

[0119] Calculate highly sensitive plaintext:

[0120]

[0121] Similarly, sensitive plaintext is calculated:

[0122]

[0123] Calculate low-sensitivity ciphertext:

[0124]

[0125] Main chain and side chain interaction method

[0126] The traditional single-chain blockchain model has insufficient storage space due to the increase in data, which in turn affects the transaction confirmation time, efficiency and other issues, and seriously affects the performance. Therefore, the main-side chain blockchain model is proposed. Compared with the traditional single-chain blockchain model, the main-side chain model is a one-main-three-side structure, such as Figure 5, one Ethereum main chain and three side chains, greatly improving storage space and performance. The blocks on the main chain store the basic information of the side chains, which can disclose information that does not involve privacy. In this study, the main chain stores the basic information of low-sensitivity information chains, medium-sensitivity information chains, and high-sensitivity information chains, such as non-privacy information such as side chain locations and side chain names. Each side chain stores addresses and symmetric keys corresponding to information of different sensitivities. P-TL contracts are deployed on the three side chains. When the nodes on the Ethereum main chain transmit the Proof of DU to the side chain by broadcasting, the Proof will automatically serve as the input condition of the contract, automatically execute the contract rules, and verify whether the DU has the authority to access the target resources.

[0127] P-TL Smart Contract

[0128] The P-TL contract includes a proof verification contract (PVC) and a real-time monitoring contract. The proof verification contract limits the life cycle of the access control policy. The ciphertext address and symmetric key can only be obtained within the permitted time range and the proof is correct, and real-time monitoring is carried out to prevent malicious behavior. The proof verification contract mainly limits the life cycle of the visitor by grading the access time of different information, and the real-time monitoring contract can monitor and record the access process. The proof verification contract maintains a list of transaction records. The real-time monitoring contract needs to maintain both the log list and the violation list. Figure 6 Shown is the composition of a P-TL contract.

[0129] Definition 5: For different data, the average access time is calculated based on the local historical browsing time records:

[0130]

[0131] If the access time to low-sensitivity data exceeds the time limit, It is considered a violation if the access time of medium sensitivity data exceeds the time limit. It is considered a violation if the access time of highly sensitive data exceeds the limit. is considered a violation.

[0132] When the DU local attribute matching is completed, DU submits Proof to the P-TL contract for verification If the conditions are met, it is submitted to DO. If not, the transaction is cancelled. This study defines the ciphertext key related information of DO as It contains four aspects of information: average access time, ciphertext address, symmetric key and hiding strategy. The complete definition is as follows:

[0133]

[0134] U={u1,u2,…ui}

[0135] M={m1,m2,…,m i}

[0136]

[0137] Represents the average access time limited by the ciphertext.

[0138] U: represents the storage address of the ciphertext.

[0139] M: represents the symmetric key corresponding to the ciphertext.

[0140] Represents the hiding strategy associated with the ciphertext of the DO.

[0141] Proof Verification Contract (PVC): This contract maintains a list of ciphertext key related information as shown in Table 2, which is sent by DO to the blockchain and saved in the list, as shown in Table 2. The table records the access time, symmetric key and ciphertext address corresponding to different ciphertext keys. By matching and verifying with Proof, Proof, k pub , Cip DO Input, only if the verification match succeeds, DU will be allowed to obtain the address of the corresponding ciphertext in IPFS. If the match fails, the transaction will be canceled.

[0142] Table 2 Example of information related to ciphertext key

[0143]

[0144] ProofVc(): As shown in Algorithm 2, it demonstrates and describes that after the user passes the local attribute matching, the user submits the Proof to the P-TL contract and enters the hidden policy element associated with the DO ciphertext. The public key k in the RSA algorithm pub = {n, c}, information in the ciphertext key related information table<Time,u,m> ←Cip DO First, use the RSA algorithm to verify The validity of the algorithm is verified, and then the correctness and timeliness of T,u,m in Proof are verified. If all are satisfied, the algorithm will output True to DO for the next storage transaction Tx acc If it is not satisfied, the algorithm will output False to DO, thus ending the transaction.

[0145]

[0146] Real-time monitoring contract: A log list and a violation list are maintained, as shown in Table 3 and Table 4. In order to regulate DU behavior, when DU exceeds the access time, its behavior will be recorded in the violation list. From the time the doctor obtains access rights to the end of the access, all its operation records will be recorded truthfully in the log list.

[0147] Table 3 Log list example

[0148]

[0149] Table 4 Example of violation list

[0150]

[0151] RT-Monitor(), as shown in Algorithm 5, demonstrates and describes the monitoring function of user access operation behavior. This contract forms an access record based on the user's access request. The complete access record includes T, BPK DU ,u,m and other information, and are recorded in the access log list. If the access user's operation authority exceeds the limit range in the user list, or the current access time has expired, the user is marked as a violating user, and a violation record is generated based on the user's access request. The violation record at this time includes T, BPK DU , u and other information, violation records are written into the violation list and can be used as one of the strong evidences for subsequent accountability.

[0152]

[0153]

[0154] System security

[0155] Medical data contains a lot of sensitive information, which will cause huge negative impacts once leaked. The medical data sharing system proposed in the present invention can ensure the security of data in all links of the data life cycle, including data encryption, data storage, data sharing, and data access.

[0156] (1) Data encryption: Different encryption methods are used according to the sensitivity of the data. High and medium sensitivity data are attribute encrypted based on AES encryption. The key generation method is completed jointly by the attribute authorization center and the user, realizing collaborative key generation. There will be no key generation errors caused by unilateral errors, which will in turn cause the key ciphertext to be threatened.

[0157] (2) Data storage: Compared with local storage, data stored in IPFS solves the problem of hardware errors that may occur in local storage, which can lead to data leakage and corruption. In addition, some data stored in IPFS is symmetrically encrypted. Even if medical data is exposed after IPFS is attacked by external forces, the attacker can obtain low-sensitivity information, but cannot obtain any information from high- and medium-sensitivity ciphertexts. Low-sensitivity information usually does not affect patients.

[0158] (3) Data sharing: The medical data sharing method proposed in the present invention is a combination of on-chain and off-chain. On the chain, the validity and timeliness of the Proof are verified by the P-TL smart contract. The only data related to the ciphertext is the symmetric key, ciphertext address and policy hiding vector. Even if it is stolen, it is difficult for the thief to meet the access policy. Off-chain, after obtaining the ciphertext address, DU obtains the ciphertext from IPFS and performs secondary decryption to obtain the plaintext. The decryption process is completed in DU and does not involve other entities. It will not cause information leakage. Therefore, the data sharing method is safe.

[0159] Data access: Medical data is subject to hierarchical access control through the proposed MSC-CP-ABE algorithm. On the chain, it does not involve data access. Off-chain, ciphertext is obtained by accessing IPFS, which can completely resist illegal attacks.

[0160] In summary, the security of the system has been verified, and data security can be guaranteed in all stages including data encryption, data storage, data sharing, and data access.

[0161] Security of MSC-CP-ABE algorithm

[0162] The AES symmetric encryption algorithm is a symmetric encryption standard adopted by the U.S. federal government, and its security is widely recognized. The MSC-CP-ABE algorithm proposed in the present invention is implemented based on the CP-ABE algorithm and combined with the AES symmetric encryption algorithm to achieve hierarchical encryption of data of different sensitivities. The algorithm security is not less than that of the CP-ABE algorithm and the AES symmetric encryption algorithm, and the proof is given below.

[0163] The CP-ABE algorithm is secure, and the AES symmetric encryption algorithm is secure.

[0164] The security of the MSC-CP-ABE algorithm proposed in the present invention is no less than that of the CP-ABE algorithm and the AES symmetric encryption algorithm.

[0165] Proof: Compare with CP-ABE algorithm.

[0166] Setup: The public keys PK of MSC-CP-ABE and CP-ABE are consistent; the master key MSK is kept by the attribute authorization center, and security is not reduced.

[0167] Enc: The subject of MSC-CP-ABE attribute encryption is AES symmetric key and low-sensitivity data, high-sensitivity data and medium-sensitivity data are encrypted by AES symmetric key, and the subject encrypted by CP-ABE algorithm is plain text. High , m Medium Attribute encryption process, m High , m Medium and plaintext M Low This is consistent with the encryption process of CP-ABE under the access structure δ. In addition, in order to achieve policy hiding, the access policy is vectorized to represent Embedded in the ciphertext, the Enc algorithm is more secure.

[0168] KenGen: The generation process of the key SK1 of MSC-CP-ABE is consistent with that of CP-ABE, D = g (β+r) / γ Generated by the attribute authorization center and the user, due to the difficulty of solving discrete logarithms, the user cannot obtain the known h = g γ , D′=g x·(β+r) / γ , K = g x The master key g is calculated from β ,γ, so the generation process of D will not expose the master key and will not reduce the security of the system.

[0169] Dec: Compared with the CP-ABE algorithm, users first perform attribute matching. That is, if the attribute set S satisfies the access policy δ, then the MSC-CP-ABE attribute decryption obtains the AES symmetric key, and the high-sensitivity and low-sensitivity plaintexts are decrypted by the AES symmetric key, while the CP-ABE algorithm directly decrypts the attribute to obtain the plaintext. AES symmetric key m High , m Medium and plaintext M Low The attribute decryption process is consistent with CP-ABE.

[0170] In summary, the security of the four steps of the MSC-CP-ABE algorithm is no less than that of the CP-ABE algorithm. By replacing the plaintext of the encryption (decryption) part with the AES symmetric key, the security of MSC-CP-ABE is no less than that of the AES symmetric encryption algorithm. By vectorizing the access policy, the MSC-CP-ABE access policy is hidden, and the security is further improved.

[0171] If a user only meets the access policy for low-sensitivity data, he or she will not be able to access medium-sensitivity data or high-sensitivity data.

[0172] Proof: The user meets the access policy for low-sensitivity data and can recursively access the left child x of the left child of the root node. Low get Since the user does not meet the access policy for sensitive data, it is not possible to recurse to the left child x of the root node. Medium get And it does not comply with the access policy for highly sensitive data, so it is impossible to recurse to the root node to obtain x High get In addition, the polynomial values ​​of the generated left and right child nodes are unrelated, and users cannot Low =q Low (0) Infer s Medium =q Medium (0) and s High =q High (0), that is, it is impossible to Inferred and

[0173] The above descriptions are only some specific implementation methods of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by any person familiar with the art within the technical scope disclosed in the present invention should be covered within the protection scope of the present invention.

Claims

1. A medical data hierarchical access control and sharing method that collaborates on-chain and off-chain, characterized by It includes the following five functional modules: ① Attribute Authorities, AA: responsible for managing user attributes and generating user attribute keys; ②Data Owner, DO: is the publisher of the data; uses the access control algorithm MSC-CP-ABE based on the main side chain and hierarchical attribute encryption to implement the AES encryption algorithm for medical data, hierarchically encrypts and uploads the ciphertext of the file to the interplanetary file system IPFS, and formulates access control policies for the data. In order to improve system efficiency, DO stores transactions Tb sto Send the storage ciphertext address and symmetric decryption key to the side chain; ③ Data User, DU: First, get the ciphertext address and symmetric key from the side chain, then get the ciphertext from the interstellar file system IPFS, and decrypt the ciphertext indexed by the address; DU matches the attribute set with the hiding strategy locally and encrypts it using the RSA encryption algorithm cryptographic system; if the match is successful, it generates an access certificate without privacy leakage, and then broadcasts it to other nodes in the data chain for consensus verification; the matching and verification process is completed by the P-TL contract. After the verification is passed, DO generates an access storage transaction Tb sto The data chain is used for consensus verification; once authorization is obtained, when the attribute set of DU meets the access policy and the access time period, the address where the ciphertext is stored in the Interstellar File System IPFS is obtained, and then the key can be obtained from DO to decrypt the ciphertext indexed by the address and obtain the data; In addition, the malicious DU obtains the key by forging a proof, but cannot decrypt the ciphertext because its attribute set or access time period does not meet the access policy set by the DO; ④ Interstellar File System IPFS: stores all encrypted data of DO and realizes distributed storage of ciphertext data. Reduce blockchain storage overhead and facilitate DO storage and DU access; ⑤Master side blockchain, MSC: It consists of the main chain and the side chain. The main chain is mainly used to index the side chain. The side chain is mainly used to set up the P-TL contract to verify the proof and save the index address and symmetric key of the ciphertext with different sensitivities of high, medium and low, verify the access rights and obtain the address information of resource storage, complete the verification on the chain, and perform storage transactions Tb sto and access transaction Tb acc Verification and communication, allowing DU to obtain the ciphertext address and symmetric key; The AC-CSS workflow of the on-chain and off-chain collaborative medical data hierarchical access control and sharing method is divided into four stages, including the initialization stage, the ciphertext storage stage, the on-chain stage, and the access stage: Initialization phase: DO and DU submit registration requests and submit relevant attributes and content to the attribute authorization center AA. After receiving the request, the attribute authorization center AA sends the keys PK, MSK, and BSK to the DO and DU. DO , BPK DO Return to DO, key PK, BSK Du , BPK Du Return to DU and initialize the parameters in the system; Among them, PK is the public key, MSK is the master key, and BSK is the DO and BPK DO The private key and public key registered by DO in AA, BSK Du , BPK Du It is the private key and public key registered by DU in AA; Ciphertext storage stage: In this stage, DO first generates an access policy based on a set of attributes, and stores the ciphertext in IPFS through the MSC-CP-ABE algorithm. Then IPFS returns the storage address u to DO. At this point, the data is securely stored. On-chain stage: DO generates a storage transaction Tb by storing the ciphertext address and symmetric decryption key with the hidden strategy. sto Sent to the main side chain MSC; any DU that wants to access the data owned by DO must locally set the hidden access policy With a set of attributes If the match is successful, DU will use the RSA cryptographic system to generate Proof, submit it to the MSC main chain, and broadcast it to other nodes on the MSC side chain, thereby triggering the P-TL smart contract deployed in each node in the MSC side chain to verify the Proof and timeliness; If an agreement is reached, DO will generate a key and send an access transaction Tb to MSC. acc , where access transaction Tb acc Used to record the access control history of DO, which is convenient for tracking, tracing and accountability; in, is the vector generated by the access policy; is the vector generated by the attribute set; Access phase: If the consensus process for access transactions is reached, DU will obtain the user's private key The key is stored locally in the DO and cannot be accessed by the MSC. It will be automatically distributed through secure communication channels without any human intervention; the DU obtains the ciphertext address, symmetric decryption key and user private key After that, the ciphertext will be obtained according to the ciphertext storage address, and then the symmetric decryption key and the user's private key will be used Decryption is performed to obtain medical data.

2. The medical data hierarchical access control and sharing method for on-chain and off-chain collaboration according to claim 1 is characterized by: The MSC-CP-ABE access control algorithm includes four stages: initialization stage, encryption storage stage, chain stage and decryption stage.

3. The medical data hierarchical access control and sharing method for on-chain and off-chain collaboration according to claim 1 is characterized by: In the Master side blockchain, MSC module, the main chain and the side chain are a one-main-three-side structure, where the blocks on the main chain store the basic information of the side chain, and disclose information that does not involve privacy. The main chain stores the basic information of the low-sensitivity information chain, the medium-sensitivity information chain and the high-sensitivity information chain, including the side chain location and the side chain name; each side chain stores the address and symmetric key corresponding to the information of different sensitivity. The P-TL contract is deployed on the three side chains. When the Proof of the DU is transmitted to the side chain by broadcasting through the node on the main chain, the Proof will automatically serve as the input condition of the contract, automatically execute the contract rules, and verify whether the DU has the authority to access the target resources.

4. The medical data hierarchical access control and sharing method for on-chain and off-chain collaboration according to claim 1 is characterized by: The data users (DU) are medical staff, research institutions and insurance companies.

5. The medical data hierarchical access control and sharing method for on-chain and off-chain collaboration according to claim 1 is characterized by: The hierarchical encryption is to perform symmetric encryption on medium and high sensitivity data, and then perform attribute encryption, while for low sensitivity data, attribute encryption is performed directly.

Images