Electronic medical data sharing system based on auditable policy-based purifiable signatures

Abstract

The application provides an electronic medical data sharing system based on an auditable policy-based cleanable signature, comprising: a trusted center; a medical data provider; a medical data cleaner; a medical data user; a cloud server; in order to solve the problem that the data cannot be cleaned in time when a single cleaner is offline or unwilling to clean, the application comprises a signer and multiple cleaners, and realizes invisibility and unlinkability. In addition, the application realizes the auditable nature of the signer and the multiple cleaners by using zero-knowledge proof.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electronic medical data processing, and particularly to an electronic medical data sharing system based on an auditable policy-based sanitizable signature. BACKGROUND

[0002] With the development of the Internet and cloud computing, electronic medical data can be stored on a cloud server to achieve flexible data sharing. The sharing of electronic medical data is of great significance to the accurate treatment of patients, the development of medical treatment, etc. With the application of electronic medical data to more fields such as hospital management, insurance claims, judicial evidence collection, medical research, the authenticity and usability of electronic medical data are crucial to the correct use of medical data and the full realization of the value of medical data sharing. At the same time, since electronic medical data contains a large amount of sensitive information, in order to realize safe medical data sharing, a sanitizable signature technology can be used to sign and perform privacy protection processing on electronic medical data. In a sanitizable signature, a specified sanitizer (Sanitizer) is allowed to make controlled modifications to the signed data without the help of the signer, and the signature will not be invalidated. This technology not only guarantees the integrity and authenticity of the data, but also protects the confidentiality of part of the data. Therefore, compared with traditional digital signatures, sanitizable signatures are more suitable for electronic medical data sharing systems and can better protect sensitive information in electronic medical data.

[0003] In a sanitizable signature scheme, unlinkability and unobservability are two very important properties. Unlinkability can prevent a verifier from linking processed data-signature pairs of the same data, thereby preventing an attacker from linking multiple sanitized data-signature pairs together in order to reconstruct the content of the original data. Unobservability can hide from the verifier which parts of the data can be modified, thereby preventing the verifier from inferring which data blocks can be modified and the number of data blocks that can be modified. In order to achieve both unlinkability and unobservability, Bultel et al. proposed the first efficient sanitizable signature scheme that simultaneously achieves unlinkability and unobservability by using equivalence class signatures, public-key encryption, hash functions, and verifiable ring signatures. However, this scheme does not support access control for sanitizers, requires the specification of sanitizers at the time of signing, and has low flexibility.

[0004] To solve the above problems, Samelin et al. proposed a strategy-based sanitizable signature with auditability, in which a signer can specify an access policy when performing a signing operation, and only sanitizers satisfying the access policy can modify the data of the signature and generate a valid signature. However, this scheme does not satisfy unlinkability and invisibility. In this scheme, a chameleon hash function is used, and the same hash value is included in the signature even after the sanitization operation is performed. Attackers can link multiple data-signature pairs according to the hash value, so it does not satisfy unlinkability. In addition, ADM (Admissible Modifications) is provided in plaintext in the signature, and the description of the block of modifiable data is included in the ADM, so it does not satisfy invisibility.

[0005] The above scheme only considers the case of a signer and a single sanitizer, which can cause the problem that data cannot be sanitized in time, because there is only one sanitizer in the scheme, and data cannot be sanitized if the sanitizer is unwilling to sanitize data or is offline. Because there is only one sanitizer, it also does not satisfy multi-sanitizer auditability. Bultel et al. use a verifiable ring signature to achieve signer and single-sanitizer auditability, but this method has low flexibility and is not suitable for the case of multiple sanitizers, because the public key in the ring generated by the signer is fixed, and the signer needs to regenerate the ring if the authority is granted to a new sanitizer. Samelin et al. use public key encryption and zero-knowledge proof to achieve signer and single-sanitizer auditability, but do not give the specific construction of the zero-knowledge proof. In addition, existing schemes can only generate proof tags by the signer when a dispute occurs, and cannot achieve auditability if the signer is offline or unwilling to generate proof tags. SUMMARY

