Block chain encryption-based remains donation information security registration device

Abstract

The invention relates to the field of cross application of information security and block chain technology, and discloses a block chain encryption-based remains donation information security registration device, which comprises a bracket, a touch screen is mounted on a display surface of the bracket, a lithium battery is mounted at the bottom in the bracket, a cooling fan is mounted in the bracket, and the cooling fan is connected with the display surface of the bracket. A system box is installed in the middle of the inner end of the support, the lithium battery is electrically connected with the cooling fan, the system box and the touch screen and used for providing a power source, and a processing system is installed in the system box and electrically connected with the touch screen; the processing system comprises an information acquisition and encryption module which is used for receiving identity information and donation willingness content submitted by a remains donator. According to the method, the access control strategy structure body is constructed, and the access control strategy structure body and the encrypted data identifier are jointly subjected to structured coding and Hash binding, so that the inseparable binding of the authority information and the data body is realized, and the security and consistency of access control are improved.

Description

Technical Field

[0001] The present invention relates to the cross-application field of information security and blockchain technology, and specifically to a body donation information security registration device based on blockchain encryption. Background Art

[0002] The body donation system embodies the dignity of life and scientific ethics of modern civilized society. It not only provides crucial support for medical education and clinical research, but also demonstrates an individual's dedication to the public good. In my country, with the gradual shift in social attitudes and the continued advancement of policy advocacy, an increasing number of citizens are expressing their willingness to voluntarily donate their bodies before death. The registration, storage, and subsequent management of these wishes have become a crucial, yet highly sensitive, component of the public health system.

[0003] To improve registration efficiency and facilitate information management, some local governments have explored establishing online body donation registration platforms based on information technology. These platforms are typically led by hospitals, the Red Cross, civil affairs departments, or third-party nonprofit organizations, and operate through a variety of modes, including web-based submission, mobile authentication, and local database storage. However, despite continuous technological advancements, existing registration platforms still face an irreconcilable conflict between technical security and data credibility.

[0004] First, most existing systems utilize a centralized database structure. Once user-submitted information is entered, it is stored internally on the server in plaintext or weakly encrypted form. This approach may be acceptable in the early stages of deployment or for small-scale use. However, as data volumes grow, the system can be compromised or the backend illegally accessed, exposing user privacy, such as user wishes and identities, to significant risks. This is especially true in specialized scenarios involving the identification of deceased individuals or medical purposes, where the sensitivity of the information far exceeds that of ordinary civil data. Existing data isolation mechanisms are clearly insufficient.

[0005] Furthermore, traditional systems often rely on "role binding + interface judgment" for permission control, lacking the ability to express structural permissions. For example, some platforms determine access capabilities solely based on login identity, without providing a detailed "role-behavior-target data" control structure. Once permissions are misconfigured, unauthorized actions such as "reading more than one item" or "changing more than one item" are highly likely to occur, making it difficult to trace accountability afterward. Summary of the Invention

[0006] In response to the shortcomings of the existing technology, the present invention provides a body donation information security registration device based on blockchain encryption, which solves the problems of insufficient user privacy protection, inaccurate access control, difficult to trace data tampering, and inability to dynamically update permissions in the existing body donation registration system.

[0007] To achieve the above objectives, the present invention is implemented through the following technical solutions: a body donation information security registration device based on blockchain encryption, comprising a bracket, a display surface of the bracket is equipped with a touch screen, a lithium battery is installed at the bottom of the inner part of the bracket, a cooling fan is installed inside the bracket, and a system box is installed at the middle part of the inner end of the bracket, the lithium battery is electrically connected to the cooling fan, the system box and the touch screen respectively for providing power, and a processing system is installed inside the system box and is electrically connected to the touch screen.

[0008] Preferably, the processing system comprises:

[0009] The information collection and encryption module is used to receive the identity information and donation intention content submitted by the body donor, encrypt the donation intention content, and generate encrypted data content, a unique data identifier and a data content hash value;

