Medical management system and method based on dynamic attribute multiple short signature encryption

Abstract

The invention relates to a medical management system and method based on dynamic attribute multiple short signature encryption, the system comprises a block chain layer, a distributed storage layer, a calculation and encryption layer and an application layer, the block chain layer comprises a smart contract, and user permission and a signature threshold are dynamically adjusted through the smart contract; the distributed storage layer comprises a distributed storage system and is used for storing the encrypted medical data and generating unique hash for positioning and verifying the data; the calculation and encryption layer comprises a proxy re-encryption server and a plurality of authority centers, the proxy re-encryption server performs authority transfer on data through a re-encryption mechanism, and the authority centers are responsible for key generation, dynamic authority updating and re-encryption key generation during authority transfer; and the application layer comprises a data owner, and adopts a dynamic attribute multiple short signature encryption algorithm to encrypt sensitive data. Compared with the prior art, the method has the advantages of improving the safety, flexibility and efficiency of medical management and the like.

Description

Technical Field

[0001] The present invention relates to the technical field of medical electronic health record management, and in particular to a medical management system and method based on dynamic attribute multiple short signature encryption. Background Art

[0002] With the development of the economy and the advancement of medical technology, the quality and efficiency of medical services have received widespread attention. Traditional paper medical records are gradually being replaced by electronic health records (EHRs), which not only reduces management difficulty and cost, but also promotes information sharing between medical institutions, improves diagnosis and treatment efficiency and patient satisfaction. However, electronic health records contain a large amount of sensitive information, and it is particularly important to ensure its privacy and security during the sharing and storage process. In addition, EHR participants need to collect, store and share case information without knowing the patient's complete identity information, so it is crucial to establish fine-grained access control policies to ensure necessary data access while protecting patient privacy.

[0003] Some existing solutions propose attribute encryption, and subsequent research by scholars has provided some improvements. However, in practical applications, there are still problems such as high overhead, potential privacy leakage in the encryption and decryption process, and insufficient fine-grained access control.

[0004] A search revealed that Chinese invention patent application publication number CN112910840A discloses a medical data storage and sharing method and system based on a consortium blockchain. The system includes encrypting the original medical data and access policies using a multi-authority attribute-based encryption algorithm when storing medical data, storing the ciphertext in a private IPFS system, assigning a unique hash value to the stored ciphertext in the IPFS system, and storing the hash value on the consortium blockchain Fabric. The multi-authority attribute-based encryption algorithm ensures the security of patient medical data and allows patients to fully control their own medical data. However, this existing patent application faces issues with the security, flexibility, and efficiency of patient medical data management.

[0005] How to achieve safe and efficient management of medical electronic health records has become a technical problem that needs to be solved. Summary of the Invention

[0006] The purpose of the present invention is to overcome the defects of the above-mentioned prior art and provide a medical management system and method based on dynamic attribute multiple short signature encryption.

[0007] The purpose of the present invention can be achieved by the following technical solutions:

[0008] According to one aspect of the present invention, a medical management system based on dynamic attribute multiple short signature encryption is provided, which includes a blockchain layer, a distributed storage layer, a computing and encryption layer, and an application layer. The blockchain layer includes a smart contract, through which user permissions and signature thresholds are dynamically adjusted; the distributed storage layer includes a distributed storage system for storing encrypted medical data and generating a unique hash for locating and verifying data; the computing and encryption layer includes a proxy re-encryption server and multiple authority centers, the proxy re-encryption server transfers data permissions through a re-encryption mechanism, and the authority center is responsible for key generation, dynamic permission updates, and re-encryption key generation during permission transfer; the application layer includes data owners and users, and the data owners use a dynamic attribute multiple short signature encryption algorithm to encrypt sensitive medical data.

[0009] Preferably, the authority center is responsible for initializing the system, setting system parameters and generating master keys and public parameters; the authority center generates initial keys and update keys for users.