[0006] Therefore, the purpose of the present application is to provide an electronic medical data sharing system based on a strategy-based sanitizable signature with auditability, which realizes invisibility and unlinkability. In addition, the present application uses zero-knowledge proof to realize signer and multi-sanitizer auditability.

[0007] To achieve the above purpose, the present application adopts the following technical scheme: an electronic medical data sharing system based on a strategy-based sanitizable signature with auditability, comprising:

[0008] a trusted center; the trusted center is a fully trusted entity, responsible for the initialization of the system and the generation of attribute keys for medical data sanitizers; collects proof tags when a dispute occurs, and finds out the actual generator of the signature;

[0009] a medical data provider; the medical data provider provides medical data and signs the medical data to ensure the authenticity of the medical data, and specifies the access policy for medical data sanitization; generates a proof tag to prove that he is or is not the actual generator of the signature when a dispute occurs;

[0010] medical data sanitizer; the medical data sanitizer modifies the medical data according to the access policy specified by the medical data provider, and can generate a valid signature without the help of the medical data provider; in case of dispute, it also generates a proof tag;

[0011] medical data user; the medical data user accesses the medical data and signature in the cloud server, and can verify the validity of the signature, thereby confirming the validity of the data, and using the data for diagnosis and research;

[0012] cloud server; the cloud server is semi-honest, providing a service of storing electronic medical data and signatures, but cannot modify the data; by storing data in the cloud, the burden of local storage of users is reduced, and users share data with others in a non-interactive manner.

[0013] In a preferred embodiment, the following algorithms are included: system initialization algorithm Setup, master key pair generation algorithm ParGen, medical data provider key pair algorithm KGen sig , medical data sanitizer key pair generation algorithm KGen san , attribute key generation algorithm AttKGen, signature algorithm Sign, sanitization algorithm Sanit, signature verification algorithm Verify, medical data provider proof tag generation algorithm Proof sig , medical data sanitizer proof tag generation algorithm Proof san , judgment algorithm Judge;

[0014] : executed by the trusted center, input security parameter , output public parameter pp;

[0015] : executed by the trusted center, input public parameter pp, output master key msk and public key mpk;

[0016] : executed by the medical data provider, input public parameter pp, output the key pair of the data provider ;

[0017] : executed by the medical data sanitizer, input public parameter pp and identity i, output the key pair of the medical data sanitizer ;

[0018] : executed by the trusted center, input public key mpk, master key msk, sanitizer public key and attribute set , generate attribute key for medical data sanitizer ;

[0019] : performed by a medical data provider, input public key mpk, purifier public key set , medical data provider private key , medical data m, modifiable block description set ADM and access policy , output medical data signature ;

[0020] : performed by a medical data purifier, input public key mpk, medical data provider public key , purifier public key set , medical data purifier private key , attribute key , medical data m, signature and modification operation set MOD, output medical data signature and modified medical data ;

[0021] : performed by a medical data user, input public key mpk, medical data provider public key , purifier public key set , medical data m and signature , if the signature is valid, output 1, otherwise output 0;

[0022] : performed by a medical data provider when a dispute occurs, input public key mpk, medical data provider private key , medical data provider public key , medical data m and signature , output proof label ;

[0023] : performed by a medical data purifier when a dispute occurs, input public key mpk, medical data purifier private key , medical data purifier public key , medical data m and signature , output proof label ;

[0024] : performed by a trusted center, the trusted center needs to be responsible for collecting enough proof labels; algorithm input medical data provider public key , purifier public key set , medical data m, signature and proof label , output the actual generator identity of the signature.

[0025] In a preferred embodiment,

[0026] In the system initialization phase, the trusted center runs the Setup algorithm to generate the public parameters of the system; let EQS denote the equivalence class signature scheme, FAME denote the attribute encryption scheme, set is a factorial method cyclic group, respectively the generator of the group , is a non-symmetric bilinear mapping; first execute , select the hash function , , and the symmetric key encryption scheme , let , output ;