[0010] An authority level marking module is used to set an access permission level for the encrypted data according to the sensitivity of the encrypted data;

[0011] An authority structure generation module is used to generate a corresponding access control policy structure based on the access authority level, and the structure includes at least one set of pairing information between roles and corresponding access operations;

[0012] The permission hash binding module is used to uniformly encode the encrypted data identifier and the access control policy structure, calculate the permission hash value, and bind the permission hash value to the encrypted data and write it into the blockchain;

[0013] The smart contract permission verification module is used to verify whether the access party's role level meets the access permission level when an external access request arrives, and to determine whether the permission structure submitted by the request is consistent with the permission hash value bound on the chain to decide whether to release the access request;

[0014] The access behavior log recording module is used to generate access behavior log records after the access request is processed, and record the visitor identity, data number, operation type, timestamp and access status on the chain;

[0015] The permission dynamic update module is used to re-encode the new structure and generate a new permission hash value to replace the original permission hash value on the chain when the access control policy structure changes.

[0016] A method for securely registering body donation information based on blockchain encryption, comprising the following steps:

[0017] S1. Receive the identity information and donation intention submitted by the body donor through the touch screen, transmit it to the processing system in the system box, encrypt the donation intention content, and generate encrypted data content, data identifier and data hash value;

[0018] S2. assigning an access permission level to the encrypted data according to its privacy level;

[0019] S3. Determine an access control policy structure based on the access permission level, wherein the structure includes a mapping relationship between roles and operations;

[0020] S4. Combine and encode the data identifier and the access control policy structure to generate a permission hash value, and write the permission hash value and the data record into the blockchain;

[0021] S5. When an access request arrives, extract the role level information of the requester and compare it with the data access level;

[0022] S6. Encode the permission structure submitted in the access request, generate the current permission hash value, and compare it with the permission hash value bound in the blockchain;

[0023] S7. If the level requirements are met and the hashes are consistent, access is allowed; otherwise, access is denied.

[0024] S8. Record access behavior to generate log data and write the access record into the blockchain.

[0025] Preferably, the S3 access control policy structure includes at least one set of ordered key-value pairs consisting of role identifiers and their corresponding access operations. The structure can be processed by a hash function after being encoded according to a preset field order and used for subsequent permission consistency verification.

[0026] Preferably, the generation of the S4 permission hash value includes the following steps:

[0027] S41. Combining the encrypted data identifier and the access control policy structure into a structure string;

[0028] S42. Use a hash function to perform an irreversible encryption operation on the structured character string to generate a hash digest value of a fixed length as a permission binding value;

[0029] S43. Bind the permission binding value to the corresponding data record structure and store it in the blockchain.

[0030] Preferably, S5 compares the role level information bound to the identity address of the accessing party with the access level value stored in the data record, and if the former is not lower than the latter, the access is allowed to proceed to S6.

[0031] Preferably, the S6 includes:

[0032] S61. Structurally encode the permission structure submitted by the visitor according to the system standard field sequence;

[0033] S62. Perform hash calculation on the encoding result to obtain the current permission hash value;

[0034] S63. Compare the current permission hash value with the binding hash value in the on-chain data record. If they are consistent, verification is passed; otherwise, access is denied.

[0035] Preferably, the step S8 includes constructing a log structure of the following fields: visitor address, request data identifier, access operation type, operation timestamp, and permission verification result status.

[0036] Preferably, after the access control policy structure is updated, S8 performs the following operations:

[0037] S81. Encode the new structure in the order of system fields;

[0038] S82. Recalculate the corresponding permission hash value;

[0039] S83. Write the new permission hash value into the blockchain in the form of a transaction and replace the original hash field.

[0040] S84. The old structure permission request is rejected during the permission hash verification phase.

[0041] Preferably, the log structure is written into the blockchain log chain area after structured encapsulation, and is provided with an access index for subsequent regulatory node calls and inquiries.