[0010] Preferably, the authority center dynamically adjusts the user's access rights according to the user's role and attributes. When the data owner changes or the user's attributes change, the authority center will generate a new key or re-encryption key.

[0011] Preferably, the data owner is responsible for creating and encrypting patient medical record data, encrypting sensitive data using a dynamic attribute multi-short signature encryption algorithm, generating a signature for the encrypted data, uploading the encrypted data to a distributed storage system, and recording relevant metadata on the blockchain.

[0012] Preferably, the data owner encrypts the patient data using a private key to generate encrypted data;

[0013] The data owner generates a signature for the encrypted data using a private key;

[0014] The data owner uploads the encrypted data and signature to the distributed storage system of the distributed storage layer, generates a data hash, and records the data hash and signature hash on the blockchain.

[0015] Preferably, when a user initiates an access request, the smart contract verifies whether the user's permissions comply with the preset access policy. If so, the verification passes; otherwise, the verification fails.

[0016] Set different signature thresholds based on user attributes and dynamically adjust the signature thresholds based on access requests;

[0017] The smart contract dynamically adjusts the signature threshold based on the scenario, including in emergency situations, where the system accelerates access control by appropriately lowering the signature threshold.

[0018] Preferably, the permission transfer is implemented based on a proxy re-encryption mechanism, and the process includes:

[0019] 1091, when user attributes are changed, the authority center will update the attribute version number to the new attribute version number to ensure that the user attributes are consistent with the latest version;

[0020] 1092, the authority center generates a new version key pair based on the user attributes and the new version number, namely, a new private key and a new public key;

[0021] 1093, the authority center generates a re-encryption key: inputs the old private key and the new public key, and outputs the re-encryption key;

[0022] 1094, the proxy re-encryption server uses the re-encryption key to convert the old version of encrypted data into the new version of encrypted data;

[0023] 1095, record the user's new attribute version number and data associated hash on the blockchain;

[0024] 1096, cancel the old version key.

[0025] According to another aspect of the present invention, a medical management method based on dynamic attribute multiple short signature encryption is provided, the method comprising:

[0026] System initialization: takes security parameters as input and outputs global public parameters;

[0027] Key generation: Authority center i generates keys based on the initialized public parameters and the attribute set AT it manages. i Generate public key PK i and private key SK i ; Authority center i is the user's initial attribute version V i Distribute key pairs And it is managed by the authority center i, where is the private key, is the public key;

[0028] Data encryption and signature: The data owner uses his own private key Patient data M D Encryption, generate encrypted data The data owner uses the private key Generate doctor's signature for encrypted data C

[0029] Data storage and on-chain records: Data owners will encrypt data and signature Upload to the distributed storage system, generate data hash, and record the data hash and signature hash on the blockchain;

[0030] User access request and user signature: The user generates an access request and generates a user signature for the access request;

[0031] Smart contract verifies user request and user signature: The smart contract verifies the user signature using the user's public key and checks whether the access metadata complies with the user's permissions and attributes;

[0032] Data access and decryption: If the smart contract verification is successful, the authorized user locates and downloads the encrypted data based on the data hash recorded on the blockchain. The user uses the private key to decrypt the data and verifies the data integrity through the doctor's signature.

[0033] Preferably, the method further comprises authority transfer: when the data owner changes, the key is updated based on a proxy re-encryption mechanism;

[0034] Use batch signature verification mechanism to verify multiple signature sets and corresponding public key sets of users.

[0035] Preferably, the smart contract sets different signature thresholds based on user attributes and dynamically adjusts the signature threshold based on access requests;

[0036] The smart contract dynamically adjusts the signature threshold based on the scenario, including in emergency situations, where the system accelerates access control by appropriately lowering the signature threshold.

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