[0027] In the master key pair generation phase, execute , let , , output ;

[0028] In the key pair and attribute key generation phase, randomly select , calculate , execute , let , , output ; randomly select , calculate , return ; if , return ; execute , return ;

[0029] In the signature phase, ; executed by the medical data provider, if , return ; the medical data is divided into blocks, that is ; for , select , calculate , , , let

[0030]

[0031] Calculate , ; randomly select , execute , , let , execute ; then, let , compute and ; to prove that "i is an element of the set of modifiable block descriptions ADM", randomly select , compute and , let , return the signature ;

[0032] In the sanitization phase, , executed by the medical data sanitizer, if then return ; compute , let , compute if then return ; let , randomly select , for , let , , compute and

[0033]

[0034] Formula explanation:

[0035] If , i.e. i is an element of the set of modifiable block descriptions ADM, then compute , which is the th power of the hash value ;

[0036] If it is otherwise ( ), i.e. i is not an element of the set of modifiable block descriptions ADM, then compute , which is the th power of the signature value ;

[0037] Randomly select , compute , let , execute ; compute , ; then, let , compute , ​To prove " " , compute and , let , let , return ;

[0038] In the signature verification phase, , performed by the medical data consumer, compute , verify the following equation:

[0039]

[0040] If the above equation holds, return 1, otherwise return 0;

[0041] Formula explanation:

[0042] Only and the hash value are equal and for all , i.e. is an element in the set , and are not equal and and and for all , i.e. is an element in the set , and are equal, the algorithm returns 1, otherwise returns 0;

[0043] In the proof label generation phase, , performed by the medical data provider, compute , in two cases:

[0044] (1) If , prove " "; randomly select , compute and , let ;

[0045] (2) If , prove " "; randomly select , compute , , and , let ; return the proof label ;

[0046] Performed by medical data purifiers, calculations There are two possible scenarios:

[0047] 1) If Then prove " Random selection ,calculate and ,make ;

[0048] 2) If Then prove " Random selection ,calculate , , and ,make ;

[0049] Return to proof label ;

[0050] During the audit phase, Executed by a trusted center, computation There are two possible scenarios:

[0051] (Ⅰ) When This indicates that a user may have generated a signature that they themselves were the actual generator of. If so, return Signer; If so, then output Santizer-i;

[0052] (II) When Then, enough proof labels need to be collected; when enough proof labels are collected, if and , If all purifiers generate signatures that are not the actual producers of the signatures, return Signer; otherwise... , and , If the medical data provider and the other purifiers besides sanitizer-i generate the signature but are not the actual generators, then output Santizer-i.

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

[0054] (1) A kind of auditable strategy-based invisible unlinkable purifiable signature scheme is designed.In order to solve the problem that single purifier may not be online or unwilling to purify when purifying data in time, the present application includes signer and multiple purifiers, and realizes invisibility and unlinkability.In addition, the present application realizes the auditable of signer and multiple purifiers using zero-knowledge proof.

[0055] (2) Most existing purifiable signature schemes can only generate proof label by signer when dispute occurs, and if the signer is not online or unwilling to generate proof label, the auditable cannot be realized.In order to solve this problem, the present application allows the signer and the purifier to generate proof label respectively, and the trusted center collects the proof label to find out the actual generator of the signature.

[0056] (3) Based on the auditable strategy-based invisible unlinkable purifiable signature scheme proposed in the present application, a privacy protection electronic medical data sharing scheme is proposed.Specifically, the medical data provider can specify access policy when signing data, and the medical data purifier that meets the access policy can modify the signed medical data and generate valid signature.When dispute occurs, the actual generator of the signature can be found out. BRIEF DESCRIPTION OF DRAWINGS

[0057] Figure 1 The system model schematic diagram of the preferred embodiment of the present application. DETAILED DESCRIPTION

[0058] The present application will be further described below in conjunction with the drawings and embodiments.