[0042] The present invention provides a secure registration device for body donation information based on blockchain encryption. It has the following beneficial effects:

[0043] 1. This invention constructs an access control policy structure and combines it with encrypted data identifiers through structured encoding and hash binding, thereby achieving inseparable binding of permission information and data, improving the security and consistency of access control. Compared with existing solutions that store permission control information and data separately, this effectively overcomes the access control failure problem caused by permission synchronization delays or tampering.

[0044] 2. This invention introduces a role-level permission determination mechanism. By binding the accessor's identity address to their permission level and dynamically comparing access levels, it prevents unauthorized access from occurring at the source. Existing technologies often rely on hard-coded role determination or static permission configuration, making it difficult to flexibly adapt to complex access control requirements. This invention significantly improves the precision and dynamic responsiveness of system permission management.

[0045] 3. This invention uses a standard field order for structure encoding and a hash comparison mechanism to verify the legitimacy of the access permission structure, ensuring accurate and tamper-resistant access control. Compared to existing authorization methods based solely on access tokens or identity tags, this effectively addresses the issues of access permission forgery and false authorization.

[0046] 4. This invention supports dynamic on-chain updates of access control policy structures, replacing the original hash value with the updated permission hash. This enables real-time effectiveness of permission changes and automatic expiration of old permissions, ensuring the timeliness and closed-loop nature of the system's access control policies. Compared to existing approaches that rely on manual administrator revocation or periodic synchronization mechanisms, this approach addresses system security risks caused by redundant permissions and lagging control. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 A perspective view of the present invention;

[0048] Figure 2 This is an exploded schematic diagram of the support structure of the present invention;

[0049] Figure 3 Schematic diagram of the system module architecture of the present invention;

[0050] Figure 4 Schematic diagram of the method steps of the present invention.

[0051] Among them, 1. bracket; 2. touch screen; 3. lithium battery; 4. cooling fan; 5. system box. DETAILED DESCRIPTION

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

[0053] Please see the attached Figure 1 -Attached Figure 2 An embodiment of the present invention provides a body donation information security registration device based on blockchain encryption, including a bracket 1, a display surface of the bracket 1 is equipped with a touch screen 2, a lithium battery 3 is installed at the bottom of the inner part of the bracket 1, a cooling fan 4 is installed inside the bracket 1, and a system box 5 is installed at the middle of the inner end of the bracket 1. The lithium battery 3 is electrically connected to the cooling fan 4, the system box 5 and the touch screen 2 respectively to provide power. A processing system is installed inside the system box 5 and is electrically connected to the touch screen 2.

[0054] Specifically, the device includes a bracket 1, which supports the entire hardware structure and provides a fixed mounting location. Made of metal alloy or flame-retardant ABS plastic, it offers excellent stability and impact resistance. A touch screen 2, measuring 10 to 15 inches and featuring capacitive multi-touch functionality, is mounted on the front of the device. Users can perform interactive operations such as entering donor identity information and signing their consent directly on the screen.

[0055] A lithium battery 3 is installed at the bottom of the bracket 1. This embodiment uses an integrated high-density lithium polymer battery with stable output and functions such as short-circuit protection and temperature control protection to ensure the stable battery life of the device in outdoor or temporary control scenarios.

[0056] To prevent heat buildup during extended operation, a cooling fan 4 is installed inside bracket 1. This low-noise DC turbofan is dynamically activated and deactivated by a temperature control chip. Heat is transferred through thermal columns and guide vanes in system box 5, effectively keeping the system temperature rise below 45°C, ensuring continuous operation even in high-temperature environments.

[0057] A system box 5 is mounted at the inner end of bracket 1. Its outer shell is made of anodized aluminum alloy and houses the core processing system, including a main control board (which may be based on an ARM architecture), a blockchain encryption module, and a security encryption chip. System box 5 is connected to touch screen 2, the power supply system, and the electronically controlled fan via a cable, forming a closed loop.