[0038] 1) This invention designs a layered hybrid blockchain architecture consisting of a blockchain layer, a distributed storage layer, a computing and encryption layer, and an application layer. Through smart contracts, user permissions and signature thresholds are dynamically adjusted to achieve more fine-grained key updates, avoiding large-scale key regeneration and redistribution. Through a proxy re-encryption mechanism, attribute-based version updates and permission transfers are performed on data, enabling dynamic permission management without re-encrypting or re-uploading data, thereby improving system efficiency. This improves the security, flexibility, and efficiency of medical data management.

[0039] 2) When the data owner changes or the user attributes are updated, the authority center of the present invention can automatically generate new keys or re-encryption keys and process signatures in batches to ensure timely update and transfer of permissions, as well as the security and flexibility of permission management.

[0040] 3) This invention uses smart contracts on the blockchain to dynamically adjust user permissions and signature thresholds, providing a decentralized permission management function, ensuring that different access needs match different authentication requirements, and ensuring the transparency and traceability of the system; it allows for temporary lowering of thresholds in special emergency situations (such as first aid) to accelerate data access and meet the need for immediate response. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 This is a schematic diagram of the structure of the medical management system of the present invention;

[0042] Figure 2 This is a schematic diagram of the model for dynamic attribute multiple short signature encryption in the present invention;

[0043] Figure 3 Schematic diagram of the workflow of the rights transfer mechanism based on proxy re-encryption in the present invention;

[0044] Figure 4 Schematic diagram of the process of the medical management method of the present invention. DETAILED DESCRIPTION

[0045] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0046] Example 1

[0047] This embodiment relates to a medical management system based on dynamic attribute multiple short signature encryption, which aims to improve the security, flexibility and efficiency of the medical management system. The system solves the problems of high overhead, privacy leakage in the encryption and decryption process, and insufficient fine-grained access control in existing medical data management systems through the organic combination of blockchain, distributed storage, proxy re-encryption and smart contracts.

[0048] like Figure 1 The system is based on a four-layer hierarchical hybrid architecture and multiple short signature encryption based on dynamic attributes. The hierarchical hybrid architecture includes a blockchain layer, a distributed storage layer, a computing and encryption layer, and an application layer. The four layers work together to achieve efficient, secure and flexible medical data management.

[0049] The blockchain layer, as the core control and recording layer, has the following functions:

[0050] Store data metadata: including data hashes, signatures, etc. to ensure data authenticity and integrity;

[0051] Record permission update and transfer logs: Ensure that all permission changes are well documented, providing transparency and traceability of the system;

[0052] Smart contracts: Dynamically adjust user permissions and signature thresholds through smart contracts, provide decentralized permission management functions, and adapt to different access requirements;

[0053] Context-aware mechanism: allows temporary lowering of signature thresholds in special emergency situations (such as first aid) to speed up data access and meet the needs of immediate response.

[0054] The distributed storage layer is mainly responsible for storing encrypted medical data. Its specific functions include:

[0055] Generate unique hash: Generate a unique hash value for each piece of data to locate and verify the data, ensuring its authenticity and integrity; hash linking enables data in the distributed storage system to match the metadata on the blockchain, ensuring that the data cannot be tampered with.

[0056] Efficient data distribution services: such as the distributed storage system IPFS, which provides decentralized storage and avoids direct storage of sensitive information, thereby ensuring data privacy and high availability.

[0057] The computing and encryption layer consists of a proxy re-encryption server and an authority center. Its specific responsibilities are:

[0058] Permission Center: Responsible for key generation, dynamic permission updates, and re-encryption key generation during permission transfer, ensuring the security and flexibility of permission management.

[0059] Proxy re-encryption server: The re-encryption mechanism is used to transfer data permissions, which can achieve dynamic management of permissions without re-encrypting or re-uploading data, thereby improving system efficiency.

[0060] Attribute key update algorithm: When user attributes change, only the changed attribute keys need to be updated, avoiding large-scale key regeneration and redistribution, and simplifying the key management process.

