A method for secure sharing of intelligent medical data based on national cryptographic algorithms

Abstract

This invention discloses a secure sharing method for intelligent medical data based on national cryptographic algorithms, comprising the following steps: The medical record query terminal generates a query trapdoor and a query vector based on the queryer's private key, medical record query keywords, and system public parameters, and sends the query trapdoor and query vector to the blockchain; the blockchain obtains multiple corresponding symmetric encrypted ciphertexts of medical records from a fog server based on the medical record index and the query trapdoor; the blockchain verifies the multiple symmetric encrypted ciphertexts of medical records based on the queryer's private key and public key; if the verification is successful, the blockchain sends multiple symmetric encrypted ciphertexts of medical records that meet the conditions and the corresponding symmetric key ciphertexts to the medical record query terminal; the medical record query terminal decrypts the multiple symmetric encrypted ciphertexts of medical records that meet the conditions based on the queryer's private key to obtain a decrypted file. This invention improves computational efficiency and prevents the leakage of user privacy information.

Description

Technical Field

[0001] This invention belongs to the field of communication technology, specifically relating to a method for secure sharing of intelligent medical data based on national cryptographic algorithms. Background Technology

[0002] The rapid development of cloud computing, big data, and artificial intelligence has spawned numerous application service industries, such as scientific research, social production, education, consumer goods, and entertainment, stimulating the potential for digital economic cooperation in these industries and accelerating digital transformation for all parties. However, in these industry applications, since most user data storage and processing are performed on remote cloud servers, ensuring the security and integrity of user data has become a serious challenge in the process of digital transformation.

[0003] Smart healthcare, as a typical application scenario in the development of digital transformation, presents numerous security challenges, including data leakage and loss, due to the computation and storage of sensitive user data on untrusted cloud servers. To address these issues, scholars both domestically and internationally have employed a range of novel cryptographic techniques. Privacy breaches in medical data can harm the interests of both users and primary data owners; therefore, ensuring fair and accurate searching of shared data and protecting the privacy of medical data is crucial in healthcare sharing systems. However, most current blockchain-based cryptographic schemes fail to address challenges such as high communication costs, low efficiency, and the vulnerability of user privacy information to leakage. Summary of the Invention

[0004] To address the aforementioned problems in existing technologies, this invention provides a method for secure sharing of intelligent medical data based on national cryptographic algorithms. The technical problem to be solved by this invention is achieved through the following technical solution:

[0005] A method for secure sharing of intelligent medical data based on national cryptographic algorithms includes the following steps:

[0006] The medical record query terminal generates a query trapdoor and a query vector based on the queryer's private key, medical record query keywords, and system public parameters, and sends the query trapdoor and the query vector to the blockchain;

[0007] The blockchain retrieves multiple corresponding symmetric encrypted ciphertexts of medical records from the fog server based on the medical record index and the query trapdoor.

[0008] The blockchain verifies the multiple symmetric encrypted ciphertexts of medical records based on the queryer's private key and public key. If the verification is successful, it sends multiple symmetric encrypted ciphertexts of medical records that meet the conditions and the corresponding symmetric key ciphertexts to the medical record query terminal.

[0009] The medical record query terminal decrypts the symmetric encrypted ciphertext of multiple medical records that meet the conditions based on the queryer's private key, and obtains the decrypted file.

[0010] In one embodiment of the present invention, the method further includes:

[0011] The attribute authority outputs system public parameters and the master key based on security parameters and the attribute set of registered doctor users;

[0012] The attribute authority determines the queryer's private key and the public and private keys of the medical record management terminal based on the system's public parameters, the master key, the queryer's identity identifier, and the queryer's registered doctor user attribute set. The authority then sends the queryer's private key to the medical record query terminal and the public and private keys to the medical record management terminal.

[0013] The medical record management terminal generates a symmetric key ciphertext, a medical record index, and an index vector corresponding to the medical record index based on the system public parameters, index key, preset access structure, medical record file set, medical record keyword set, and symmetric encryption algorithm, and sends the medical record index and the index vector to the blockchain.

[0014] In one embodiment of the present invention, the attribute authority determines the queryer's private key and the public and private keys of the medical record management terminal based on the system public parameters, the master key, the queryer's identity identifier, and the queryer's registered doctor user attribute set, and sends the queryer's private key to the medical record query terminal and the public and private keys to the medical record management terminal, including:

[0015] The attribute authority determines the retrieval key and the public and private keys of the medical record management terminal based on the system's public parameters, the master key, the queryer's identity identifier, and the queryer's registered doctor user attribute set.

[0016] The attribute authority obtains the index key from the medical record management terminal;

[0017] The attribute authority sends the retrieval key and the index key as the queryer's private key to the medical record query terminal, and sends the public key and the private key to the medical record management terminal.

[0018] In one embodiment of the present invention, the medical record management terminal generates symmetric key ciphertext, a medical record index, and an index vector corresponding to the medical record index based on the system public parameters, index key, preset access structure, medical record file set, medical record keyword set, and symmetric encryption algorithm, and sends the medical record index and the index vector to the blockchain, including:

[0019] The medical record management terminal performs key information protection on the preset access structure to obtain a preset protected access structure, and sends the attribute protection information of the preset protected access structure to the blockchain.

[0020] The medical record management terminal encrypts each medical record file in the medical record file set using a symmetric encryption algorithm to obtain the corresponding symmetric encryption ciphertext and symmetric key for each medical record, and then sends the symmetric encryption ciphertext of the medical record to the fog server;

[0021] The medical record management terminal uses the symmetric key and the random number r. i The binary random vector of the index key, the preset protection access structure, and the system public parameters are used to generate symmetric key ciphertext on the blockchain;

[0022] The medical record management terminal calculates the signature of each medical record file based on the identity of the medical record manager and the system's public parameters;

[0023] The medical record management terminal determines the first index parameter, the second index parameter, and the third index parameter based on the random number of keywords in the medical record keyword set and the system common parameters;

[0024] The medical record management terminal determines the fourth index parameter based on the keyword and the medical record file;

[0025] The medical record management terminal determines the medical record index based on the first index parameter, the second index parameter, the third index parameter, and the fourth index parameter;

[0026] The medical record management terminal determines the index vector corresponding to the medical record index based on the medical record file and the index key;

[0027] The medical record management terminal sends the medical record index and the index vector to the blockchain.

[0028] In one embodiment of the present invention, the medical record query terminal generates a query trapdoor and a query vector based on the queryer's private key, medical record query keywords, and system public parameters, and sends the query trapdoor and the query vector to the blockchain, including:

[0029] The medical record query terminal generates a query trap based on the medical record query keywords and the system's public parameters;

[0030] The medical record query terminal generates a query vector based on the index key in the queryer's private key;

[0031] The medical record query terminal sends the query trap and the query vector to the blockchain.

[0032] In one embodiment of the present invention, the blockchain obtains multiple corresponding symmetric encrypted ciphertexts of medical records from the fog server based on the medical record index and the query trapdoor, including:

[0033] The blockchain determines whether the medical record index and the query trapdoor match;

[0034] If a match is found, the blockchain sends the medical record file identifier corresponding to the medical record index to the fog server;

[0035] The fog server searches for the corresponding symmetric encrypted ciphertext of the medical record based on the medical record file identifier, and sends the found multiple symmetric encrypted ciphertexts of the medical records to the blockchain.

[0036] In one embodiment of the present invention, the blockchain verifies the plurality of symmetric encrypted ciphertexts of medical records based on the queryer's private key and the public key. If the verification is successful, the blockchain sends the plurality of symmetric encrypted ciphertexts of medical records that meet the conditions to the medical record query terminal, including:

[0037] The blockchain calculates the first parameter to be verified based on the queryer's private key;

[0038] If the first parameter to be verified matches the attribute protection information, the blockchain generates a digital certificate for each medical record symmetric encrypted ciphertext based on the identity of the medical record manager, and sends the digital certificate and the signature of the corresponding medical record file to the fog server.

[0039] The fog server calculates the parameter pair to be verified based on the digital certificate and the signature of the medical record file, and sends the parameter pair to the blockchain;

[0040] The blockchain verifies each medical record's symmetric encrypted ciphertext based on the parameters to be verified and the public key;

[0041] If the verification is successful, multiple symmetric encrypted ciphertexts of medical records that meet the conditions and the corresponding symmetric key ciphertexts are sent to the medical record query terminal.

[0042] In one embodiment of the present invention, the medical record query terminal decrypts the multiple symmetric encrypted ciphertexts of medical records that meet the conditions based on the queryer's private key to obtain a decrypted file, including:

[0043] The medical record query terminal calculates the transformation key based on the queryer's private key;

[0044] The medical record query terminal sends the transformation key and the corresponding symmetric key ciphertext to the fog server assistant terminal;

[0045] The fog server assistant calculates the intermediate ciphertext based on the transformation key and the corresponding symmetric key ciphertext.

[0046] The fog server assistant sends the intermediate encrypted text to the medical record query terminal;

[0047] The medical record query terminal calculates the symmetric key based on the intermediate ciphertext;

[0048] The medical record query terminal uses a symmetric decryption algorithm to decrypt the symmetric encrypted ciphertext of multiple medical records that meet the conditions, and obtains a decrypted file.

[0049] In one embodiment of the present invention, the system common parameters and the master key are represented as follows:

[0050]

[0051] Where PP represents the system common parameters, MSK represents the master key, and V i =v i G and H represent one-way mapping hash functions, where G represents... The generators are A1 = αG and A2 = e(A1,G).

[0052] In one embodiment of the present invention, the expression of the retrieval key is:

[0053]

[0054] Where uid represents the identity identifier of the queryer, S uid This represents the set of registered doctor user attributes of the queryer.

[0055] The beneficial effects of this invention are:

[0056] This invention targets massive, multimodal data and uses blockchain to store encrypted keyword indexes and related data. This allows data users to perform rapid searches using smart contracts, and search results are only released to the user after verification by the smart contract. This avoids erroneous results returned by the cloud, improves computational efficiency, and minimizes the risk of user privacy leaks.

[0057] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0058] Figure 1 A schematic diagram of a system model framework for a method for secure sharing of intelligent medical data based on national cryptographic algorithms, provided in an embodiment of the present invention;

[0059] Figure 2 This is a comparison chart of encryption time for the present invention and existing technologies under different numbers of attributes during the encryption stage;

[0060] Figure 3This is a comparison chart of the computational costs of the inventive method and existing technologies with 100 keywords in the IdxGen and TrapGen stages;

[0061] Figure 4 This is a comparison chart of the computational costs of the inventive method and existing technologies with 300 keywords in the IdxGen and TrapGen stages;

[0062] Figure 5 This is a comparison chart of the computational costs of the inventive method and existing technologies with 500 keywords in the IdxGen and TrapGen stages;

[0063] Figure 6 This diagram illustrates the relationship between the storage cost and the number of attributes of the user's private key, the relationship between the trapdoor size and the number of attributes, the relationship between the ciphertext size and the number of attributes, and the relationship between the storage cost and the number of attributes of the index in the method of this invention and existing technologies.

[0064] Figure 7 This is a schematic diagram of the security game interaction during the security verification process of a smart medical data security sharing method based on national cryptographic algorithms provided in an embodiment of the present invention. Detailed Implementation

[0065] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.

[0066] First, the basic knowledge required for this application is introduced, including: bilinear mapping, access structure, linear secret sharing, vector space model, elliptic curves, and smart contracts.

[0067] Table 1 shows the relevant symbols and their meanings:

[0068]

[0069] Table 1

[0070] 1.1 Bilinear Mapping

[0071] Attribute-based encryption is a one-to-many encryption technique that builds upon identity-based encryption schemes. Let's first examine the mathematical foundations and related cryptographic knowledge involved in attribute encryption.

[0072] Let p be a large prime number. and They are two multiplicative groups of order p, and g is a group. The generator of bilinear mappings. It satisfies the following properties:

[0073] Bilinear: arbitrary a,b∈Z pThe following equations hold true:

[0074] e(g a ,g b )=e(g b ,g a )=e(g,g) ab (1.1)

[0075] Non-degeneracy; existence It satisfies e(g,g)≠1.

[0076] Computability: for any It can be used for efficient calculations.

[0077] 1.2 Access Structure

[0078] Given an access structure W and a set of t entities, and Ω = {P1, P2, ..., P...} t If for any U, V, when U∈W and If V∈W holds true, then W is monotonic. If W is Ω={P1,P2,...,P...} t A non-empty subset of}, which means Given a set a, if any element of a is in W, then a is called an authorized set; otherwise, it is called an unauthorized set.

[0079] 1.3 Linear Secret Sharing

[0080] Given a set of Ω, the following conclusions are drawn regarding linear secret-sharing schemes:

[0081] 1. Each part of the secret value s in Z p The vector is formed on top.

[0082] 2. There exists a monotonic access structure (M, ρ), where M is called a shared matrix with l rows and n columns, ρ is the entity Ω that maps the i-th row of the matrix to the set, and then we randomly choose a vector. Where s is the secret value, s i It is a random number. Based on the secret value s of the access structure ∧, λ i It is one of the l shared values, and λ i ∈ρ(i), where M i Let M represent the i-th row.

[0083] Linear Reconstruction: Suppose (M,ρ) is the access structure ∧ of a linear secret-sharing scheme, and S∈(M,ρ) is the authorization set. Definition If {λ i If} are the effective shared values ​​of s, then there exists a set of constants w. i ∈Z p Make

[0084] 1.4 Vector Space Model