[0059] It should be noted that the following detailed description is exemplary and is intended to provide further explanation of the present application. Unless otherwise indicated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application pertains.

[0060] It should be noted that the terms used herein are only for the purpose of describing specific embodiments, and are not intended to limit the exemplary embodiments according to the present application; As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form, and furthermore, it should be understood that when the terms "comprise" and / or "include" are used in the specification, there is a feature, step, operation, device, component and / or combination thereof.

[0061] The present application is studied for the above problems, as follows:

[0062] (1) An auditable policy-based invisible unlinkable sanitizable signature scheme is designed. In order to solve the problem that data cannot be sanitized in time when a single sanitizer is offline or unwilling to sanitize, the invention contains a signer and multiple sanitizers, and realizes invisibility and unlinkability. In addition, the invention realizes the auditable of the signer and multiple sanitizers by using zero-knowledge proof.

[0063] (2) Most existing sanitizable signature schemes can only generate proof tags by the signer when there is a dispute, and the auditable cannot be realized if the signer is offline or unwilling to generate proof tags. In order to solve this problem, the invention allows the signer and the sanitizer to generate proof tags respectively, and the trusted center collects the proof tags to find out the actual generator of the signature.

[0064] (3) Based on the auditable policy-based invisible unlinkable sanitizable signature scheme proposed in the invention, a privacy-protected electronic medical data sharing scheme is proposed. Specifically, the medical data provider can specify the access policy when signing the data, the medical data sanitizer satisfying the access policy can modify the signed medical data and generate a valid signature. When there is a dispute, the actual generator of the signature can be found out.

[0065] I. The system model of the electronic medical data sharing system based on the auditable policy-based sanitizable signature is shown in Figure 1 . The system consists of the following five different entities.

[0066] (1) Trusted center

[0067] The trusted center is a fully trusted entity, responsible for the initialization of the system and the generation of attribute keys for medical data sanitizers. When there is a dispute, it can collect proof tags to find out the actual generator of the signature.

[0068] (2) Medical data provider

[0069] The medical data provider provides medical data and signs the medical data to ensure the authenticity of the medical data, and specifies the access policy of the medical data sanitizer. When there is a dispute, it can generate proof tags to prove that it is or is not the actual generator of the signature.

[0070] (3) Medical data sanitizer

[0071] The medical data sanitizer (such as a patient or a doctor) that satisfies the access policy specified by the medical data provider can modify the medical data and generate a valid signature without the help of the medical data provider. When there is a dispute, it can also generate proof tags.

[0072] (4) Medical data user

[0073] The medical data user can access the medical data and the signature in the cloud server, and can verify the validity of the signature, thereby confirming the validity of the data, and can use the data for diagnosis, research or other purposes.

[0074] (5) Cloud server

[0075] The cloud server is semi-honest, and can provide a service of storing electronic medical data and signatures, but cannot modify the data. In addition, by storing the data in the cloud, the burden of local storage of the user is reduced, and the user can also share the data with others in a non-interactive manner.

[0076] Table 1: Symbolic variables

[0077]

[0078]

[0079] Formal definition of the system

[0080] The system of the present application includes the following algorithms: system initialization algorithm Setup, master key pair generation algorithm ParGen, medical data provider key pair algorithm KGen sig , medical data purifier key pair generation algorithm KGen san , attribute key generation algorithm AttKGen, signature algorithm Sign, sanitization algorithm Sanit, signature verification algorithm Verify, medical data provider proof label generation algorithm Proof sig , medical data purifier proof label generation algorithm Proof san , and judgment algorithm Judge.

[0081] 1. : The algorithm is executed by a trusted center, and the input is a security parameter , and the output is a public parameter pp.

[0082] 2. : The algorithm is executed by a trusted center, and the input is a public parameter pp, and the output is a master key msk and a public key mpk.

[0083] 3. : The algorithm is executed by a medical data provider, and the input is a public parameter pp, and the output is a data provider's key pair .

[0084] 4. : The algorithm is executed by a medical data purifier, and the input is a public parameter pp and an identity i, and the output is a medical data purifier's key pair .