[0061] The application layer includes data owners (such as doctors) and users (such as doctors, nurses, or researchers). The specific operation process is as follows: the data owner is responsible for encrypting the data and uploading it to the storage system, while also recording the metadata on the blockchain to ensure data security and traceability. After the user verifies the permission through the access request, he can download the data from the storage system and decrypt it for access, meeting the needs of data privacy and dynamic permission control in medical scenarios.

[0062] The present invention makes the following improvements to the dynamic attribute-based multiple short signature encryption:

[0063] a) Efficient short signature BLS signature algorithm: Using a more efficient short signature BLS signature algorithm, combined with batch verification methods, significantly improves the efficiency of signature verification and reduces computational costs.

[0064] b) Dynamically adjust the signature threshold: Dynamically adjust the multi-signature threshold through smart contracts to ensure that different access needs match different authentication requirements. In particular, in an emergency, the threshold can be temporarily lowered to speed up data access.

[0065] c) Fine-grained key update mechanism: The attribute key update algorithm and proxy re-encryption algorithm are used to achieve more fine-grained key updates. Only the changed attribute keys need to be updated, thus avoiding large-scale key regeneration and redistribution.

[0066] Entity definition and workflow

[0067] By reference Figure 2 , defines the entities and workflow of the system. The entities include:

[0068] (1) Authority Center

[0069] Each authority center is fully trusted and is responsible for allocating and managing attributes related to itself. These can include hospital departments (such as internal medicine, surgery, and laboratories), insurance companies, research institutions, and so on. It is primarily responsible for initializing the system, setting system parameters, and generating master keys and public parameters. At the same time, it generates initial keys and update keys for users to ensure that each user has the necessary credentials to access the system. In addition, the authority center dynamically adjusts user access rights based on their roles and attributes to adapt to security requirements in different scenarios. Finally, when a doctor leaves or user attributes change, the authority center generates new keys or re-encryption keys to achieve a smooth transfer or update of permissions, ensuring the security and flexibility of the system.

[0070] (2) Data owner (such as a doctor)

[0071] Responsible for creating and encrypting patient medical record data, its main responsibilities include: encrypting sensitive data using a dynamic multi-short signature encryption algorithm to ensure data security during transmission and storage; generating signatures for the encrypted data to verify its authenticity and integrity; and finally, uploading the encrypted data to a distributed storage system and recording related metadata, such as data hashes and signatures, on the blockchain to ensure data traceability and immutability. Through these steps, data owners not only protect patient privacy but also lay a solid foundation for subsequent data access and permission management.

[0072] (3) Users (such as doctors, nurses, researchers)

[0073] Permissions are obtained by requesting access to specific data. Its main responsibilities include: initiating access requests, and the system verifying whether the permissions comply with the preset access policy through smart contracts; dynamically adjusting signature thresholds based on the attributes of different user roles to ensure flexible and secure permission management; and, in emergency situations, adjusting thresholds to allow users to quickly obtain access rights to meet the needs of immediate response. This mechanism not only ensures data security and privacy, but also provides efficient access control at critical moments, ensuring timeliness and accuracy in medical scenarios.

[0074] (4) Proxy re-encryption server

[0075] When a doctor leaves or user attributes are updated, the server is responsible for re-encrypting the data to support a smooth transfer of permissions. Its main responsibilities include: converting encrypted data based on the re-encryption key generated by the permission center, enabling the new data owner to decrypt the data without re-encrypting the data content, thereby ensuring the continuity and efficiency of the permission transfer. Furthermore, through this process, the proxy re-encryption server enables permission transfer without decrypting the data content, effectively protecting data privacy and preventing the leakage of sensitive information during the permission change process. This mechanism not only improves the system's flexibility and responsiveness, but also enhances data security and integrity.

[0076] (5) Smart Contracts