[0085] The vector space model is a mathematical model for information retrieval that supports both join-based and join-free search. Documents are ranked by calculating the values ​​of the index vector and the query vector, i.e., the relevance score. The index vector is a normalized TF value, and the query vector is a standardized IDF value. TF represents a specific keyword in a document, and IDF is the number of documents in the set divided by the number of documents containing that keyword. A similarity evaluation function is typically used to implement the ranking function. The following example illustrates how to calculate the relevance score.

[0086] Suppose there exists a set of files F = {f1,...,f...} n The keyword list extracted from it is WL = {w1,...,w}. m}, where m and n represent the number of keywords and files, respectively, given a set of query keywords. And it is stipulated that f l,τ This is represented as containing the keyword w. τ file f l |Fτ| indicates that the specified keyword w is present. τ Number of files; TF l,τ f l,τ The number of specific keywords in a string, i.e., the value of TF; IDF q,τ The IDF value represents the number of documents in the collection divided by the number of documents containing the keyword; W l TF l,τ European length; W q Indicates IDF l,τ Given the Euclidean length, the correlation score is calculated as follows:

[0087]

[0088] in

[0089] 1.5 Elliptic Curve

[0090] Let F q It is a q-element finite field, denoted as It is F q The algebraic closure of has the following cubic homogeneous equation:

[0091] Y 2 Z+a1XYZ+a3YZ 2 =X 3 +a2X 2 Z+a4XZ 2 +a6Z3 (1.3)

[0092] It is called the projective Weierstrass equation, where a i ∈F q .make

[0093] Ψ(X,Y,Z)=Y 2 Z+a1XYZ+a3YZ 2 -(X 3 +a2X 2 Z+a4XZ 2 +a6Z 3 (1.4)

[0094] If the system of equations

[0095]

[0096] In the domain If there is no solution above, then the projective Weierstrass equation is nonsingular; otherwise, it is singular. Let F... q It is a finite field, denoted as It is F q The algebraic closure of the projective Weierstrass equations in the projective plane A curve defined on the affine plane is called a non-singular or smooth projective elliptic curve if the Weierstrass equation has no solution; if Z = 0, the projective elliptic curve has only one point (0, 1, 0), which is called the point at infinity. Dehomogenizing equation (1) yields the affine Weierstrass equation on the affine plane:

[0097] Thus, the affine Weierstrass equation (4) defines a curve on the affine plane, called an affine elliptic curve. The addition operation "+" on the elliptic curve E has the following properties:

[0098] 1) To All have N+M=M+N∈E;

[0099] 2) To Both have N + O = N;

[0100] 3) To There must exist a point -N such that N + (-N) = 0 holds true for all cases.

[0101] 4) If line l intersects E at points N, M, and K, then N + M + K = 0;

[0102] 5) To Both (M+N)+K=M+(N+K).

[0103] Based on the above properties, all points on the elliptic curve E plus a special point O form an additive commutative group (Abel group), denoted as (E,+), where O is the identity element.

[0104] 1.6 Smart Contracts

[0105] A smart contract is a computer protocol that, once established, executes and verifies itself without human intervention. From a technical perspective, a smart contract is similar to a computer program; it can automatically execute all or part of the rules stipulated in the contract and generate corresponding certificates to prove the contract's operation. Before deploying a smart contract, all rules and execution steps related to the contract have already been established.

[0106] In the solution of this invention, for massive amounts of multimodal data, we use blockchain to store encrypted keyword indexes and related data. This allows data users to perform fast searches using search smart contracts, and search results are only provided to data users after being verified by the smart contract, thus avoiding erroneous results returned by the cloud.

[0107] Example 1

[0108] like Figure 1 As shown, the system constructed in this invention comprises six entities:

[0109] Attribute Authority (AA): The AA is a trusted authority responsible for system initialization, including the generation of system parameters and master key, as well as the generation of private key based on the attribute set provided by the user.

[0110] Fog Server Provider (FSP): FSPs have strong storage capabilities, are responsible for storing ciphertext, and send the corresponding ciphertext file to the blockchain's verification smart contract when they receive a file identifier.

[0111] Blockchain (BC): The Medical Record Management (DO) module uploads the encrypted index to the blockchain. Once the Medical Record Query (DU) module submits a query trap, the Search Smart Contract (SSC) determines whether the query trap matches the secure index and sends the file identifier to the FSP. Furthermore, the Verification Smart Contract (VSC) judges the correctness of the results returned by the trap and calculates the score for the corresponding file. Finally, the top-k most matching files are sent to the user.

[0112] Decryption Fog Server Assistant (D-FSA): D-FSA has powerful computing capabilities and uses user-generated conversion keys to perform initial decryption of ciphertext.

[0113] The Medical Record Controller (DO): Similar to the patient's end, this entity owns and manages electronic medical records. They choose a symmetric encryption algorithm to encrypt the files and then use the ABE algorithm to encrypt the symmetric key. Furthermore, the DO uploads a keyword index of the files to the blockchain for storage, thereby providing search services for the Medical Record Controller (DU).

[0114] Medical Record Query Terminal (DU): In this scheme, this refers to the doctor's terminal. When a doctor's attribute set meets the access policy, they can obtain the required encrypted data from the fog terminal. Each DU has a unique set of attributes and an associated private key.

[0115] The formal model of this invention includes the following seven basic algorithms:

[0116] (1) Setup(1 k ,L)→(PP,MSK): Input security parameter 1 k The attribute system L and AA execute the Setup algorithm and output the system public parameters PP and the master key MSK.

[0117] (2) KeyGen(MSK,uid,S) uid → (SK): Input the master key MSK, the user's identifier uid, and the attribute set S. uid AA runs the KeyGen algorithm to obtain the user's private key.

[0118] (3) Encrypt(ssk,(A,ρ),F,PP)→(CT): Input system public parameters PP, symmetric key ssk, access structure (A,ρ), and data file F={f1,...,F l}, where l represents the number of files, and DO executes an encryption algorithm to generate ciphertext CT.

[0119] (4) IdxGen:(WL,PP)→(I): Input keyword list WL={w1,...,w m}, DO extracts keywords from the file set F and the system public, and the IdxGen algorithm outputs the ciphertext index I.

[0120] (5)TrapGen(KW,PP)→(T): Input the system public parameter PP and the query keyword KW, and DU executes the TrapGen algorithm to generate the search trapdoor T.

[0121] (6) Search(I,T)→(√ / ⊥): Input the ciphertext index I and the search trapdoor T, then SSC executes the search algorithm. If the index and trapdoor match successfully, SSC will send the file identifier to the fog server FSP; otherwise, it outputs ⊥.

[0122] (7) Verigy(sig lC l ,PP,pk0): VSC executes the verification algorithm to check if the result returned by FSP is correct. Then it returns the top-ranked k encrypted files to DU.

[0123] (8) Transform(RK)→(tkp,tsk): Input the retrieval key RK, and DU executes this transformation algorithm to generate the transformed key pair (tpk,tsk), where tpk (the transformed public key) is sent to D-FSA and tsk (the transformed key) is kept by itself.