[0058] During the user information collection process, the device's touchscreen display interface features a modular layout, including an identity entry area, a fingerprint / face verification interface, and a section for electronic signature of the letter of intent. All interactive operations trigger the generation of a local event log, which is then written to the on-chain log area via a log structure (including operator identification, timestamp, and operation type), forming a complete audit chain.

[0059] In this design, the power system automatically distributes current to each module through an independent power management chip, ensuring power priority: touch screen 2 > system box > cooling fan 4. If the device is idle for a set time (e.g., 5 minutes), it automatically triggers low-power mode, maintaining only background monitoring and link keepalives, minimizing energy consumption.

[0060] Please see the attached Figure 3 , the processing system includes:

[0061] The information collection and encryption module is used to receive the identity information and donation intention content submitted by the body donor, encrypt the donation intention content, and generate encrypted data content, a unique data identifier and a data content hash value;

[0062] The permission level marking module is used to set the access permission level for encrypted data according to the sensitivity of the encrypted data;

[0063] An authority structure generation module is used to generate a corresponding access control policy structure based on the access authority level, and the structure includes at least one set of pairing information between roles and corresponding access operations;

[0064] The permission hash binding module is used to uniformly encode the encrypted data identifier and access control policy structure, calculate the permission hash value, and bind the permission hash value to the encrypted data and write it into the blockchain;

[0065] The smart contract permission verification module is used to verify whether the access party's role level meets the access permission level when an external access request arrives, and to determine whether the permission structure submitted by the request is consistent with the permission hash value bound on the chain to decide whether to release the access request;

[0066] The access behavior log recording module is used to generate access behavior log records after the access request is processed, and record the visitor identity, data number, operation type, timestamp and access status on the chain;

[0067] The permission dynamic update module is used to re-encode the new structure and generate a new permission hash value to replace the original permission hash value on the chain when the access control policy structure changes.

[0068] Specifically, the processing system is integrated into the system box of the body donation information security registration device, serving as the device's core control unit. Its primary functions include receiving user information, encrypting and encapsulating it, setting permissions, binding it to the blockchain, verifying access, and logging it, forming a closed loop for secure data transfer.

[0069] When a user submits a registration application through the device's touchscreen, the system first initiates a front-end information collection program to receive and standardize the user's input identity information and donation intention. The system performs format verification on the collected identity fields (such as name and ID number) and the terms of intention (such as the type of donation agreed to, the authorized person, etc.), and then calls a local encryption algorithm to encrypt and encapsulate the core content. The national encryption SM4 algorithm is preferably used to encrypt the donation intention text. The encryption process is completed locally on the chip to prevent the transmission of plain text on the network and improve the level of information security.

[0070] After encryption, the system generates a corresponding unique data identifier, which can be constructed based on the donor's identity hash and timestamp for subsequent data location. The system also calculates a hash digest value for the encrypted content, such as using the SM3 algorithm. The generated hash value is used for both integrity verification and as a benchmark for permission binding.

[0071] After encryption is complete, the system automatically determines the access level based on the data's sensitivity. This level is determined by a pre-defined criteria within the platform, with different data categories assigned varying levels of access control. For example, public donation statements might be assigned a basic level, while content containing identity or medical records might be assigned a higher level. This level information drives the logic behind the permissions structure.

[0072] The permissions structure consists of one or more access roles and their corresponding operational permissions. A typical structure might include medical personnel with read permissions, family members with query and signature permissions, and administrative agencies with audit and tracking permissions. The system uses a standard field format to construct the access control policy structure. The structure's encoding order is fixed to ensure stable and unique hash calculation results.