[0077] Deployed on the blockchain, it verifies user access requests and signatures. Its primary responsibilities include dynamically adjusting role signature thresholds and responding to emergencies to ensure flexible and secure access control in various scenarios. Furthermore, when data is uploaded and permissions are transferred, the smart contract stores relevant information (such as data hashes and permission change records) on the blockchain, ensuring the transparency, integrity, and immutability of data and permission records. In this way, smart contracts not only provide an efficient access verification mechanism, but also provide a solid foundation for system security and traceability.

[0078] (6) Blockchain

[0079] Responsible for recording key information such as data hashes, access logs, and permission changes, the blockchain ensures system transparency and traceability, ensuring that all data access and permission changes are recorded completely and immutably. Through its decentralized ledger mechanism, the blockchain prevents single points of failure and data tampering, enhancing the system's security and reliability. This design not only ensures transparency and integrity in medical data management, but also effectively prevents unauthorized modifications and potential security risks.

[0080] (7) Distributed Storage System

[0081] Responsible for storing encrypted medical record data, ensuring high availability and immutability. Its primary responsibilities include providing unique hash identifiers, enabling data to be linked and recorded on the blockchain, thereby supporting efficient data management and retrieval. Furthermore, by avoiding direct storage of sensitive information, the distributed storage system ensures data privacy and high availability, preventing data leaks and unauthorized access. This design not only enhances data security but also provides reliable technical support for the sharing and use of medical data.

[0082] The system can effectively resist common attacks such as unauthorized user requests, man-in-the-middle attacks, and signature tampering or forgery, ensuring the privacy and integrity of data. Specifically:

[0083] (1) Unauthorized user requests: The system detects and rejects all access requests from unauthorized users through the multi-signature verification mechanism of the smart contract, and records detailed logs to ensure that each access attempt is tracked and audited.

[0084] (2) Man-in-the-middle attack: A strong encryption mechanism is used during data transmission to ensure that attackers cannot decrypt the communication content; any tampering is detected by the integrity check mechanism, and the system refuses to process tampered data to ensure the authenticity and integrity of the data.

[0085] (3) Signature tampering or forgery: The system uses aggregate signatures and batch verification to successfully identify and reject all tampered and forged signatures, ensuring that only legitimate signatures can pass verification and preventing unauthorized access.

[0086] Example 2

[0087] This embodiment relates to a medical management method based on dynamic attribute multiple short signature encryption, such as Figure 4 The specific implementation process of this method includes:

[0088] 101. System initialization

[0089] Initial Setup (λ) → IP: The initial setup takes the security parameter λ as input and outputs the global public parameter IP, which provides a shared basis for multi-authority organizations. The global public parameter IP includes the elliptic curve generator g and the bilinear map e:G1×G2→G T . Output G1, G2 and G T They are all groups of order p, and the hash function H:{0,1} * →G1 system generates public parameters IP=(g,e,G1,G2,G T ).

[0090] 102.Key Generation

[0091] Authority Key Generation(IP,AT i )→PK i ,SK i : Authority center i initializes the public parameter IP and the attribute set AT it manages i Generate public key PK i and private key SK i ,in y i Is the private value of the authority center This ensures that each attribute is managed and encrypted by a unique authority.

[0092] The authority center i is the user's initial attribute version V i Distribute key pairs It is managed by the authority center i and used for data encryption, decryption and identity authentication. i is the user attribute set, and the version number V i =1.

[0093] 103. Data Encryption

[0094] Data Patient data M D and the data owner's (doctor's) private key The data owner (doctor) uses his own private key Patient data M D Encryption, generate encrypted data Ensure data privacy protection.

[0095] 104.Data Signature

[0096] Sign The data owner (doctor) uses his private key Generate a signature for encrypted data C Ensure data origin and integrity, and prevent data tampering during transmission and storage.

[0097] 105.Data storage and on-chain records

[0098] IPFS Upload and BC The data owner (doctor) will encrypt the data and signature Upload to the distributed storage system IPFS and generate data hash h IPFS , and record the data hash h on the blockchain IPFS and signature hash to ensure the uniqueness and non-tamperability of data.

[0099] 106. User Requests Access