[0124] (9)Decryptout(tpk,CT)→(MC): Input the DU's public key tpk and ciphertext, and D-FSA runs this algorithm to generate the intermediate ciphertext MC.

[0125] (10)Decrypt(tsk,IC)→(F δ ): DU inputs the conversion key tsk and intermediate ciphertext MC, decrypts to obtain the file of interest F. δ .

[0126] Privacy breaches in medical data can harm the interests of both users and primary data owners. Therefore, ensuring fair and accurate searching of shared data and protecting the privacy of medical data becomes extremely important in healthcare sharing systems. For data owners, i.e., patients, they do not want their medical data to be leaked, yet they also want it to be transmitted to designated doctors. Therefore, the following key issues regarding data owners in healthcare need to be addressed.

[0127] Preventing data leaks: A secure transmission channel is needed to prevent data from being stolen during transmission.

[0128] Secure access control: Access policies need to be set up on the basis of secure transmission, so that only doctors with the required permissions can access the transmitted content, thus enabling patients to have control over their data.

[0129] Data security, efficiency, and searchability: For data users, i.e. doctors, there is a need to quickly retrieve data from the fog that meets the query criteria in order to improve the efficiency of secure sharing and use of electronic medical data.

[0130] According to our proposed security framework, the CA is a fully trusted entity, and transactions on the blockchain are public, transparent, and secure. The ultimate goal of this scheme is to achieve security under chosen-plaintext attacks. In a chosen-plaintext attack, the attacker has access to the cryptographic machine and can construct ciphertext corresponding to any plaintext. During a chosen-plaintext attack, the cryptanalyst has the ability to select or control the plaintext, choosing any plaintext and its corresponding ciphertext that they deem advantageous for the attack. This is a more powerful attack method than known-plaintext attacks. If a cryptographic system can resist chosen-plaintext attacks, it must also be able to resist ciphertext-only attacks and known-plaintext attacks.

[0131] The security model is described through an interactive game between an opponent and a challenger, with the specific game interaction process shown below. If no opponent exists who can win the following matches... Our solution thus achieves selective CPA security.

[0132] Initialization phase: In this phase, the adversary Choose an access policy (A) * ,ρ * And send it to the challenger. Run the Setup algorithm to obtain PP and MSK. Then To the enemy PP announced that it privately owns MSK.

[0133] Inquiry Phase I: In this phase, First, create an empty table B and an empty set J, then... Execute the following query.

[0134] (1) Attribute private key query: adversary (uid,S) uid Use it as input to query the private key. Execute the KeyGen algorithm to obtain the attribute private key SK uid And calculate J = J∪S uid ,Then Private key SK uid Return to

[0135] (2) Key conversion query: Input (uid,S) uid To query the attribute private key. Then Check if (S) exists in table B uid SK uid ,tk), if it exists Return to otherwise Executing the KeyGen and Transform algorithms will convert the project (S) uidSK uid Place tk into B. Finally, send tk to B.

[0136] Challenge Phase: Select two messages of the same length, m0 and m1, and then hand them over to... Randomly select x∈{0,1} and based on (A * ,ρ * ) for m χ Encryption is performed to obtain the challenge ciphertext CT. χ ,Then CT b Send to

[0137] Inquiry Phase II: In this phase, A process similar to Phase I can be performed, but The attribute set used for private key lookup cannot satisfy (A) * ,ρ * ).

[0138] Speculation phase: Give your own guess b′∈{0,1}, Winning a match is possible if and only if b = b'. Calculate the opponent's... The advantages of winning the game are as follows:

[0139]

[0140] The method of the present invention will now be described in detail:

[0141] A method for secure sharing of intelligent medical data based on national cryptographic algorithms includes the following steps:

[0142] Step 10, System Initialization Algorithm (Setup): The attribute authority (AA) outputs system public parameters and the master key based on security parameters and the registered doctor user attribute set. In this step, the attribute authority (AA) outputs system public parameters and the master key based on security parameter 1. k Two p-order cyclic groups and Bilinear mapping Registered doctor user attribute set L and random number v i The system outputs public parameters and the master key. The registered doctor user attribute set contains the personal information of all registered doctor users, and the queryer is a subset of the registered doctor users.

[0143] Specifically, this process includes steps 11-14:

[0144] Step 11, AA selects two p-order cyclic groups. and Where p is a prime number, and G is... The generator.

[0145] Step 12, AA defines a bilinear mapping. And choose α, α1, a∈Z p .

[0146] Step 13, for i∈L, AA randomly selects a number v. i ∈Z p And calculate V i =v i G.

[0147] Step 14, output system parameters and master key:

[0148]

[0149] Where PP represents the system common parameters, MSK represents the master key, H represents the one-way mapping hash function, and A1 = aG and A2 = e(G,G) are defined. α .

[0150] Step 20, Private Key Generation Algorithm (KeyGen): The attribute authority determines the queryer's private key and the public and private keys of the medical record management terminal based on the system's public parameters, master key, queryer's identity identifier, and the queryer's registered doctor user attribute set. The queryer's private key is sent to the medical record query terminal, and the public and private keys are sent to the medical record management terminal. This step includes steps 21-23:

[0151] Step 21: The attribute authority determines the retrieval key and the public and private keys of the medical record management terminal based on the system public parameters, master key, querier identity identifier, and the querier's registered doctor user attribute set.

[0152] Specifically, AA randomly selects t∈Z p The retrieval key RK is calculated as follows:

[0153] Where A3 = αG, uid represents the identity identifier of the querier, and S uid This represents the set of registered doctor user attributes for the querier, and is a subset of the set of registered doctor user attributes L.

[0154] AA selects a random number r′∈Z p And calculate the public key pk0 and private key sk0 of the medical record management terminal as (pk0,sk0)=(R′,r′), where R′=r′G.

[0155] Step 22: The attribute authority obtains the index key from the medical record management system. Specifically, the medical record management system randomly selects two invertible matrices M1, M2 ∈ R.dxd And a d-dimensional binary random vector s, where R is a matrix group, and two invertible matrices M1, M2 and the binary random vector s are used as the index key IK. AA can obtain the index key IK from the medical record management terminal.

[0156] Step 23: The attribute authority sends the retrieval key and index key as the queryer's private key SK = {RK, IK} to the medical record query terminal, and sends the public key and private key (pk0, sk0) to the medical record management terminal. The transmission process in this step is conducted through a secure channel. The public key of the medical record management terminal is stored on the blockchain when the medical record management terminal accesses the blockchain.

[0157] Step 30, Encryption Algorithm: The medical record management terminal generates symmetric key ciphertext, medical record index, and corresponding index vector based on system public parameters, index key, preset access structure, medical record file set, medical record keyword set, and symmetric encryption algorithm. It then sends the medical record index and index vector to the blockchain. The preset access structure (A, ρ) represents the access restrictions pre-set by the medical record administrator, with each restriction acting as an attribute. A is called a shared matrix with l rows and n columns, ρ is the entity that maps the i-th row of the matrix to the set, ρ(i) represents the i-th row of the matrix, and λ... i It is one of the l shared values, and λ i ∈ρ(i). The medical record file set is a plaintext file set F = {f1,...,f...} n The medical record keyword set is WL. This step includes steps 31-39:

[0158] Step 31: The medical record management terminal performs critical information protection on the preset access structure to obtain a preset protected access structure, and sends the attribute protection information of the preset protected access structure to the blockchain. Specifically, the medical record management terminal selects a random value χ∈Z. p By calculating q i =e(H(attr) i (A4) to replace each attribute information attr in the preset access structure. i This protects critical information in the access policy. Where A4 = α1χG, q i This indicates the attribute protection information after the replacement.

[0159] Step 32: The medical record management terminal encrypts each medical record file in the medical record file set using a symmetric encryption algorithm, obtaining the corresponding symmetric encryption ciphertext and symmetric key for each medical record. Specifically, the medical record management terminal selects the symmetric encryption algorithm Enc(f l The ssk method encrypts each medical record file fl (1≤l≤n) to obtain the symmetric encrypted ciphertext C of the medical record. lWhere ssk represents the symmetric key, the medical record management terminal then symmetrically encrypts the medical record into ciphertext C. l Send to the fog server FSP.

[0160] Step 33, the medical record management terminal uses the symmetric key and random number r to... i The binary random vector of the index key, the preset protection access structure, and the system public parameters are used to generate symmetric key ciphertext on the blockchain.

[0161] Specifically, the medical record management terminal randomly selects a random number r. i ∈Z p Given S = sG, i ∈ {1,...,l}, compute the ciphertext CT (symmetric key ciphertext) of the symmetric key:

[0162] CT={C,C0,C1,C 1,i C 2,i C 3,i};

[0163] Where s represents a binary random vector.

[0164] C=ssk·e(A3,S),C0=χG,C1=S,C 1,i =(r i +λ i G,C 2,i =r i G,C 3,i =v ρ(i) r i G.

[0165] Step 34: The medical record management terminal calculates the signature for each medical record file based on the medical record administrator's identity and system common parameters. The medical record management terminal assigns a signature to each medical record file. l (1≤l≤n) Calculate the signature sig l =(H(id) l ),H(C l )′) r′ , where H(C l )′=H(C l )G, id l This represents the identity of the medical record administrator. In this step, the medical record management system calculates the signature by calling the blockchain.

[0166] Step 35: The medical record management terminal determines the first index parameter, the second index parameter, and the third index parameter based on the random number of keywords in the medical record keyword set and the system common parameters.

[0167] Specifically, the medical record management terminal assigns each keyword w j ∈WL randomly selects two random numbers γ∈Z p,r∈Z p Then calculate I0 = (A1) γ I1 = λ′ and I2 = (C1) r Where I0 represents the first index parameter, I1 represents the second index parameter, I2 represents the third index parameter, and λ′=γG.

[0168] Step 36: The medical record management terminal determines the fourth index parameter based on the keywords and the medical record file. Specifically, the medical record management terminal determines the keyword {w j | j∈[1,t] Is it included in file {f? l | l∈[1,n] If it contains, then the fourth index parameter I lj =sH(w j )G, otherwise I lj =1.

[0169] Step 37: The medical record management terminal determines the medical record index based on the first index parameter, the second index parameter, the third index parameter, and the fourth index parameter. The expression for medical record index I is: I = (I0, I1, I2, {I... lj} l∈[1,n],j∈[1,t] The medical record index I corresponds to a medical record file identifier.

[0170] Step 38: The medical record management terminal determines the index vector corresponding to the medical record index based on the medical record file and the index key.

[0171] Specifically, for medical record files {f l | l∈[1,n] The medical record management system calculates a d-dimensional index vector P based on a random vector s, where each dimension of P is a standardized TF value. Then, the system uses the binary random vector s as a splitting indicator to split P into P′ and P″. The index vector P is represented as...

[0172] When s j When P = 0, j ′ and P j " is represented by two random values, and their sum is P. j When s j When P = 1, j ′=P j "=P j .

[0173] Step 39: The medical record management terminal sends the medical record index I and index vector P to the blockchain.

[0174] Steps 10-30 are pre-processing steps performed by the system and do not require participation in the actual query process. Step 40 begins the specific process of the user querying medical records.

[0175] Step 40, Trapdoor Generation Algorithm (TrapGen): The medical record query client generates a query trapdoor and a query vector based on the queryer's private key, medical record query keywords, and system public parameters, and sends the query trapdoor and query vector to the blockchain. This step currently includes steps 41-43:

[0176] Step 41: Enter the medical record query keywords KW = {w1,...,w} into the medical record query terminal. τ} and system common parameters are used to generate a query trap. The medical record query terminal randomly selects a random number υ∈Z. p And calculate the query trapdoor T = {t1, t2, t3}. The calculation formula is: The medical record search keywords are the collection of elements in the medical record keywords.

[0177] Step 42: The medical record query terminal generates a query vector based on the index key in the queryer's private key. Specifically, the medical record query terminal generates a query vector Q, and splits Q into (Q′, Q″) based on the binary random vector s, setting the query vector Q = (M1... - 1 Q′,M2 -1 Q″).

[0178] If s j =0, then Q j ′=Q j "=Q j If s j =1, then Q j ′ and Q j " represents two random numbers whose sum is Q j .

[0179] Step 43: The medical record query terminal sends the query trapdoor T and query vector Q to the blockchain.

[0180] Step 50, Search Function: The blockchain retrieves the corresponding symmetric encrypted ciphertexts of multiple medical records from the fog server based on the medical record index and query trapdoor. This step includes steps 51-53:

[0181] Step 51: The blockchain determines whether the medical record index and the query trapdoor match.

[0182] Specifically, the blockchain's search smart contract SSC checks whether the following formula holds true to determine whether the medical record index and the query trapdoor match:

[0183]

[0184] Step 52: If a match is found, the blockchain sends the medical record file identifier corresponding to the medical record index to the fog server.

[0185] Step 53: The fog server searches for the corresponding symmetric encrypted ciphertext of the medical record based on the medical record file identifier, and then forwards the found multiple symmetric encrypted ciphertexts C. l Send to the blockchain.

[0186] Step 60, Verification Algorithm: The blockchain verifies multiple symmetric encrypted medical records using the queryer's private and public keys. If verification is successful, it sends the multiple symmetric encrypted medical records that meet the criteria, along with the corresponding symmetric key, to the medical record query client. This step includes steps 61-65:

[0187] Step 61: The blockchain calculates the first parameter to be verified based on the querier's private key. Specifically, the blockchain's verification smart contract VSC is based on the K key of the querier's private key. i，2 Calculate the first parameter to be verified, {q} i ′} i∈Suid =e(C0,K i,2 ).

[0188] Step 62: If the first parameter to be verified matches the attribute protection information, the blockchain generates a digital certificate based on the medical record administrator's identity identifier for each medical record symmetric encrypted ciphertext sent in step 53, and sends the digital certificate and the signature of the corresponding medical record file to the fog server.

[0189] Specifically, VSC detects q i =q i 'Is it valid? If valid (the first parameter to be verified matches the attribute protection information), VSC will use the medical record administrator's identity ID.' l Symmetrically encrypted ciphertext C for medical records l Generate digital certificate ζ l and digital certificate ζ l Symmetric encryption ciphertext C of medical records l The corresponding medical record file signature sig l Send to FSP.

[0190] Step 63: The fog server calculates the parameter pair (l, η) to be verified based on the digital certificate and the signature of the medical record file, and sends the parameter pair (l, η) to the blockchain.

[0191] Specifically, FSP calculates l = ζ l H(C l ) And send (l,η) to VSC.

[0192] Step 64: The blockchain verifies the symmetric encrypted ciphertext of each medical record based on the parameters to be verified and the public key.

[0193] Specifically, VSC via Verify the symmetric encrypted ciphertext C of the medical record l , where L = lG.

[0194] Step 65: If verification fails, VSC will destroy the encrypted CT of the symmetric key and return ⊥ to the medical record query terminal.

[0195] If verification is successful, multiple symmetric encrypted ciphertexts of medical records that meet the criteria, along with their corresponding symmetric key ciphertexts, are sent to the medical record query terminal. Specifically, if verification is successful, a relevance score is calculated using the index vector P and the query vector Q, where the relevance score is calculated as follows:

[0196]

[0197] Based on the relevance scores, VSC sends the symmetric encrypted ciphertext of the medical records corresponding to the top k relevance scores, along with the corresponding symmetric key ciphertext, to the medical record query client.

[0198] Step 70, Decryption Algorithm: The medical record query terminal decrypts multiple symmetric encrypted ciphertexts of medical records that meet the query criteria using the queryer's private key, obtaining the decrypted file. This step includes steps 71-76:

[0199] Step 71: The medical record query terminal calculates the transformation key based on the queryer's private key. The medical record query terminal randomly selects two numbers z, y∈Z. p Calculate the transformation key tk = (tpk = {tpk1, tpk2, tpk3}, tsk = {z / y}).

[0200] in,

[0201] Step 72: The medical record query terminal sends the transformation key and the corresponding symmetric key ciphertext to the fog server assistant terminal. The medical record query terminal sends the ciphertext CT and tpk of the symmetric key to the fog server assistant terminal D-FSA.

[0202] Step 73: The fog server assistant calculates the intermediate ciphertext based on the transformation key and the corresponding symmetric key ciphertext.

[0203] Specifically, the formula for calculating the intermediate ciphertext MC is as follows:

[0204]

[0205] in,

[0206] Step 74: The fog server assistant sends the intermediate encrypted text to the medical record query terminal;

[0207] Step 75: The medical record query terminal calculates the symmetric key based on the intermediate ciphertext.

[0208] The specific calculation formula is as follows:

[0209]

[0210] Step 76: The medical record query terminal decrypts the symmetric encrypted ciphertext of the medical records corresponding to the first k relevance scores using a symmetric decryption algorithm, obtaining the decrypted file F. δ =Dec(C l ,ssk).

[0211] Smart contracts can be viewed as a type of computer protocol. Once developed and deployed, such a protocol can achieve self-execution and self-verification without human intervention, autonomously executing all or part of the contract and generating corresponding licenses to prove the validity of the contractual operations. Smart contracts support fair and trustworthy transactions in the absence of a trusted third party. This section will introduce how to search for and verify smart contracts (see Tables 2 and 3).

[0212]

[0213] Table 2 Search Smart Contracts

[0214]

[0215]

[0216] Table 3 Verification of Smart Contracts

[0217] The beneficial effects of this invention are as follows:

[0218] 1) Based on the Ethereum blockchain, there are two smart contracts: the Search Smart Contract (SSC) and the Verify Smart Contract (VSC). The SSC matches user trapdoors with the index to perform searches, while the VSC checks the correctness of the results returned by the fog server. When the user and the fog server honestly execute the contract rules, the user can obtain correct search results without additional local verification.

[0219] 2) Based on the elliptic curve discrete logarithm problem, a searchable attribute-encrypted medical data sharing scheme is designed, which enhances the security of the data sharing process and achieves selective CPA security;

[0220] 3) To improve search accuracy and query speed, this solution uses a vector space model to calculate the association score between the query keyword set and the files, and then sorts and searches based on the score. Finally, data users will receive the top-k documents that best meet their needs, saving network bandwidth. The encrypted index is stored on the smart contract, allowing for quick query results by simply inputting the index and the trapdoor during the trapdoor query phase.

[0221] 4) Through security proof and communication complexity analysis, it is demonstrated that the proposed solution satisfies the requirements of efficient search, policy hiding, flexible access control, and fairness in the system model;

[0222] 5) The performance of the construction scheme of the present invention is evaluated and analyzed to demonstrate that the construction scheme of the present invention is practical.

[0223] The safety of this invention will be described in detail below:

[0224] 1.1 Security Proof

[0225] 1.1.1 Correctness

[0226] (1) Calculation correctness during the search phase

[0227]

[0228]

[0229] (2) Verification of the correctness of calculations

[0230]

[0231] (3) Correctness of calculations during the decryption phase

[0232]

[0233]

[0234]

[0235] 1.1.2 Security

[0236] Theorem 1: Assume that Waters’s solution is selectively CPA-safe, and that our proposed solution is also selectively CPA-safe.

[0237] Proof: If there is an adversary Our plan can be disrupted based on the chosen plaintext attack model, and then we can build a simulator. It disrupts Waters's plan with undeniable advantages. The interaction of this security game is as follows: Figure 7 As shown.

[0238] Initialization: In this phase, notify Set the access strategy that the opponent wants to challenge. * =(M * ,ρ * Next, through Send Γ * Give Then Calculate PP′ and return it to

[0239] After receiving PP′, define A5 = α1G, and obtain PP through the following calculations, then send it to...

[0240]

[0241] Query Phase I: Create an empty table N and an empty set J, and perform the following query:

[0242] • Private key lookup: Input (uid,S) uid To perform a key lookup. Ask the challenger The private key is obtained from the key generation oracle. Randomly select t∈Z P And the retrieval key RK is calculated as follows:

[0243]

[0244] Then, Towards Send RK and calculate J = J∪S uid .

[0245] • Key conversion lookup: Check if (S) exists in table N. uid ,RK,tk). If it exists, Send it to otherwise Choose y, z∈Z p Calculate the conversion key

[0246] Then (S) uid Add ,RK,tk) to the table