[0085] 5. The algorithm is executed by the trusted center, input public key mpk, master key msk, purifier public key and attribute set , generate attribute key for medical data purifier .

[0086] 6. The algorithm is executed by the medical data provider, input public key mpk, purifier public key set , medical data provider private key , medical data m, admissible modification set ADM (Admissible Modifications) and access policy , output medical data signature .

[0087] 7. The algorithm is executed by the medical data purifier, input public key mpk, medical data provider public key , purifier public key set , medical data purifier private key , attribute key , medical data m, signature and modification operation set MOD, output medical data signature and modified medical data .

[0088] 8. The algorithm is executed by the medical data user, input public key mpk, medical data provider public key , purifier public key set , medical data m and signature , if the signature is valid, output 1, otherwise output 0.

[0089] 9. The algorithm is executed by the medical data provider when a dispute occurs, input public key mpk, medical data provider private key , medical data provider public key , medical data m and signature , output proof label .

[0090] 10. The algorithm is executed by the medical data purifier when a dispute occurs, input public key mpk, medical data purifier private key , medical data purifier public key , medical data m and signature , output proof label .

[0091] 11. The algorithm is executed by the trusted center, which needs to be responsible for collecting enough proof tags. The algorithm inputs the medical data provider public key , the purifier public key set , medical data m, signature and proof tag , and outputs the actual generator identity of the signature.

[0092] System initialization:

[0093] In the system initialization phase, the trusted center runs the Setup algorithm to generate the public parameters of the system

[0094]

[0095] The algorithm is called by the trusted center, and the output is the public parameter of the system

[0096] Let EQS represent the equivalence class signature scheme, and FAME represent the attribute encryption scheme, let be the factorial method cyclic group, be the generator of the group , and be the asymmetric bilinear mapping. First execute , select the hash function , , and the symmetric key encryption scheme , let , output .

[0097] Master key pair generation:

[0098] In this system, the trusted center runs the ParGen algorithm to generate the master key pair

[0099]

[0100] The algorithm is called by the trusted center, and the input is the public parameter , and the output is the master key msk and the public key mpk.

[0101] Execute , let , , output .

[0102] Key pair and attribute key generation:

[0103] ​In the system, the medical data provider needs to generate a key pair to perform subsequent operations, and the medical data purifier needs to generate a key pair and obtain an attribute key to perform subsequent operations

[0104]

[0105] The algorithm is executed by the medical data provider to generate the key pair of the medical data purifier .

[0106] Randomly select , calculate , execute , let , , output .

[0107]

[0108] The algorithm is executed by the medical data purifier to generate the key pair of the medical data purifier .

[0109] Randomly select , calculate , return .

[0110]

[0111] The algorithm is executed by the trusted center to generate an attribute key for the medical data purifier .

[0112] If , return . Execute , return .

[0113] Signature:

[0114] The medical data provider calls the signature algorithm to generate a signature before outsourcing data to the cloud server .

[0115]

[0116] The algorithm is executed by the medical data provider, and if , return . The medical data is divided into blocks, that is . For , select , calculate , , , let

[0117]

[0118] calculate , Random selection ,implement , ,make ,implement Next, order ,calculate and In order to prove " Random selection ,calculate and ,make Return signature .

[0119] Purification:

[0120] To protect the privacy of medical data, medical data cleaners execute purification algorithms to modify the medical data and generate valid signatures.

[0121]

[0122] The algorithm is executed by medical data purifiers, if... Then return .calculate ,make ,calculate ,if Then return .make Random selection ,for ,make , ,calculate as well as

[0123]

[0124] Random selection ,calculate ,make ,implement .calculate , Next, order ,calculate , In order to prove " Random selection ,calculate and ,make ,make ,return .

[0125] Signature verification:

[0126] Medical data users can download medical data and signatures from the cloud server and execute a signature verification algorithm to verify the signature.

[0127]