[0073] After the structure is constructed, the processing system packages it with the corresponding encrypted data identifier, processes it through a structure encoding algorithm (such as Base64 or a fixed-length field sequence), and calculates a permission hash value for the encoded result. This permission hash serves as a summary of the permission structure and is written to the blockchain platform along with the encrypted data content, thus binding the data and access rules to the blockchain. The written content includes the data identifier, encrypted data body, permission level, and permission hash value, forming a complete registration record on the blockchain.

[0074] When an external access request is triggered, the system automatically verifies access qualifications based on the on-chain smart contract mechanism. First, the accessor's role level is queried based on the identity address provided. This role level is then compared with the access rights level preset in the target data record. If the authorization requirements are met, the permission structure submitted in the access request is extracted, encoded and hashed, and compared with the original permission hash value on the chain. Only when both the role level and the permission structure are consistent will the smart contract grant the data access request.

[0075] After each access request is processed, regardless of whether the access result is successful or denied, the system automatically generates a log record of the access behavior. This log structure includes the visitor's identity (encrypted or hashed), the data number, the operation type (such as read, write, attempted modification), the request timestamp, and the access result status code. The access log is encapsulated by the system according to the on-chain log specification and written to the blockchain log area, ensuring that the access behavior has auditable basis and cannot be tampered with or deleted later.