[0100] Access Request(User, Access Metadata) → Request: The user generates an access request, which contains their identity information and access metadata so that the smart contract can confirm their access rights.

[0101] 107. User signature generation

[0102] Sign User generates a signature for the access request Ensure the authenticity and integrity of the request and prevent the request from being forged or tampered with.

[0103] 108. Smart contract verifies user request and signature

[0104] SC Verify Smart contracts use the user's public key Verify user signature Check whether the access metadata complies with the user's permissions and attributes to ensure that the request is legal and meets the permission requirements.

[0105] Batch Here are multiple signatures of the user and the corresponding public key set The authority center uses the batch signature (BLS) verification mechanism to verify multiple user attribute signatures, such as Figure 2 This method effectively reduces the computational overhead of verifying multiple signatures and is suitable for high-concurrency access scenarios.

[0106] For multiple attribute signatures {σ1,σ2,…,σ n} Perform batch verification, including:

[0107] Calculate each signature σ i The corresponding pairing value e(σ i ,g) and e(H(A i ),PK i ); verify e(σ i ,g)=e(H(A i ),PK i ) is true, if all signatures meet the requirements, the verification is successful, otherwise it is an error.

[0108] Enhance access control flexibility by adding a threshold-based multi-signature verification mechanism. This mechanism will dynamically adjust the signature threshold based on user role and appropriately lower the threshold in emergency situations to speed up access. Specifically, it includes:

[0109] 1071) Set the role adaptive threshold AdaptiveThresh(Role)→t Role

[0110] The system sets different signature thresholds t according to user roles (such as doctor, nurse, researcher) Role For example, the data owner (doctor) needs at least three valid signatures, while other roles (such as researchers) only need one signature.

[0111] 1072) Smart Contract Control SmartContract(t Role ,Access Request)→Result Validation

[0112] The smart contract in the blockchain dynamically adjusts the signature threshold t according to the role of the access request Role , and perform threshold verification, the verification result is Result Validation .

[0113] 1073) Emergency adjustment (EM,t Role )→t′ Role

[0114] In an emergency (such as an emergency), the smart contract can temporarily reduce the signature threshold to a temporary value t Role , to expedite emergency access.

[0115] The role-adaptive threshold mechanism enables flexible access control for different roles based on their data access rights. Smart contracts dynamically adjust signature thresholds based on the context to accommodate the access needs of different roles in the healthcare environment.

[0116] The signature verification threshold is dynamically adjusted according to the user's attributes and role to ensure that different user roles can access the corresponding data according to their permission level; and in an emergency, the smart contract can temporarily lower the signature verification threshold according to preset rules to speed up data access and meet the needs of immediate response; the smart contract can also automatically record the relevant change log when the permission changes, ensuring the transparency and traceability of permission management.

[0117] 109. Dynamic Property Update and Version Control (Permission Transfer)

[0118] Doctors are defined as data owners. If they leave their job, the patient data they are responsible for will face transfer issues. Therefore, to ensure the continued management of patient medical records and data security, it is necessary to design an efficient and secure processing mechanism to hand over or transfer the doctor's management rights over medical records. This mechanism, based on proxy re-encryption, transfers the rights to the new designated doctor (manager) when the doctor leaves, achieving a secure transfer of management rights.

[0119] Because proxy re-encryption allows for new data access permissions by updating only the key, rather than the entire encrypted data, this approach eliminates the need for large-scale re-encryption of stored data, reducing computational and storage overhead. Furthermore, permission transfer requires only a one-time re-encryption key update, resulting in high efficiency. With proxy re-encryption, the proxy server itself cannot access the original medical record data. The key update and re-encryption processes are independent of each other, ensuring data privacy is not compromised.

[0120] Proxy re-encryption implements the permission redistribution algorithm, such as Figure 3 , the specific implementation process:

[0121] 1091, Version Control (AT i ,V i )→V i+1 :When user attribute AT i When a change occurs, the authority center changes the attribute version number from V i Increment to V i+1 , ensure that user properties are consistent with the latest version.

[0122] 1092, Generate New The authority center is based on the user's attributes AT i and the new version number V i+1 Generate a new version of the key pair to ensure that the user's access rights match the new attributes, and the old version of the key becomes invalid.

[0123] 1093, Rekey The authority center generates a re-encryption key and the old private key and the new public key Input, output re-encryption key

[0124] 1094, Proxy The proxy re-encryption server uses the re-encryption key to encrypt the old version of the data Combined re-encryption key Convert to the new version Ensure that data access permissions match the latest properties.

[0125] 1095, Blockchain Update (Y i+1 ,h IPFS )→Updated Record: Record the user’s new attribute version number and data-associated hash h on the blockchain IPFS , ensuring traceability and transparency of permissions after changes.

[0126] 1096, Revoke Confirmation: The old version key Unregister to prevent the old key from continuing to access data outside the new attribute.

[0127] 1097, Access Verification (Updated Record, Blockchain Record) → GrantAccess: For new medical record data, the user initiates an access request to the blockchain. The system verifies the permission based on the blockchain record and grants access if it is passed. This ensures the continuity of data permissions and records each access event.

[0128] In the scenario of doctor resignation or authority transfer, the main workflow is as follows Figure 3 As shown, the following steps are included:

[0129] First, the authority center generates a re-encryption key And sent to the proxy re-encryption server.

[0130] Second, the proxy re-encryption server uses the key to re-encrypt the original encrypted data. Re-encrypt to generate new encrypted data And updated to the distributed storage system IPFS.

[0131] Finally, the blockchain records the new permission information and data hash h IPFS All data access and permission changes are recorded on the blockchain, ensuring system transparency and traceability. The distributed storage system stores all encrypted data, provides data location and distribution services, and works with the blockchain to ensure data privacy, security, and continuous management.

[0132] 110.Data Access and Decryption

[0133] Data Access (h IPFS )→C:Authorized users hash data h according to the blockchain record IPFS Locate and download encrypted data C to ensure secure access to the data.

[0134] Decryption and User uses private key Decrypt data C and sign it with the doctor Verify data integrity to ensure that the data content has not been tampered with.

[0135] 111. Logging and tracing

[0136] Log Transaction (User Access Event) → Blockchain Log: User access event. Log records on the blockchain ensure the transparency and traceability of each data access and prevent unauthorized operations.

[0137] This medical management solution, based on a dynamic attributed multiple short signature encryption scheme, implements a low-overhead, high-performance data access control and permission transfer mechanism, ensuring comprehensive performance in data privacy protection, dynamic permission management, role-adaptive control, and emergency response. Proxy re-encryption and blockchain records provide excellent support for continuous data management and permission transfer, meeting the high security and flexibility requirements of distributed data management systems.

[0138] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and such modifications or substitutions are intended to be within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. A medical management system based on dynamic attribute multiple short signature encryption, the system includes a blockchain layer, a distributed storage layer, a computing and encryption layer, and an application layer, characterized in that: The blockchain layer includes smart contracts, which dynamically adjust user permissions and signature thresholds through the smart contracts; the distributed storage layer includes a distributed storage system for storing encrypted medical data and generating a unique hash for locating and verifying data; the computing and encryption layer includes a proxy re-encryption server and multiple authority centers. The proxy re-encryption server transfers data permissions through a re-encryption mechanism, and the authority center is responsible for key generation, dynamic permission updates, and re-encryption key generation during permission transfer; the application layer includes data owners and users, and the data owners use a dynamic attribute multiple short signature encryption algorithm to encrypt sensitive medical data.

2. A medical management system based on dynamic attribute multiple short signature encryption according to claim 1, characterized in that: The authority center is responsible for initializing the system, setting system parameters and generating master keys and public parameters; the authority center generates initial keys and update keys for users.