[0128] The algorithm is executed by the user of the medical data and calculates... Verify the following formula:

[0129]

[0130] If the above equation is true, return 1; otherwise, return 0.

[0131] Proof of label generation:

[0132] In the event of a dispute, both medical data providers and medical data cleansers can generate proof labels to demonstrate whether they are or are not the actual producers of the data-signature pairs.

[0133]

[0134] The algorithm is executed by the medical data provider and calculates... There are two possible scenarios:

[0135] (1) If Then prove " Random selection ,calculate and ,make .

[0136] (2) If Then prove " Random selection ,calculate , , and ,make .

[0137] Return to proof label .

[0138]

[0139] The algorithm was executed by medical data purifiers and calculated... There are two possible scenarios:

[0140] (1) If then prove that ". Randomly choose , compute and , let .

[0141] (2) If then prove that ". Randomly choose , compute , , and , let .

[0142] Return the proof label .

[0143] Audit:

[0144] When enough proof labels are collected, the trusted center can execute the judgment algorithm to find the actual generator of the data-signature pair.

[0145]

[0146] The algorithm is executed by the trusted center, and is calculated, which is divided into two cases:

[0147] (1) When it means that there is a user who generates the actual generator of his own signature, if , then return Signer. If , output Santizer-i.

[0148] (2) When , it is necessary to collect enough proof labels. When enough proof labels are collected, if and , it means that all purifiers generate the actual generator of their own non-signature, then return Signer. If , and , it means that the medical data provider and the rest of the purifiers except sanitizer-i generate the actual generator of their own non-signature, then output Santizer-i.

[0149] II. Bilinear mapping

[0150] Let , and be the q-th order cyclic group, and They are groups and The generator, then It is a bilinear mapping that satisfies the following properties.

[0151] (1) Bilinear: for any ,satisfy .

[0152] (2) Non-degeneracy: at least exists ,satisfy .

[0153] (3) Computability: For any There exists an efficient algorithm to calculate .

[0154] III. Encryption of Ciphertext Policy Attributes

[0155] Definition. Access structure. Let... If the attribute set is represented, then the access structure is... yes The non-empty subset of, i.e. If any satisfy and ,So Then it is called It is monotonous.

[0156] In the ciphertext policy attribute encryption scheme, the access policy is embedded in the ciphertext, and the decryption key is associated with a set of attributes. Only users with attribute keys that satisfy the access policy can correctly decrypt the ciphertext, as defined below:

[0157] Definition. Ciphertext Policy Attribute Based Encryption (CP-ABE). CP-ABE includes the following four algorithms:

[0158] (1) Algorithm input security parameters Output the public key pk and the master key msk.

[0159] (2) The algorithm inputs the master key msk and the set of attributes. Output key .

[0160] (3) The algorithm inputs are the public key pk, the data m, and the access policy. , output ciphertext c.

[0161] (4) : This algorithm takes as input public key pk, key and ciphertext c, and outputs data .

[0162] Four, equivalence class signatures

[0163] Let be a cyclic group of order q, , . Let , define equivalence relation as follows:

[0164]

[0165] Therefore, the equivalence class of x is defined as:

[0166]

[0167] Definition. Class-Hiding. For all , the relation is class-hiding if the probability that a polynomial-time adversary can distinguish elements from the same equivalence class and random samples is negligible, which is formalized as follows

[0168]

[0169] where denotes a negligible function.

[0170] Equivalence class signatures allow users to sign a representative of the equivalence class defined above, so that a representative and its corresponding signature can be updated to a new signature of a random representative in the same class.

[0171] Definition. Equivalence Class Signatures (EQS). Equivalence class signatures contain the following five algorithms:

[0172] (1) : The algorithm takes as input a bilinear group and data length , and outputs key pair .

[0173] (2) : The algorithm takes as input private key sk and data , and outputs the signature of the equivalence class .

[0174] (3) : algorithm takes as input public key pk, data x, and a signature of an equivalence class , outputs a signature of an equivalence class .