[0247] In N. Finally. Send tk to

[0248] challenge: Select two messages of the same size, m0 and m1, and send them to... Then and m0, m1 and Γ * Send together Then choose Encryption was performed using a searchable encryption scheme by Jin Li et al. To obtain CT*, and then send it to Then Choose v = {s, s2, ..., s} n} For each line M i Select r i ∈Z p Then make C = m δ ·e(A3,S),C0=χG,C1=S,C 1,i =(r i +λ i G,C 2,i =r i G,C 3,i =v ρ(i) r i G, and send it to

[0249] Query Phase II: Continue with the first phase of the query, and the attribute set used for the private key query cannot satisfy Γ. * .

[0250] guess: His / her conjecture about ζ is given as δ∈{0,1}.

[0251] When δ = ζ It perfectly simulates the game. Therefore, if an opponent exists... Its advantage lies in the fact that disrupting our plans is not negligible, so we can construct a simulator to break the plan.

[15] Its advantages cannot be ignored.

[0252] Theorem 2: This scheme supports hidden access strategies.

[0253] Proof: In this scheme, the DO (Data Owner) establishes an appropriate access policy to encrypt data. To protect sensitive information within the access policy, the adversary chooses a random value χ as a hidden attribute in the access policy. Specifically, the data owner calculates q... i =e(H1(attr) i (A5) χ Replace each attribute in the access strategy.

[0254] To ensure that only authorized users can access and decrypt encrypted data, VSC first verifies that the user's attribute set meets the blind access policy. Specifically, it uses the attribute private key component. To calculate q′ i And judgment q i =q′ iWhether it holds true. Access and decryption operations can only be performed if the equation holds true and the authorized user's attribute set satisfies the access policy. It is precisely because of the existence of the random value χ that unauthorized users cannot access e(H1(attr) from the data. i (A5)χ) Obtain information about the access policy.

[0255] Below, we will analyze the feasibility of our solution from three perspectives: security comparison, cost comparison, and actual performance implementation.

[0256] 1.1.3 Functional Comparison

[0257] We analyzed the functionality of our solution in terms of fine-grained access control, policy hiding, multi-keyword search, result ranking, verifiability of the solution, and fog server storage. By comparing the functionality with some existing solutions [1-4] in Table 4, it can be seen that our constructed solution meets all the functional requirements.

[0258] Among them, the solution [1]: Fan Y, Liu Z.Verifiable attribute-based multi-keywordsearch over encrypted cloud data in multi-owner setting[C] / / 2017 IEEE secondinternational conference on data science in cyberspace(DSC). IEEE, 2017: 441-449.

[0259] Scheme [2]: Han D, Pan N, Li K CA traceable and revocable ciphertext-policy attribute-based encryption scheme based on privacy protection[J]. IEEETransactions on Dependable and Secure Computing, 2020,19(1):316-327.

[0260] Scheme [3]: Ge C, Susilo W, Baek J, et al. Revocable attribute-based encryption with data integrity in clouds [J]. IEEE Transactions on Dependable and Secure Computing, 2021, 19(5): 2864-2872.

[0261] Scheme [4]: ​​Gu K, Zhang W, Li

[0262] Table 4 Functional Comparison

[0263]

[0264] 1.1.4 Experimental Environment

[0265] The simulation in this paper was performed on the local machine. Table 5 below shows the environmental configuration parameters for this experiment.

[0266] Table 5. Details of Experimental Environment Parameters

[0267]

[0268] 1.1.5 Cost Comparison

[0269] We compared the computational costs of the proposed schemes and the results are shown in Table 6, while the storage costs are shown in Table 7. Table 6 shows that although the scheme constructed in this invention has a higher cost for message encryption than schemes [1,3,4], it is significantly superior to other schemes in the trapdoor generation, search, and decryption stages, thus the overall cost is lower than other schemes. Table 7 shows that, in terms of storage cost comparison, the scheme of this invention is superior to schemes [1-3] in terms of ciphertext size; it is on par with scheme [4] in terms of index size and superior to scheme [1]; it is on par with scheme [4] in terms of private key size and superior to schemes [2,3]; and it is superior to scheme [1] in terms of trapdoor size and on par with scheme [4].

[0270] Table 6 Comparison of Computational Costs

[0271] [1] <![CDATA[(2n2+4)E+E2]]> <![CDATA[(2n1+l2+4)E+E T ]]> <![CDATA[(l2+3)P]]> <![CDATA[(2n1+1)P]]> [2] <![CDATA[(6n2+2)E+E2]]> × × <![CDATA[(5n2+2)E+5P]]> [3] <![CDATA[(4n2+2)E+E2]]> × × <![CDATA[2n3E T +4P]]> [4] <![CDATA[(2n2+3)E+E2]]> <![CDATA[(2n1+l2+4)E+E T ]]> <![CDATA[(l2+3)P]]> <![CDATA[(4n1+2)P+2n1E2]]> This invention <![CDATA[(4n2+2)E+E2]]> 3E <![CDATA[(l2+2)P]]> <![CDATA[E2+2P]]>

[0272] Table 7 Storage Costs

[0273]

[0274] 1.1.6 Performance Comparison

[0275] Through experimental analysis, the various stages of the present invention were tested with code and the running time was recorded. Finally, the results were compared with those of schemes [1-4], and the results are as follows.

[0276] from Figure 2 (a) It can be seen that, in the comparison of encryption time between our scheme and schemes [1-4] under different numbers of attributes in the encryption stage, when the number of attributes increases, the encryption time of our scheme increases linearly with the number of attributes, and the encryption time is only lower than that of scheme [4]. However, this is because our scheme takes into account multi-keyword sorting search more than other schemes [1-3] in the encryption stage, so the time consumption is slightly more, but it is still within an acceptable range. And the time consumption is less than that of scheme [4].

[0277] from Figure 2 (b) It can be seen that, in comparison with other schemes, the decryption time of DU decryption of scheme [2,3,4] increases linearly with the increase of the number of attributes, while our scheme and scheme [1] basically achieve decryption calculation time independent of the number of attributes, that is, when the number of attributes increases, the decryption time does not change much.

[0278] Down Figure 3 , Figure 4 and Figure 5 The computational costs of our scheme and schemes [1,4] at different keyword counts in the IdxGen and TrapGen stages are shown respectively, i.e., a comparison of the computational costs of the two stages when the number of keywords is 100, 300, and 500. Figure 3 (b), Figure 4 (b) and Figure 5 As can be seen from (b), in our scheme, the computational cost in the TrapGen stage does not increase with the number of attributes, the computation time is independent of the number of attributes, and the computational cost is much lower than that of scheme [1,4]. From Figure 3 (a), Figure 4 (a) and Figure 5 As shown in (a), although our solution is not the one with the shortest computation time, it is at an intermediate level among the compared solutions. Therefore, the overall computational cost is relatively low.

[0279] When comparing storage overhead, we assume |G| = 1024 bits. We made some comparisons on points that have a significant impact on storage, including the size of the private key, ciphertext, index, and trapdoor. Figure 6 (a) reflects that in the KeyGen stage, the storage cost and number of attributes of the user private key in our scheme and schemes [1-4] are linearly increasing, and our scheme is significantly better than schemes [3,4].

[0280] Figure 6 (b) Reflecting the TrapGen stage, it can be clearly seen that the trapdoor overhead of scheme [1] increases linearly with the query, while our scheme and scheme [4] maintain a low constant level.

[0281] Figure 6 (c) Displaying the storage cost of the ciphertext, we can see that the storage cost of our scheme and schemes [1-4] increases linearly with the number of attributes, but our scheme has a slight advantage over scheme [4] and performs better, while being on par with scheme [3]. Compared to schemes [1,2], the storage cost of our scheme increases more slowly, leaving more room for improvement in the later stages.

[0282] Figure 6 (d) reflects the generation stage of IdxGen. It can be seen that our algorithm maintains a constant level of index storage cost and attribute count during the IdxGen stage. In contrast, the index storage cost in schemes [1,4] increases linearly with the number of attributes, thus our scheme has an advantage.

[0283] Since other solutions do not provide specific cost data for smart contracts, only the cost of this solution is presented here without comparison. The cost of deploying the smart contract is shown in Table 8 below:

[0284] Table 8 Smart Contract Consumption

[0285]

[0286] In summary, the solution constructed in this invention is more complete in terms of functionality, making up for the functional deficiencies of other solutions; it also performs better in terms of computational cost, especially in terms of computational cost, which is significantly better than other solutions; in performance comparison, all comparisons are within an acceptable range, ranking among the top performers of the compared solutions. Therefore, our solution is reliable and has performance advantages.

[0287] To achieve flexible access control and secure data sharing, blockchain-based attribute-based searchable encryption addresses fairness, user privacy, and policy concealment issues among untrusted cloud servers, users, and fog servers in smart healthcare scenarios. This solution designs two types of smart contracts: a search contract checks if a user's trapdoor matches the index, reducing the fog server's search cost; the other smart contract verifies the correctness of returned search results without requiring additional verification overhead from local users. Furthermore, to reduce user network bandwidth consumption and improve search accuracy, this invention employs a vector space model to calculate and query keyword sets and sort files by relevance to return the precise files required by the user. Security proofs demonstrate that the proposed solution satisfies the indistinguishability of chosen plaintext security and chosen key security, while also implementing flexible access control policies.

[0288] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0289] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. In addition, those skilled in the art can combine and integrate the different embodiments or examples described in this specification.

[0290] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for secure sharing of intelligent medical data based on national cryptographic algorithms, characterized in that, Includes the following steps: The attribute authority outputs system public parameters and master key based on security parameters and the registered doctor user attribute set; and determines the retrieval key and the public and private keys of the medical record management terminal based on the system public parameters, the master key, the querier's identity identifier and the querier's registered doctor user attribute set. Obtain the index key from the medical record management terminal; The retrieval key and the index key are sent to the medical record query terminal as the queryer's private key, and the public key and the private key are sent to the medical record management terminal; The medical record management terminal protects key information of the preset access structure, obtains the preset protected access structure, and sends the attribute protection information of the preset protected access structure to the blockchain. Each medical record file in the medical record file set is encrypted using a symmetric encryption algorithm to obtain the corresponding symmetric encrypted ciphertext and symmetric key for each medical record, and the symmetric encrypted ciphertext of the medical record is sent to the fog server; Based on the symmetric key and random number The following steps are taken to generate a symmetric key ciphertext on the blockchain: using a binary random vector of the index key, the preset protection access structure, and the system public parameters; calculating the signature of each medical record file based on the medical record administrator's identity and the system public parameters; determining a first index parameter, a second index parameter, and a third index parameter based on random numbers of keywords in the medical record keyword set and the system public parameters; determining a fourth index parameter based on the keywords and the medical record file; determining the medical record index based on the first, second, third, and fourth index parameters; determining the index vector corresponding to the medical record index based on the medical record file and the index key; and sending the medical record index and the index vector to the blockchain. The medical record query terminal generates a query trapdoor and a query vector based on the queryer's private key, medical record query keywords, and system public parameters, and sends the query trapdoor and the query vector to the blockchain; The blockchain obtains multiple corresponding symmetric encrypted ciphertexts of medical records from the fog server based on the medical record index and the query trapdoor; calculates a first parameter to be verified based on the queryer's private key; if the first parameter to be verified matches the attribute protection information, then generates a digital certificate for each symmetric encrypted ciphertext of medical records based on the identity identifier of the medical record manager, and sends the digital certificate and the signature of the corresponding medical record file to the fog server; The fog server calculates the parameter pair to be verified based on the digital certificate and the signature of the medical record file, and sends the parameter pair to the blockchain; The blockchain verifies each medical record's symmetric encrypted ciphertext based on the parameters to be verified and the public key; If the verification is successful, multiple symmetric encrypted ciphertexts of medical records that meet the conditions and the corresponding symmetric key ciphertexts are sent to the medical record query terminal. The medical record query terminal calculates the transformation key based on the queryer's private key; Send the transformation key and the corresponding symmetric key ciphertext to the fog server assistant. The fog server assistant calculates the intermediate ciphertext based on the transformation key and the corresponding symmetric key ciphertext; and sends the intermediate ciphertext to the medical record query terminal. The medical record query terminal calculates the symmetric key based on the intermediate ciphertext; The symmetric encryption ciphertexts of multiple medical records that meet the conditions are decrypted using a symmetric decryption algorithm to obtain the decrypted file.

2. The intelligent medical data secure sharing method based on national cryptographic algorithms according to claim 1, characterized in that, The medical record query terminal generates a query trapdoor and a query vector based on the queryer's private key, medical record query keywords, and system public parameters, and sends the query trapdoor and the query vector to the blockchain, including: The medical record query terminal generates a query trap based on the medical record query keywords and the system's public parameters; The medical record query terminal generates a query vector based on the index key in the queryer's private key; The medical record query terminal sends the query trap and the query vector to the blockchain.

3. The intelligent medical data secure sharing method based on national cryptographic algorithms according to claim 1, characterized in that, The blockchain retrieves multiple corresponding symmetric encrypted ciphertexts of medical records from the fog server based on the medical record index and the query trapdoor, including: The blockchain determines whether the medical record index and the query trapdoor match; If a match is found, the blockchain sends the medical record file identifier corresponding to the medical record index to the fog server; The fog server searches for the corresponding symmetric encrypted ciphertext of the medical record based on the medical record file identifier, and sends the found multiple symmetric encrypted ciphertexts of the medical records to the blockchain.

4. The intelligent medical data secure sharing method based on national cryptographic algorithms according to claim 1, characterized in that, The system public parameters and the master key are represented as follows: ； in, Indicates system common parameters, Indicates the master key. , H This represents a one-way mapping hash function. express generator, , .

5. The intelligent medical data secure sharing method based on national cryptographic algorithms according to claim 1, characterized in that, The expression for the retrieval key is: ； in, Indicates the identity of the inquirer. This represents the set of registered doctor user attributes of the queryer.

Images