3. A medical management system based on dynamic attribute multiple short signature encryption according to claim 1, characterized in that: The authority center dynamically adjusts the user's access rights according to the user's role and attributes. When the data owner changes or the user's attributes change, only the changed attribute key is updated and a new key or re-encryption key is generated.

4. A medical management system based on dynamic attribute multiple short signature encryption according to claim 1, characterized in that: The data owner is responsible for creating and encrypting patient medical record data, encrypting sensitive data using a dynamic attribute multi-short signature encryption algorithm, generating a signature for the encrypted data, uploading the encrypted data to a distributed storage system, and recording relevant metadata on the blockchain.

5. A medical management system based on dynamic attribute multiple short signature encryption according to claim 1, characterized in that: The data owner encrypts the patient data using a private key to generate encrypted data; The data owner generates a signature for the encrypted data using a private key; The data owner uploads the encrypted data and signature to the distributed storage system of the distributed storage layer, generates a data hash, and records the data hash and signature hash on the blockchain.

6. A medical management system based on dynamic attribute multiple short signature encryption according to claim 1, characterized in that: When a user initiates an access request, the smart contract verifies whether the user's permissions comply with the preset access policy. If so, the verification passes; otherwise, the verification fails. Set different signature thresholds based on user attributes and dynamically adjust the signature thresholds based on access requests; The smart contract dynamically adjusts the signature threshold based on the scenario, including in emergency situations, where the system accelerates access control by appropriately lowering the signature threshold.

7. A medical management system based on dynamic attribute multiple short signature encryption according to claim 1, characterized in that: The permission transfer is implemented based on the proxy re-encryption mechanism, and the process includes: 1091, when user attributes are changed, the authority center will update the attribute version number to the new attribute version number to ensure that the user attributes are consistent with the latest version; 1092, the authority center generates a new version key pair based on the user attributes and the new version number, namely, a new private key and a new public key; 1093, the authority center generates a re-encryption key: inputs the old private key and the new public key, and outputs the re-encryption key; 1094, the proxy re-encryption server uses the re-encryption key to convert the old version of encrypted data into the new version of encrypted data; 1095, record the user's new attribute version number and data associated hash on the blockchain; 1096, cancel the old version key.

8. A method for a medical management system based on dynamic attribute multiple short signature encryption using any one of claims 1 to 7, characterized in that: The method comprises: System initialization: takes security parameters as input and outputs global public parameters; Key generation: Authority center i generates keys based on the initialized public parameters and the attribute set AT it manages. i Generate public key PK i and private key SK i ; Authority center i is the user's initial attribute version V i Distribute key pairs And it is managed by the authority center i, where is the private key, is the public key; Data encryption and signature: The data owner uses his own private key Patient data M D Encryption, generate encrypted data The data owner uses the private key Generate doctor's signature for encrypted data C Data storage and on-chain records: Data owners will encrypt data and signature Upload to the distributed storage system, generate data hash, and record the data hash and signature hash on the blockchain; User access request and user signature: The user generates an access request and generates a user signature for the access request; Smart contract verifies user request and user signature: The smart contract verifies the user signature using the user's public key and checks whether the access metadata complies with the user's permissions and attributes; Data access and decryption: If the smart contract verification is successful, the authorized user locates and downloads the encrypted data based on the data hash recorded on the blockchain. The user uses the private key to decrypt the data and verifies the data integrity through the doctor's signature.

9. The method according to claim 8, characterized in that The method further includes permission transfer: when the data owner changes, updating the key based on a proxy re-encryption mechanism; Use batch signature verification mechanism to verify multiple signature sets and corresponding public key sets of users.

10. The method according to claim 8, characterized in that The smart contract sets different signature thresholds based on user attributes and dynamically adjusts the signature thresholds based on access requests; The smart contract dynamically adjusts the signature threshold based on the scenario, including in emergency situations, where the system accelerates access control by appropriately lowering the signature threshold.

Images