[0175] (4) : algorithm takes as input public key pk, data x, and a signature of an equivalence class , outputs if the signature is valid, and outputs otherwise.

[0176] (5) : algorithm takes as input public key pk and private key sk, outputs if the keys are consistent, and outputs otherwise.

[0177] V. Non-Interactive Zero-Knowledge Proof

[0178] Definition. A non-interactive zero-knowledge proof (NIZKP) is a pair of algorithms is a binary relation, and the language satisfies . The non-interactive zero-knowledge proof of the language contains the following 2 algorithms:

[0179] (1) : takes as input a witness , outputs a proof of .

[0180] (2) : algorithm checks whether is a valid proof of .

[0181] A non-interactive zero-knowledge proof must satisfy the following 3 properties:

[0182] (1) Completeness: for any and the corresponding witness , we have .

[0183] (2) Soundness: there is no polynomial-time adversary can produce a proof ​​with a non-negligible probability such that .

[0184] (3) Zero-knowledge: There is a polynomial-time algorithm Sim, such that and Sim(s) follow the same probability distribution, and the proof does not leak any information.

[0185] Use:

[0186] In the existing cleanable signature scheme, there are few schemes that can achieve access control of the purifier while achieving invisibility and unlinkability. In addition, the existing scheme only considers the case of a single purifier and a signer, and if the purifier is offline or unwilling to perform the purification operation, the data cannot be purified in time. The method of realizing the auditability of the purifier in the existing scheme cannot be directly extended to the case of multiple purifiers, because the flexibility of the existing method is low, and if a new purifier needs to be assigned purification authority, the signer needs to regenerate the signature. The present application contains a signer and multiple purifiers, and can realize the auditability of the signer and multiple purifiers. Specifically, the medical data provider can specify an access policy when signing the data, and only the purifier who meets the access policy can modify the signed data and generate a valid signature, thereby achieving privacy protection and access control of the purifier. In the event of a dispute, not only can the medical data provider generate a proof tag, but all medical data purifiers can generate a proof tag, thereby identifying the actual generator of the data-signature pair.

Claims

1. An electronic medical data sharing system based on auditable policy and sanitizable signatures, characterized in that... include: Trust Center; The Trust Center is a fully trusted entity responsible for system initialization and generating attribute keys for medical data purifiers. In the event of a dispute, collect supporting tags to identify the actual generator of the signature; Medical data providers offer and sign medical data to ensure its authenticity and specify access policies for data sanitization. In case of disputes, they generate proof tags to demonstrate whether they are the actual signer. Medical data purifiers; medical data purifiers that comply with the access policies specified by medical data providers modify medical data and can generate valid signatures without the assistance of medical data providers; they also generate proof labels in case of disputes. Medical data users; Medical data users access medical data and signatures in the cloud server and can verify the validity of the signatures, thereby confirming the validity of the data and using the data for diagnosis and research; Cloud server; Cloud servers are semi-honest, providing services for storing electronic medical data and signatures, but they cannot modify the data; By storing data in the cloud, the burden on users' local storage is reduced, and users can share data with others in a non-interactive way; This includes the following algorithms: Setup (system initialization algorithm), ParGen (master key pair generation algorithm), and KGen (medical data provider key pair algorithm). sig KGen, a key pair generation algorithm for medical data purification san Attribute key generation algorithm AttKGen, signature algorithm Sign, sanitization algorithm Sanit, signature verification algorithm Verify, and medical data provider proof label generation algorithm Proof sig Proof of Medical Data Purifiers san Judge algorithm; : Performed by a trusted center, with input security parameters Output common parameter pp; :Executed by a trusted center, inputting the public parameter pp, and outputting the master key msk and public key mpk; : Performed by the medical data provider, inputting the public parameter pp, and outputting the data provider's key pair. ; Executed by the medical data purifier, it takes public parameters pp and identity i as input and outputs the medical data purifier's key pair. ; Executed by a trusted center, inputting the public key mpk, master key msk, and purifier public key. and attribute set Generate attribute keys for medical data purifiers ; : Performed by the medical data provider, inputting the public key mpk and the purifier's public key set. Medical data provider's private key Medical data m, modifiable block description set ADM, and access policy Output medical data signature ; : Performed by the medical data cleaner, inputting the public key mpk and the public key of the medical data provider. Purifier public key set Medical data purifier private key Attribute Key Medical data m, signature Modify the operation set MOD and output medical data signature. And modified medical data ; This is executed by the medical data user, who inputs the public key mpk and the public key of the medical data provider. Purifier public key set Medical data m and signature If signature Output 1 if valid, otherwise output 0; In case of a dispute, the medical data provider will perform the action, inputting the public key mpk and the medical data provider's private key. Public key of medical data provider Medical data m and signature Output proof label ; In case of a dispute, the medical data cleaner will execute the procedure, requiring the input of the public key mpk and the medical data cleaner's private key. Medical Data Purifier Public Key Medical data m and signature Output proof label ; The process is executed by a trusted center, which is responsible for collecting sufficient proof tags; the algorithm inputs the public key of the medical data provider. Purifier public key set Medical data m, signature and proof label Output the identity of the actual generator of the signature.