[0076] If the system detects that the access control policy needs to be adjusted (for example, a user adds an authorized role or an organization's permissions are revoked), the processing system will rebuild a new access control structure and calculate a new permission hash value based on it. The system uses an on-chain permission field replacement mechanism to replace the original permission hash value with the new value, thereby achieving dynamic changes in the permission policy. The original structure automatically becomes invalid due to the hash mismatch, eliminating the need for a separate revocation operation, effectively preventing the old authorization path from being used again.

[0077] Please see the attached Figure 4 , a method for secure registration of body donation information based on blockchain encryption, comprising the following steps:

[0078] S1, receiving the identity information and donation intention content submitted by the body donor through the touch screen 2, transmitting it to the processing system in the system box 5, encrypting the donation intention content, and generating encrypted data content, data identification and data hash value;

[0079] Specifically, the registration device's touchscreen interface receives user-entered identity information and donation intentions, including but not limited to name, ID number, contact information, declaration of intention, and authorization information. After transmitting this information to the processing system within the system box, the system first performs symmetric encryption on the "donation intention," preferably using the SM4 algorithm. A unique data identifier (e.g., in the form of a UUID) and a cryptographic digest hash (e.g., SHA-256 or SM3 algorithm) are simultaneously generated locally for subsequent identification indexing and integrity verification.

[0080] The purpose of this step is to ensure that the information is encrypted and encapsulated before being stored in the blockchain, so that no node can read its original plaintext, thereby enhancing the confidentiality of the information.

[0081] The code is:

[0082] importuuid,hashlib

[0083] fromCrypto.CipherimportAES

[0084] defencrypt_data(plain_text:str,key:bytes)->dict:

[0085] cipher=AES.new(key,AES.MODE_ECB)

[0086] padded = plain_text.ljust(32) # Simplified filling

[0087] encrypted=cipher.encrypt(padded.encode())

[0088] data_id = str(uuid.uuid4())

[0089] data_hash=hashlib.sha256(encrypted).hexdigest()

[0090] return {

[0091] "data_id":data_id,

[0092] "encrypted_data":encrypted.hex(),

[0093] "data_hash":data_hash

[0094] }

[0095] S2. assigning access rights to the encrypted data according to its privacy level;

[0096] Specifically, the processing system analyzes the sensitivity of the encrypted data and configures access rights based on a pre-set level model. Different levels correspond to the minimum threshold for access roles. For example:

[0097] Level 1: General disclosure (e.g., only expressing willingness)

[0098] Level 2: Authorized access (including identity + authorization letter)

[0099] Level 3: Strictly controlled content (medical assessment, matching donation records, etc.)

[0100] The result of the level setting will be written into the chain along with the data for subsequent access authority comparison.

[0101] S3. Determine an access control policy structure based on the access permission level. The structure includes a mapping relationship between roles and operations. The access control policy structure includes at least one set of ordered key-value pairs consisting of role identifiers and their corresponding access operations. The structure can be processed by a hash function after being encoded in a preset field order and used for subsequent permission consistency verification.

[0102] Specifically, the processing system automatically constructs an access control structure from a preset policy template based on the permission level. This structure is an ordered key-value pair containing the role name and the type of operation allowed. The structure is well-defined and the field order is fixed, which helps ensure the uniqueness and consistency of the hash calculation results. The structure can be referenced:

[0103] {

[0104] "relative":["read"],

[0105] "doctor":["read","comment"],

[0106] "admin":["read","modify","audit"]

[0107] }

[0108] The code is:

[0109] importjson

[0110] defgenerate_access_policy(level:int)->dict:

[0111] policies={

[0112] 1:{"relative":["read"]},

[0113] 2:{"doctor":["read"],"relative":["read"]},

[0114] 3:{"admin":["read","modify","audit"]}

[0115] }

[0116] returnpolicies.get(level,{})

[0117] defencode_policy(policy:dict)->str:

[0118] returnjson.dumps(policy,sort_keys=True)

[0119] S4. Combine and encode the data identifier and the access control policy structure to generate a permission hash value, and write the permission hash value and the data record into the blockchain. The generation of the permission hash value includes the following steps:

[0120] S41. Combining the encrypted data identifier and the access control policy structure into a structure string;

[0121] S42. Use a hash function to perform an irreversible encryption operation on the structured string to generate a hash digest value of fixed length as the permission binding value;

[0122] S43. Bind the permission binding value to the corresponding data record structure and store it in the blockchain.

[0123] Specifically, the data identifier and the policy structure are combined and encoded to generate a unified structure string, which is then processed using a hash function to obtain the permission hash value. This hash value is written into the blockchain along with the encrypted data and becomes the key credential for subsequent permission consistency verification.

[0124] The specific operations of S41–S43 are as follows:

[0125] S41: Splicing data identification and structure encoding

[0126] S42: Calculate permission binding hash

[0127] S43: Build and submit on-chain data structure

[0128] The code is:

[0129] defcompute_perm_hash(data_id:str,encoded_pol icy:str)->str:

[0130] combined=data_id+encoded_pol icy

[0131] returnhashlib.sha256(combined.encode()).hexdigest()

[0132] defbuild_blockchain_record(data_id,encrypted_data,data_hash,perm_hash):

[0133] return {

[0134] "data_id":data_id,

[0135] "cipher":encrypted_data,

[0136] "data_hash":data_hash,

[0137] "perm_hash":perm_hash

[0138] }

[0139] S5. When an access request arrives, the role level information of the requester is extracted and compared with the data access level; the role level information bound to the accessor's identity address is compared with the access level value stored in the data record. If the former is not lower than the latter, entry into S6 is allowed.

[0140] Specifically, when an external access request arrives, the system analyzes the visitor's identity, extracts their role level information, and compares it with the access level value in the data record. If the visitor's permission level is not lower than the target data requirement, the system proceeds to the next stage of verification.

[0141] defis_level_sufficient(visitor_level:int,required_level:int)->bool:

[0142] returnvisitor_level>=required_level

[0143] S6. Encode the permission structure submitted in the access request, generate the current permission hash value, and compare it with the permission hash value bound in the blockchain; including:

[0144] S61. Structurally encode the permission structure submitted by the visitor according to the system standard field sequence;

[0145] S62. Perform hash calculation on the encoding result to obtain the current permission hash value;

[0146] S63. Compare the current permission hash value with the binding hash value in the on-chain data record. If they are consistent, verification is passed; otherwise, access is denied.

[0147] Specifically, the visitor needs to submit a permission structure that matches their identity. The system encodes the standard field sequence of the structure, generates a hash value for the requested permission, and compares it with the permission hash value stored on the chain. If they match, the permission structure is considered valid.

[0148] include:

[0149] S61: Structure Encoding

[0150] S62: Request hash generation

[0151] S63: Compare with the original hash value on the chain

[0152] defvalidate_policy_structure(submitted:dict,chain_hash:str,data_id:str)->bool:

[0153] encoded=encode_policy(submitted)

[0154] local_hash=compute_perm_hash(data_id,encoded)

[0155] returnlocal_hash==chain_hash

[0156] S7. If the level requirements are met and the hashes are consistent, access is allowed; otherwise, access is denied.

[0157] Specifically, the system allows access only when both the level check and the structure consistency check pass; otherwise, the access is automatically denied and the reason for the failure is output.

[0158] defprocess_request(visitor_level,required_level,submitted_policy,chain_hash,data_id):

[0159] ifnotis_level_sufficient(visitor_level,required_level):

[0160] return "Accessdenied:insufficientlevel"

[0161] ifnotvalidate_policy_structure(submitted_policy,chain_hash,data_id):

[0162] return "Accessdenied:inval idstructure"

[0163] return "Accessgranted"

[0164] S8. Record access behavior to generate log data and write the access record into the blockchain, including constructing a log structure with the following fields: visitor address, request data identifier, access operation type, operation timestamp, and permission verification result status.

[0165] After the access control policy structure is updated, S8 performs the following operations:

[0166] S81. Encode the new structure in the order of system fields;

[0167] S82. Recalculate the corresponding permission hash value;

[0168] S83. Write the new permission hash value into the blockchain in the form of a transaction and replace the original hash field.

[0169] S84. The old structure permission request is rejected during the permission hash verification phase.

[0170] Specifically, every access operation is automatically recorded by the processing system. Record fields include: accessor ID, target data ID, access action, timestamp, and final judgment result. This log information is written to the blockchain audit chain for subsequent accountability and regulatory review.

[0171] importtime

[0172] defrecord_access_log(visitor_id,data_id,action,result):

[0173] log={

[0174] "visitor":visitor_id,

[0175] "data_id":data_id,

[0176] "action":action,

[0177] "timestamp":int(time.time()),

[0178] "result":result

[0179] }

[0180] write_to_blockchain("access_log",log)

[0181] If the data permission policy changes (such as adding new roles or tightening permissions), the system reconstructs the structure and calculates the new permission hash, replacing the original field on the chain. The old permission structure will no longer pass the hash check, and the old permissions will automatically become invalid.

[0182] defupdate_permission_structure(data_id,new_policy:dict):

[0183] encoded=encode_policy(new_pol icy)

[0184] new_hash=compute_perm_hash(data_id,encoded)

[0185] update_chain(data_id,field="perm_hash",value=new_hash)

[0186] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A body donation information security registration device based on blockchain encryption, comprising a bracket (1), characterized in that: The display surface of the bracket (1) is installed with a touch screen (2), the bottom of the bracket (1) is installed with a lithium battery (3), the interior of the bracket (1) is installed with a cooling fan (4), the interior of the bracket (1) is installed with a system box (5), the middle of the inner end of the bracket (1) is installed with the lithium battery (3), the cooling fan (4), the system box (5) and the touch screen (2) are respectively electrically connected to provide power, and the interior of the system box (5) is installed with a processing system and is electrically connected to the touch screen (2).

2. The body donation information security registration device based on blockchain encryption according to claim 1 is characterized by: The processing system comprises: The information collection and encryption module is used to receive the identity information and donation intention content submitted by the body donor, encrypt the donation intention content, and generate encrypted data content, a unique data identifier and a data content hash value; An authority level marking module is used to set an access permission level for the encrypted data according to the sensitivity of the encrypted data; An authority structure generation module is used to generate a corresponding access control policy structure based on the access authority level, and the structure includes at least one set of pairing information between roles and corresponding access operations; The permission hash binding module is used to uniformly encode the encrypted data identifier and the access control policy structure, calculate the permission hash value, and bind the permission hash value to the encrypted data and write it into the blockchain; The smart contract permission verification module is used to verify whether the access party's role level meets the access permission level when an external access request arrives, and to determine whether the permission structure submitted by the request is consistent with the permission hash value bound on the chain to decide whether to release the access request; The access behavior log recording module is used to generate access behavior log records after the access request is processed, and record the visitor identity, data number, operation type, timestamp and access status on the chain; The permission dynamic update module is used to re-encode the new structure and generate a new permission hash value to replace the original permission hash value on the chain when the access control policy structure changes.

3. A method for secure registration of body donation information based on blockchain encryption, according to the device for secure registration of body donation information based on blockchain encryption according to any one of claims 1-2, characterized in that: The following steps are involved: S1, receiving the identity information and donation intention content submitted by the body donor through the touch screen (2), transmitting it to the processing system in the system box (5), encrypting the donation intention content, and generating encrypted data content, data identification and data hash value; S2. assigning an access permission level to the encrypted data according to its privacy level; S3. Determine an access control policy structure based on the access permission level, wherein the structure includes a mapping relationship between roles and operations; S4. Combine and encode the data identifier and the access control policy structure to generate a permission hash value, and write the permission hash value and the data record into the blockchain; S5. When an access request arrives, extract the role level information of the requester and compare it with the data access level; S6. Encode the permission structure submitted in the access request, generate the current permission hash value, and compare it with the permission hash value bound in the blockchain; S7. If the level requirements are met and the hashes are consistent, access is allowed; otherwise, access is denied. S8. Record access behavior to generate log data and write the access record into the blockchain.

4. The method for secure registration of body donation information based on blockchain encryption according to claim 3, characterized in that: The S3 access control policy structure includes at least one set of ordered key-value pairs consisting of role identifiers and their corresponding access operations. The structure can be processed by a hash function after being encoded according to a preset field order and used for subsequent permission consistency verification.

5. The method for secure registration of body donation information based on blockchain encryption according to claim 3, characterized in that: The generation of the S4 permission hash value includes the following steps: S41. Combining the encrypted data identifier and the access control policy structure into a structure string; S42. Use a hash function to perform an irreversible encryption operation on the structured character string to generate a hash digest value of a fixed length as a permission binding value; S43. Bind the permission binding value to the corresponding data record structure and store it in the blockchain.

6. The method for secure registration of body donation information based on blockchain encryption according to claim 3, characterized in that: The step S5 compares the role level information bound to the identity address of the accessing party with the access level value stored in the data record. If the former is not lower than the latter, the accessing party is allowed to enter S6.

7. The method for secure registration of body donation information based on blockchain encryption according to claim 3, characterized in that: The S6 includes: S61. Structurally encode the permission structure submitted by the visitor according to the system standard field sequence; S62. Perform hash calculation on the encoding result to obtain the current permission hash value; S63. Compare the current permission hash value with the binding hash value in the on-chain data record. If they are consistent, verification is passed; otherwise, access is denied.

8. The method for secure registration of body donation information based on blockchain encryption according to claim 3, characterized in that: The S8 includes constructing a log structure with the following fields: visitor address, request data identifier, access operation type, operation timestamp, and permission verification result status.

9. The method for secure registration of body donation information based on blockchain encryption according to claim 3, characterized in that: After the access control policy structure is updated, S8 performs the following operations: S81. Encode the new structure in the order of system fields; S82. Recalculate the corresponding permission hash value; S83. Write the new permission hash value into the blockchain in the form of a transaction and replace the original hash field. S84. The old structure permission request is rejected during the permission hash verification phase.

10. The method for secure registration of body donation information based on blockchain encryption according to claim 8, characterized in that: The log structure is written into the blockchain log chain area after structured encapsulation, and is provided with an access index for subsequent regulatory node calls and queries.

Images