2. The electronic medical data sharing system based on auditable policy-based clean signatures according to claim 1, characterized in that: During the system initialization phase, the Trusted Center runs the Setup algorithm to generate common system parameters; let EQS represent the equivalence class signature scheme, FAME represent the attribute encryption scheme, and let... yes Factorial cyclic group Groups generator, It is an asymmetric bilinear mapping; first execute Choose a hash function , , and symmetric key encryption schemes ,make Output ; During the master key pair generation phase, the following steps are performed: ,make , Output ; During the key pair and attribute key generation phase, random selection ,calculate ,implement ,make , Output Random selection ,calculate ,return ;if Then return ;implement ,return ; During the signing phase, ; This is performed by the medical data provider, if ,return Medical data Divided into Each block, that is ;for ,choose ,calculate , , ,make calculate , Random selection ,implement , ,make ,implement Next, order ,calculate and In order to prove Random selection ,calculate and ,make Return signature ; During the purification phase, This is carried out by medical data purifiers, if Then return ;calculate ,make ,calculate ,if Then return ;make Random selection ,for ,make , ,calculate as well as Formula explanation: if If i is an element in the set of modifiable block descriptions (ADM), then the calculation... This calculation formula represents the hash value. of Power; In other cases If i is not an element in the set of modifiable block descriptions (ADM), then the calculation is performed. This calculation formula represents the signature value. of Power; Random selection ,calculate ,make ,implement ;calculate , Next, order ,calculate , In order to prove Random selection ,calculate and ,make ,make ,return ; During the signature verification phase, Executed by the user of medical data, calculation Verify the following formula: If the above equation is true, return 1; otherwise, return 0. Formula explanation: only With hash value Equal and for all ,Right now It is a set The elements in and Not equal and and And for all ,Right now It is a set The elements in and The algorithm returns 1 if the values ​​are equal, otherwise it returns 0. During the proof label generation stage The calculation is performed by the medical data provider. There are two possible scenarios: (1) If Then prove " Random selection ,calculate and ,make ; (2) If Then prove " Random selection ,calculate , , and ,make Return to proof label ; Performed by medical data purifiers, calculations There are two possible scenarios: 1) If Then prove " Random selection ,calculate and ,make ; 2) If Then prove " Random selection ,calculate , , and ,make ; Return to proof label ; During the audit phase, Executed by a trusted center, computation There are two possible scenarios: (Ⅰ) When This indicates that a user may have generated a signature that they themselves were the actual generator of. If so, return Signer; If so, then output Santizer-i; (II) When Then, sufficient proof labels need to be collected; When enough proof tags are collected, if and , If all purifiers generate signatures that are not the actual producers of the signatures, return Signer; otherwise... , and , If the medical data provider and the other purifiers besides sanitizer-i generate the signature but are not the actual generators, then output Santizer-i.

Images