Attribute-based encryption method and system for layered data access control in internet of things

Abstract

The application relates to the technical field of digital information transmission and discloses an Internet of Things hierarchical data access control method and system based on attribute-based encryption. The method first collects attribute registration information of terminals at each level, completes attribute marking and coding, and constructs an attribute domain partition prefix tree; after receiving an access request, target level and requester attribute sets are extracted, directional retrieval is performed based on the prefix tree, a candidate attribute matching path set is obtained, and a strategy matching sparse bit vector table is constructed; local strategy verification is performed based on the table, a linear secret sharing matrix is calculated to determine a reconstruction result, and a level decryption delegation token is generated; the target level terminal completes lightweight final decryption according to the token, and updates a local cache and a session state. Through hierarchical attribute domain clipping and local strategy verification, the application reduces redundant calculation of attribute retrieval and strategy matching, reduces terminal decryption response delay, and realizes efficient and safe control of data access under a hierarchical architecture.

Description

Technical Field

[0001] This invention relates to the field of digital information transmission technology, and in particular to a method and system for layered data access control in the Internet of Things based on attribute-based encryption. Background Technology

[0002] The medical Internet of Things (IoT) adopts a layered architecture to realize data collection, transmission, and application. The perception layer deploys terminal devices to collect physiological parameters, the data layer stores medical data, and the application layer provides diagnostic and treatment services. Attribute-based encryption technology is used for access control. By associating access policies with user attributes, it realizes attribute-based permission verification and supports fine-grained access management in multi-terminal distributed access scenarios.

[0003] During system debugging, it was discovered that decryption response time is prolonged when multiple terminals concurrently access the data layer. For example, in emergency scenarios, real-time heart rate data uploaded by monitor terminals needs to be decrypted at the application layer before doctors can view it. In practice, the increased decryption time leads to data display delays. This problem stems from the fact that during attribute-based encryption strategy verification, the system does not distinguish between independent domains of device attributes in the perception layer, user attributes in the application layer, and data attributes in the data layer. It adopts a global attribute set traversal matching method. In cross-layer access, only the corresponding layer attribute subset needs to be matched, but all attributes are still traversed, resulting in redundant calculations. This causes the server's computing resources to be inefficiently occupied when processing decryption requests. The delay in real-time data decryption affects the timeliness of medical decisions. At the same time, terminal devices remain connected while waiting for decryption results, increasing network transmission burden and device power consumption. Therefore, the existing technology has shortcomings. Summary of the Invention

[0004] To address the technical challenges of attribute-based encrypted access control in a layered architecture of the medical Internet of Things (IoT), such as redundant retrieval space, high computational overhead, and long decryption response latency, which make it difficult to meet the requirements for low-latency and high-security access to medical data, this invention provides the following technical solution to achieve layered, fine-grained access control and efficient data decryption:

[0005] A layered data access control method for the Internet of Things based on attribute-based encryption includes:

[0006] Step S1: Collect attribute registration information and access request data of terminals at each level of the medical Internet of Things, perform hierarchical attribution labeling and attribute encoding on the attribute registration information to obtain a hierarchical attribute encoding set, and construct an attribute domain partitioning prefix tree based on the hierarchical attribute encoding set;

[0007] Step S2: Receive access request data, extract the target level identifier and requester attribute set from the access request, perform hierarchical targeted retrieval on the requester attribute set based on the attribute domain partitioning prefix tree, obtain a candidate attribute matching path set, and construct a strategy matching sparse bit vector table based on the candidate attribute matching path set.

[0008] Step S3: Based on the policy matching sparse bit vector table, perform local policy verification under hierarchical attribute domain pruning, calculate the reconstructability determination result of the linear secret sharing matrix, obtain the access authorization determination vector, and generate a hierarchical decryption delegation token based on the access authorization determination vector.

[0009] Step S4: Based on the hierarchical decryption delegation token, perform lightweight final decryption on the target hierarchical terminal to restore the plaintext of the medical data, and update the local attribute domain partition prefix tree cache and access session state of the terminal according to the decryption result.

[0010] Further, the steps of collecting attribute registration information and access request data from terminals at each level of the medical IoT, performing hierarchical attribution labeling and attribute encoding on the attribute registration information to obtain a hierarchical attribute code set, and constructing an attribute domain partitioning prefix tree based on the hierarchical attribute code set include: S11: collecting attribute registration information from the medical IoT sensing layer, application layer, and data layer respectively, wherein the attribute registration information includes device identifier, user role identifier, attribute name, and hierarchical identifier; S12: performing hierarchical attribution labeling and attribute encoding on the attribute registration information to obtain a hierarchical attribute code set; S13: constructing an attribute domain partitioning prefix tree based on the hierarchical attribute code set.

[0011] Further, the steps of performing hierarchical attribution labeling and attribute encoding on the attribute registration information to obtain a hierarchical attribute code set include: S121: Reading attribute registration information one by one from the attribute registration information database, and labeling each attribute registration information as one of three hierarchical attribution tags: perception layer attribute, application layer attribute, or data layer attribute, based on the value of the hierarchical identifier field in the attribute registration information; S122: Generating an attribute code for each attribute registration information labeled with a hierarchical attribution tag, wherein the attribute code is a fixed-length string composed of three segments in sequence: a hierarchical prefix segment, a role type segment, and an attribute value segment; S123: Grouping and summarizing all generated attribute codes according to the hierarchical attribution tags to obtain a hierarchical attribute code set, wherein the hierarchical attribute code set is a set data structure containing three subsets, namely, the perception layer attribute code subset, the application layer attribute code subset, and the data layer attribute code subset.

[0012] Furthermore, the steps for constructing the attribute domain partitioning prefix tree based on the hierarchical attribute encoding set include: S131: Creating the root node of the attribute domain partitioning prefix tree, and setting three first-level branch nodes under the root node. The first first-level branch node corresponds to the perception layer attribute domain, the second first-level branch node corresponds to the application layer attribute domain, and the third first-level branch node corresponds to the data layer attribute domain. Each first-level branch node uses the value of the hierarchical prefix segment as the branch key; S132: Inserting the role type segment of each attribute code in the perception layer attribute encoding subset character by character under the first-level branch node corresponding to the perception layer attribute domain to form a perception layer subtree; inserting each attribute code in the application layer attribute encoding subset into the first-level branch node corresponding to the application layer attribute domain in the same character-by-character insertion manner. Form an application layer subtree; insert each attribute code in the data layer attribute code subset into the first-level branch node corresponding to the data layer attribute domain in the same character-by-character insertion manner to form a data layer subtree; S133: store the complete attribute value segment and attribute metadata of the corresponding attribute code in each leaf node of the attribute domain partitioning prefix tree; store the total number of attribute codes in the attribute domain and the common prefix length of the attribute codes in each first-level branch node; S134: perform path compression on the subtree under each first-level branch node in the attribute domain partitioning prefix tree. The path compression operation is to traverse each path from the first-level branch node to the leaf node in the subtree. When a continuous sequence of intermediate nodes containing only a single child node appears in the path, the continuous sequence of intermediate nodes is merged into a single node.

[0013] Further, the steps of receiving access request data, extracting the target level identifier and requester attribute set from the access request data, performing hierarchical targeted retrieval on the requester attribute set based on the attribute domain partitioning prefix tree to obtain a candidate attribute matching path set, and constructing a strategy matching sparse bit vector table based on the candidate attribute matching path set include: S21: receiving access request data and extracting the target level identifier and requester attribute set from the access request data; S22: performing hierarchical targeted retrieval on the requester attribute set based on the attribute domain partitioning prefix tree to obtain a candidate attribute matching path set; S23: constructing a strategy matching sparse bit vector table based on the candidate attribute matching path set.

[0014] Further, the steps of performing hierarchical targeted retrieval on the requester attribute set based on the attribute domain partitioning prefix tree to obtain the candidate attribute matching path set include: S221: Based on the extracted target hierarchical identifier, locate the first-level branch node corresponding to the target hierarchical identifier in the constructed attribute domain partitioning prefix tree, and determine the first-level branch node as the retrieval entry node; S222: Filter attribute codes from the extracted requester attribute set whose hierarchical prefix segments are consistent with the hierarchical prefix segment codes corresponding to the retrieval entry node, forming a hierarchically filtered attribute subset; S223: For each attribute code in the hierarchically filtered attribute subset, starting from the retrieval entry node, traverse downwards along the attribute domain partitioning prefix tree character by character according to the role type segment of the attribute code, and record the complete path hit by the attribute code in the attribute domain partitioning prefix tree; S224: Summarize all the hit complete paths to obtain the candidate attribute matching path set.

[0015] Further, based on the policy-matching sparse bit vector table, local policy verification under hierarchical attribute domain pruning is performed to calculate the reconstructability determination result of the linear secret sharing matrix, obtaining the access authorization determination vector. The steps for generating a hierarchical decryption delegation token based on the access authorization determination vector include: S31: Based on the compressed policy-matching sparse bit vector table, extract the row coordinates of all index pairs in the compressed policy-matching sparse bit vector table, remove duplicate row coordinates to obtain a set of valid row indices, extract the row vectors in the linear secret sharing matrix corresponding to each row coordinate in the set of valid row indices, and arrange them in ascending order of row coordinates to form a pruned secret sharing submatrix; S32: Perform linearity verification and secret reconstructability determination on the pruned secret sharing submatrix; S33: Generate the access authorization determination vector based on the reconstructability flag and the reconstruction coefficient vector; S34: Generate a hierarchical decryption delegation token based on the access authorization determination vector.

[0016] Further, the steps for performing linear independence verification and secret reconstructibility determination on the pruned secret shared submatrix include: S321: Performing Gaussian elimination on the pruned secret shared submatrix to obtain a row echelon matrix, and calculating the number of non-zero rows in the row echelon matrix, which is the rank of the pruned secret shared submatrix; S322: Reading the column number of the linear secret shared matrix, and determining whether the calculated rank of the pruned secret shared submatrix is ​​equal to the column number of the linear secret shared matrix. If it is equal, the secret is determined to be reconstructible, a reconstructible flag is generated and its value is set to true; if it is not equal, the secret is determined to be unreconstructable, a reconstructible flag is generated and its value is set to false; S323: If the value of the reconstructible flag is true, the reconstruction coefficient vector corresponding to the pruned secret shared submatrix is ​​calculated. The reconstruction coefficient vector is a numerical vector with a length equal to the number of rows of the pruned secret shared submatrix, satisfying the condition that the weighted linear combination of all row vectors of the pruned secret shared submatrix and each component of the reconstruction coefficient vector equals the target vector.

[0017] Furthermore, based on the hierarchical decryption delegation token, the steps of performing lightweight final decryption on the target-level terminal to restore the plaintext of the medical data, and updating the local attribute domain partition prefix tree cache and access session state of the terminal according to the decryption result include: S41: The target-level terminal receives the generated hierarchical decryption delegation token, reads the signature field from the hierarchical decryption delegation token, and performs RSA digital signature verification operation on the signature field using the public key of the key management center; S42: The target-level terminal performs final decryption operation according to its own attribute private key and the extracted partial decryption intermediate value to restore the plaintext of the medical data; S43: Update the local attribute domain partition prefix tree cache of the terminal according to the decryption result; S44: Update the access session state.

[0018] An attribute-based encryption-based IoT hierarchical data access control system is provided to implement the aforementioned attribute-based encryption-based IoT hierarchical data access control method. The system includes:

[0019] Attribute registration and prefix tree construction module: used to collect attribute registration information and access request data of terminals at all levels of medical IoT, perform hierarchical attribution labeling and attribute encoding on attribute registration information to obtain a hierarchical attribute encoding set, and construct an attribute domain partitioning prefix tree based on the hierarchical attribute encoding set;

[0020] Access Request Processing and Sparse Bit Vector Construction Module: This module receives access request data, extracts the target level identifier and requester attribute set from the access request data, performs hierarchical targeted retrieval on the requester attribute set based on the attribute domain partitioning prefix tree, obtains a candidate attribute matching path set, and constructs a strategy matching sparse bit vector table based on the candidate attribute matching path set.

[0021] The strategy verification and delegation token generation module is used to perform local strategy verification under hierarchical attribute domain pruning based on the sparse bit vector table of strategy matching, calculate the reconstructability determination result of the linear secret sharing matrix, obtain the access authorization determination vector, and generate hierarchical decryption delegation tokens based on the access authorization determination vector.

[0022] Terminal decryption and status update module: It is used to perform lightweight final decryption on the target level terminal based on the hierarchical decryption delegation token, restore the plaintext of medical data, and update the local attribute domain partition prefix tree cache and access session status of the terminal according to the decryption result.

[0023] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0024] This invention effectively solves the problems of redundant retrieval space and excessive computational overhead caused by full-domain attribute traversal during the attribute-based encryption strategy verification stage in the layered architecture of the medical IoT by constructing an attribute domain partitioned prefix tree and performing hierarchical targeted retrieval. Based on the hierarchical characteristics of the medical IoT's perception layer, application layer, and data layer, this method divides attribute codes into three independent subtrees according to hierarchical prefix segments. This ensures that when an access request specifies a target level, strategy verification only needs to search within the corresponding subtree, skipping other hierarchical subtrees, reducing the retrieval space by approximately one-third. Path compression further reduces the subtree depth and the number of node accesses. The retrieval entry node is located by identifying the target level, and irrelevant attribute codes are discarded by hierarchical filtering, achieving a dual reduction in retrieval space and input attributes, reducing the number of attribute codes that need to be traversed. Based on the strategy matching sparse bit vector table, valid row indices are extracted, and a pruned secret shared submatrix is ​​constructed, reducing the Gaussian elimination computation from the cubic number of rows in the original matrix to the cubic number of matching rows, significantly reducing the computational complexity of strategy verification. The lightweight terminal decryption design transfers the bilinear pairing operation to the central node. The terminal only performs one exponential operation and one symmetric decryption. Combined with the attribute domain partitioning prefix tree local caching mechanism, it avoids repeated remote retrieval, significantly shortens the decryption response latency, improves the real-time performance and efficiency of digital information transmission in the medical IoT, and meets the low-latency requirements of medical services for data access. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a flowchart of the IoT hierarchical data access control method based on attribute-based encryption in this invention;

[0027] Figure 2 This is a schematic diagram of the attribute encoding structure in an embodiment of the present invention;

[0028] Figure 3 This is a schematic diagram of the attribute domain partitioning prefix tree in an embodiment of the present invention;

[0029] Figure 4 This is a schematic diagram illustrating a path compression example in an embodiment of the present invention;

[0030] Figure 5 This is a schematic diagram of hierarchical targeted retrieval in an embodiment of the present invention;

[0031] Figure 6 This is an example of strategy matching sparse bit vector representation in an embodiment of the present invention;

[0032] Figure 7 This is a schematic diagram of the secret shared submatrix after trimming in an embodiment of the present invention;

[0033] Figure 8 This is a schematic diagram of the hierarchical decryption delegation token format in an embodiment of the present invention;

[0034] Figure 9 This is a schematic diagram of terminal local caching and audit feedback in an embodiment of the present invention.

[0035] Figure 10 This is a functional block diagram of the attribute-based encryption-based IoT hierarchical data access control system of the present invention. Detailed Implementation

[0036] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0037] Example 1:

[0038] Please see Figure 1 As shown, this embodiment provides a layered data access control method for the Internet of Things based on attribute-based encryption, including:

[0039] S1: Collect attribute registration information and access request data of terminals at all levels of the medical IoT, perform hierarchical attribution labeling and attribute encoding on the attribute registration information to obtain a hierarchical attribute encoding set, and construct an attribute domain partitioning prefix tree based on the hierarchical attribute encoding set.

[0040] Further, step S1 includes:

[0041] S11: Collect the terminal's attribute registration information from the medical IoT sensing layer, application layer, and data layer respectively. The attribute registration information includes device identifier, user role identifier, attribute name, and the identifier of the layer to which it belongs.

[0042] Further, step S11 includes:

[0043] S111: Obtain attribute registration information reported by the sensing layer terminal through the data acquisition interface deployed in the medical IoT sensing layer. The sensing layer terminal includes physiological signal acquisition devices, environmental monitoring sensors, and medical wearable terminals. When the sensing layer terminal first accesses the medical IoT, it submits attribute registration information to the key management center. The device identifier in the attribute registration information is the unique hardware number of the sensing layer terminal, the user role identifier is the role type number of the medical staff or patient operating the sensing layer terminal, the attribute name is the text description of the functional attributes or permission attributes of the sensing layer terminal, and the level identifier is fixedly marked as the level number corresponding to the sensing layer.

[0044] S112: Obtain attribute registration information reported by application layer terminals through the data acquisition interface deployed in the medical IoT application layer. The application layer terminals include clinical diagnostic workstations, remote consultation platforms, and medical order management systems. When registering with the medical IoT, the application layer terminals submit attribute registration information to the key management center. The hierarchical identifier in the attribute registration information is fixedly marked as the hierarchical number corresponding to the application layer.

[0045] S113: Obtain attribute registration information reported by the data layer terminal through the data acquisition interface deployed in the medical IoT data layer. The data layer terminal includes an electronic medical record storage server, a medical image archiving node, and a health record management platform. When registering with the medical IoT, the data layer terminal submits attribute registration information to the key management center. The hierarchical identifier in the attribute registration information is fixedly marked as the hierarchical number corresponding to the data layer.

[0046] S114: The attribute registration information collected in steps S111, S112 and S113 is summarized and stored in the attribute registration information database of the key management center. The attribute registration information database is organized in the form of a relational table. Each record contains four fields: device identifier, user role identifier, attribute name, and level identifier.

[0047] Specifically, the purpose of step S11 is to collect the attribute registration information of terminals from the three layers of the medical IoT and establish a unified attribute registration information database. In the layered architecture of the medical IoT, there are significant differences in the terminal device types, functional attributes, and permission attributes of the perception layer, application layer, and data layer. Perception layer terminals mainly involve data collection attributes, application layer terminals mainly involve business processing attributes, and data layer terminals mainly involve data storage and management attributes. If the attribute registration information is not collected layer by layer, but a unified flat collection method is used, it will be impossible to distinguish the layer to which the attribute belongs when constructing the attribute encoding. This will cause the attribute base encryption strategy verification stage to still need to traverse and match the entire attribute space, making it impossible to achieve layer-based attribute domain pruning. By collecting the information layer by layer and retaining the layer identifier field in the attribute registration information, the necessary layer attribution basis is provided for the layer attribution labeling in the subsequent step S12, so that each attribute registration information carries clear layer information before entering the encoding stage.

[0048] S12: Perform hierarchical attribution labeling and attribute encoding on the attribute registration information to obtain a hierarchical attribute encoding set.

[0049] Further, step S12 includes:

[0050] S121: Read attribute registration information one by one from the attribute registration information database. Based on the value of the hierarchical identifier field in the attribute registration information, label each attribute registration information as one of three hierarchical attribution tags: perception layer attribute, application layer attribute, or data layer attribute. The hierarchical attribution tag is a classification mark attached to the attribute registration information record. When the hierarchical identifier field is the hierarchical number corresponding to the perception layer, it is labeled as a perception layer attribute. When the hierarchical identifier field is the hierarchical number corresponding to the application layer, it is labeled as an application layer attribute. When the hierarchical identifier field is the hierarchical number corresponding to the data layer, it is labeled as a data layer attribute.

[0051] S122: Generate an attribute code for each attribute registration information labeled with a hierarchical affiliation tag. The attribute code is a fixed-length string, composed of three segments concatenated in sequence: a hierarchical prefix segment, a role type segment, and an attribute value segment. The hierarchical prefix segment is the prefix part of the attribute code, with a fixed length of 2 characters. Its value is determined according to the hierarchical affiliation tag. The hierarchical prefix segment corresponding to the perception layer attribute has a fixed value of "01", the hierarchical prefix segment corresponding to the application layer attribute has a fixed value of "02", and the hierarchical prefix segment corresponding to the data layer attribute has a fixed value of "03". The role type segment is the middle part of the attribute code, with a fixed length of 4 characters. It is generated based on the user role identifier field in the attribute registration information through a preset role type code mapping table. The role type code mapping table is preset according to the predefined user role categories in the medical IoT, mapping each user role identifier to a unique 4-character code. The attribute value segment is the tail portion of the attribute code, with a fixed length of 8 characters. It is generated by hashing the attribute name field in the attribute registration information using a secure hash algorithm, extracting the first 8 characters. The secure hash algorithm uses SHA-256, taking the text content of the attribute name field as input and outputting a 256-bit hash value. The first 8 hexadecimal characters of this hash value are then used as the attribute value segment. For example, assuming an attribute registration information entry belongs to the perception layer, the user role identifier corresponds to the role type encoding mapping table with the code "D001", and the attribute name is "heart rate collection permission", then performing a SHA-256 hash operation on "heart rate collection permission" yields the hash value "3f7a9b2c...". The first 8 characters "3f7a9b2c" are extracted as the attribute value segment, resulting in the final attribute code "01D0013f7a9b2c", where "01" is the level prefix segment, "D001" is the role type segment, and "3f7a9b2c" is the attribute value segment. See Figure 2This is a schematic diagram of the attribute encoding structure provided in this application embodiment. As shown in the figure, the attribute encoding is composed of three fixed-length strings concatenated sequentially, from left to right: a hierarchy prefix segment (2 characters), a role type segment (4 characters), and an attribute value segment (8 characters), for a total length of 14 characters. The data sources of each segment are marked at the top of the figure: the hierarchy prefix segment is generated by mapping the hierarchy identifier, with the perception layer, application layer, and data layer corresponding to fixed codes "01", "02", and "03" respectively; the role type segment is generated by the user role identifier through a role type encoding mapping table; and the attribute value segment is generated by truncating the first 8 characters of the attribute name after SHA-256 hashing. A specific encoding example, "01D0013f7a9b2c", is given at the bottom of the figure. In the medical Internet of Things, the length and format of attribute names of terminals at different levels vary significantly. The functional attribute descriptions of perception layer devices are usually shorter, while the permission attribute descriptions of application layer systems may contain longer text content. This encoding structure embeds hierarchical semantics directly into the prefix position of the encoding through hierarchical prefix segments. This allows subsequent construction of the attribute domain partitioning prefix tree to directly determine hierarchical routing based on the first two characters, without needing to backtrack and query the original registration information. The attribute value segment uses SHA-256 hash mapping to unify attribute names of different lengths into a fixed-length representation of 8 characters, ensuring consistent storage format of leaf nodes in the prefix tree and providing a structurally regular foundation for path compression operations.

[0052] S123: Group and summarize all generated attribute codes according to hierarchical attribution labels to obtain a hierarchical attribute code set. The hierarchical attribute code set is a set data structure containing three subsets: the perception layer attribute code subset, the application layer attribute code subset, and the data layer attribute code subset. The perception layer attribute code subset contains all attribute codes whose hierarchical attribution label is perception layer attribute. The application layer attribute code subset contains all attribute codes whose hierarchical attribution label is application layer attribute. The data layer attribute code subset contains all attribute codes whose hierarchical attribution label is data layer attribute.

[0053] Specifically, step S12 transforms the original attribute registration information into a set of hierarchical attribute codes with structured hierarchical semantics through a joint operation of hierarchical attribution labeling and attribute encoding. The hierarchical prefix segment in the attribute code directly embeds hierarchical information, enabling rapid hierarchical routing when constructing the attribute domain partitioning prefix tree without needing to backtrack and query the hierarchical identifier field in the original attribute registration information. The introduction of the role type segment further distinguishes attributes of different role types within the same level. In the medical IoT, the same sensing layer may contain doctor, nurse, and patient roles, each with different attribute sets. The role type segment allows the attribute domain partitioning prefix tree to further refine its branch structure according to role type within the hierarchical branches, improving retrieval efficiency. The attribute value segment is generated using SHA-256 hash mapping. Its purpose is to uniformly map attribute names of varying lengths to fixed-length codes, ensuring that the attribute value segment length corresponding to each leaf node in the attribute domain partitioning prefix tree is consistent, facilitating prefix tree construction and path compression operations. If the attribute encoding operation in step S12 is missing, step S13 will be unable to construct the attribute domain partitioning prefix tree based on a unified encoding format. The length differences of different attribute names will lead to an irregular structure of the prefix tree, the path compression operation will not be effectively executed, and the depth of the tree and the retrieval complexity will increase significantly.

[0054] S13: Construct an attribute domain partitioning prefix tree based on the hierarchical attribute encoding set.

[0055] Further, step S13 includes:

[0056] S131: Create the root node of the attribute domain partitioning prefix tree. The attribute domain partitioning prefix tree is a multi-level tree-based index data structure. The root node is the top-level entry node of the attribute domain partitioning prefix tree and does not store specific attribute data. Three first-level branch nodes are set under the root node: the first first-level branch node corresponds to the perception layer attribute domain, the second first-level branch node corresponds to the application layer attribute domain, and the third first-level branch node corresponds to the data layer attribute domain. Each first-level branch node uses the value of the hierarchical prefix segment as the branch key. The branch key for the perception layer attribute domain is "01", the branch key for the application layer attribute domain is "02", and the branch key for the data layer attribute domain is "03". See also... Figure 3This is a schematic diagram of the attribute domain partitioning prefix tree provided in this application embodiment. As shown in the figure, the attribute domain partitioning prefix tree takes the root node as the top-level entry point and divides it downwards into three first-level branch nodes, corresponding to the perception layer attribute domain (branch key "01"), the application layer attribute domain (branch key "02"), and the data layer attribute domain (branch key "03"), respectively. Each first-level branch node governs the index subtree of all attribute codes within that level. Taking the perception layer subtree as an example, the first-level branch nodes expand level by level according to the characters of the role type segment. The figure shows two branches, role type nodes "D" and "N". The "D" branch, after path compression, forms a merged node "00", which then branches downwards to nodes "1" and "2", finally reaching the leaf node to store the attribute value segment and attribute metadata. The bottom of the figure marks the three-segment composition structure of the attribute code, which corresponds to the hierarchical structure of the tree. In the actual deployment of medical IoT, the number of perception layer terminals is usually much greater than that of application layer and data layer terminals, resulting in the size of the perception layer attribute code subset being significantly larger than the other two subsets. The attribute domain partitioning prefix tree isolates the attribute encoding of the three levels into independent subtrees. This allows the retrieval operation to completely bypass the large perception layer subtree when the access request points to the application layer or data layer. The reduction in retrieval space is particularly significant in scenarios with uneven distribution of hierarchical attributes. The path compression operation merges consecutive single-child nodes into a single node, reducing the subtree depth and the number of node accesses per retrieval.

[0057] S132: Insert each attribute code in the perceptual layer attribute encoding subset into the first-level branch node corresponding to the perceptual layer attribute domain, character by character, to form a perceptual layer subtree. The character-by-character insertion process starts from the first character of the character type segment, sequentially checking whether the current node has a child node with that character as the branch key. If it exists, continue downwards along that child node; if it does not exist, create a new child node with that character as the branch key and continue downwards along the new child node until all characters in the character type segment have been processed. Insert each attribute code in the application layer attribute encoding subset into the first-level branch node corresponding to the application layer attribute domain using the same character-by-character insertion method to form an application layer subtree. Insert each attribute code in the data layer attribute encoding subset into the first-level branch node corresponding to the data layer attribute domain using the same character-by-character insertion method to form a data layer subtree. For example, assuming the perceptual layer attribute encoding subset contains three attribute codes with role type segments "D001", "D001", and "N002" respectively, then under the first-level branch node of the perceptual layer attribute domain, the first character "D" of "D001" is inserted to create a child node, followed by the second character "0" to create a lower-level child node, and so on, inserting "0" and "1" to complete the insertion of the role type segment of the first attribute code. When inserting the second attribute code "D001", since the path already exists, it directly reaches the end node along the existing path. When inserting the third attribute code "N002", a new child node with "N" as the branch key is created under the first-level branch node, and then "0", "0", and "2" are inserted to form a new path.

[0058] S133: In each leaf node of the attribute domain partition prefix tree, the complete attribute value segment and attribute metadata corresponding to the attribute code are stored. The attribute metadata includes the original attribute name, device identifier, and user role identifier corresponding to the attribute code. In each first-level branch node, the total number of attribute codes in the attribute domain and the length of the common prefix of the attribute codes are stored. The total number of attribute codes is the number of entries of attribute codes in the attribute code subset corresponding to the first-level branch node, and the length of the common prefix is ​​the number of characters of the longest common prefix of the role type segments of all attribute codes in the attribute code subset.

[0059] S134: Perform path compression on the subtrees under each first-level branch node in the attribute domain partitioning prefix tree. The path compression operation involves traversing each path from the first-level branch node to a leaf node in the subtree. When a continuous sequence of intermediate nodes containing only a single child node appears in the path, this continuous sequence of intermediate nodes is merged into a single node. The branch key of the merged single node is set to the concatenated string of the branch keys of the merged continuous intermediate nodes, reducing the depth of the attribute domain partitioning prefix tree and obtaining the final attribute domain partitioning prefix tree. For example, suppose there is a path "D"->"0"->"0"->"1" in the perceptual layer subtree, where "0"->"0" is a continuous path containing only a single child node. After path compression, it is merged into "D"->"00"->"1", reducing the depth of the attribute domain partitioning prefix tree from 4 levels to 3 levels. See also... Figure 4 This is a schematic diagram illustrating a path compression example provided in this application. As shown, the left side shows the path structure before compression. Starting from the root node, it sequentially passes through "01" and "D," then enters two consecutive single child nodes "0" and "0," before reaching node "1" and the leaf node. The path depth is 6 levels. The left curly brace marks the "single child node continuous path" area composed of two consecutive single child nodes. The middle arrow indicates the direction of the "path compression" operation. The right side shows the path structure after compression. The two consecutive single child nodes "0" and "0" are merged into a single node "00" (marked with a bold border). The path depth is reduced from 6 levels to 5 levels, and a note next to it states "two single nodes merged into one node." In the medical IoT, attribute codes for different role types within the same level may share a large number of prefixes in the first few characters of the role type segment. For example, the first two characters of the role type segment of the doctor's role code and the nurse's role code in the same department may be the same. This will generate a large number of intermediate node links containing only a single child node in the attribute domain partition prefix tree. Path compression reduces the physical depth of the tree by merging these redundant intermediate nodes without changing the tree's logical semantics. This reduces the number of nodes that need to be accessed during each retrieval from a first-level branch node to a leaf node, directly shortening the time overhead of a single attribute encoding retrieval.

[0060] Specifically, the attribute domain partitioning prefix tree constructed in step S13 is the core data structure for implementing attribute domain pruning. In traditional attribute-based encryption schemes, the policy verification phase requires matching all attributes held by the requester with all policy attributes in the ciphertext access policy one by one. When the number of registered attributes in the medical IoT reaches a large scale, the computational cost of full-domain traversal matching increases linearly with the number of attributes. The attribute domain partitioning prefix tree divides the attribute codes into three independent subtrees according to the hierarchical prefix segments. This allows the policy verification phase to only search within the subtree corresponding to the target level when the access request specifies the target level, skipping the subtrees of the other two levels, thereby reducing the search space to about one-third of the original. The path compression operation further reduces the depth of the subtrees, reducing the number of node accesses in each search process. The total number of attribute codes and the length of the common prefix stored in the first-level branch nodes provide a fast judgment basis for the hierarchical targeted search in the subsequent step S22, enabling the search algorithm to evaluate the size and structural characteristics of the subtree before entering it. Without the construction of the attribute domain partitioning prefix tree in step S13, step S22 cannot perform hierarchical directional retrieval and must instead perform linear traversal matching of all attribute codes. This is the root cause of the redundant computational overhead problem that this patent aims to solve. Step S13 and step S12 form a close data dependency relationship. The hierarchical attribute code set output by step S12 is the only input data source for constructing the attribute domain partitioning prefix tree in step S13. The hierarchical prefix segment of the attribute codes in the hierarchical attribute code set determines the first-level branch structure of the attribute domain partitioning prefix tree, the role type segment determines the intermediate layer structure of the subtree, and the attribute value segment determines the storage content of the leaf nodes.

[0061] S2: Receive access request data, extract the target level identifier and requester attribute set from the access request data, perform hierarchical targeted retrieval on the requester attribute set based on the attribute domain partitioning prefix tree, obtain the candidate attribute matching path set, and construct a strategy matching sparse bit vector table based on the candidate attribute matching path set.

[0062] Further, step S2 includes:

[0063] S21: Receive access request data, extract the target level identifier and requester attribute set from the access request data. The access request data is a structured data packet of a data access request initiated by a terminal in the medical Internet of Things, containing the identity information of the requester and the description information of the resource to be accessed. The target level identifier is a field value in the access request data that indicates the level that the requester intends to access, and the value is one of the level numbers corresponding to the perception layer, application layer, or data layer. The requester attribute set is a set of all attribute codes held by the requester carried in the access request data. The format of each attribute code is consistent with the attribute code format generated in step S122, and is composed of three segments: level prefix segment, role type segment, and attribute value segment.

[0064] S22: Perform hierarchical targeted retrieval on the requester's attribute set based on the attribute domain partition prefix tree to obtain a set of candidate attribute matching paths.

[0065] Further, step S22 includes:

[0066] S221: Based on the target level identifier extracted in step S21, locate the first-level branch node corresponding to the target level identifier in the attribute domain partitioning prefix tree constructed in step S13. This first-level branch node is determined as the retrieval entry node, and the subtrees corresponding to the other two first-level branch nodes in the attribute domain partitioning prefix tree are skipped without any retrieval operation. The location process involves converting the target level identifier into the corresponding level prefix segment code, and searching for a first-level branch node under the root node of the attribute domain partitioning prefix tree whose branch key matches the level prefix segment code. For example, if the target level identifier is the level number corresponding to the perception layer, it is converted into the level prefix segment code "01". The first-level branch node with branch key "01" under the root node is searched as the retrieval entry node, and the subtrees corresponding to branch key "02" for the application layer attribute domain and branch key "03" for the data layer attribute domain are completely skipped. See also... Figure 5 This is a schematic diagram of hierarchical targeted retrieval provided in an embodiment of this application. As shown in the figure, the left side of the figure shows the retrieval process of the attribute domain partition prefix tree, and the right side shows the hierarchical filtering process of the requester attribute set. The two work together to achieve dual pruning. In the attribute domain partition prefix tree on the left, when the target level is the application layer, the retrieval entry is located at the first-level branch node corresponding to the branch key "02". The perception layer subtree (branch key "01") and the data layer subtree (branch key "03") are completely skipped with cross marks. Only the application layer subtree is expanded to perform character-by-character traversal retrieval. In the requester attribute set on the right, the attribute codes with the hierarchical prefix segments "01" and "03" are discarded with cross marks. Only the three attribute codes with the hierarchical prefix segment "02" are retained to form the hierarchically filtered attribute subset, and the hierarchical targeted retrieval is performed by pointing to the application layer subtree on the left through the leader. In clinical diagnostic scenarios within the Internet of Things (IoT) for healthcare, when a clinical diagnostic workstation initiates an application-layer data access request, its attribute set may simultaneously contain both perception-layer attributes and data-layer attributes held due to historical registration. If these attribute codes, unrelated to the current access target, are not filtered, they will generate invalid retrieval initiation overhead. The retrieval space pruning on the left and the input dimension pruning on the right create a synergistic effect, ensuring that the actual retrieval operation only occurs within the intersection of the target-level subtree and the target-level attribute codes. This reduces the retrieval computation to a level proportional to the size of the target-level attributes, rather than proportional to the total number of attributes across the entire domain.

[0067] S222: From the requester attribute set extracted in step S21, select attribute codes whose hierarchical prefix segments match the hierarchical prefix segment codes corresponding to the retrieval entry node, forming a hierarchically filtered attribute subset. Discard attribute codes in the requester attribute set whose hierarchical prefix segments do not match the hierarchical prefix segment codes corresponding to the retrieval entry node. The hierarchically filtered attribute subset is a subset of attribute codes in the requester attribute set that retains only those related to the target level. Its data structure is the same as the requester attribute set, being a set of attribute codes. For example, suppose the requester attribute set contains 5 attribute codes, of which 3 have hierarchical prefix segments of "01" corresponding to the perception layer, 1 has hierarchical prefix segments of "02" corresponding to the application layer, and 1 has hierarchical prefix segments of "03" corresponding to the data layer. If the hierarchical prefix segment code corresponding to the retrieval entry node is "01", then the hierarchically filtered attribute subset contains 3 attribute codes, and the other 2 attribute codes are discarded.

[0068] S223: For each attribute code in the attribute subset after hierarchical filtering, starting from the retrieval entry node, traverse downwards character by character along the attribute domain partition prefix tree according to the role type segment of the attribute code. The traversal process is as follows: starting from the retrieval entry node, take the first character of the role type segment, and search for the child node in the child node of the current node whose branch key matches the character (if a merged node after path compression is encountered, compare whether the concatenated string of the branch key of the merged node matches the corresponding substring of the role type segment). If a matching child node is found, move to the child node and continue processing the next character of the role type segment until all characters of the role type segment are processed and the leaf node position is reached. At this time, further compare whether the attribute value segment stored in the leaf node is consistent with the attribute value segment of the current attribute code. If they are consistent, record the complete path hit by the attribute code in the attribute domain partition prefix tree. The complete path includes all node sequences traversed from the retrieval entry node to the leaf node. If an attribute code fails to reach a leaf node during traversal because a matching child node cannot be found at a certain node, or if the attribute values ​​are inconsistent after reaching the leaf node, then the attribute code is marked as a miss and discarded from the attribute subset after hierarchical filtering.

[0069] S224: Summarize all the complete paths that were matched in step S223 to obtain a candidate attribute matching path set. The candidate attribute matching path set is a list data structure. Each element in the list is a complete path record. Each complete path record contains the sequence of nodes passed through the path, the corresponding attribute code, and the attribute metadata stored in the leaf node.

[0070] Specifically, step S22 implements the core logic of attribute domain pruning through hierarchical targeted retrieval. In the hierarchical architecture of the medical IoT, when a terminal initiates an access request for a specific level, the attributes that the terminal actually needs to match are only a subset of the attributes corresponding to that target level. Traditional attribute-based encryption schemes, upon receiving an access request, match all attributes held by the requester one by one with all attributes in the policy, without considering the natural segmentation characteristics of attribute domains under a hierarchical architecture. Step S221 directly locates the corresponding first-level branch node in the attribute domain partitioning prefix tree through the target level identifier, allowing the retrieval operation to completely bypass the attribute domain subtrees of the other two levels. The degree of reduction in the retrieval space depends on the size ratio of the attribute domains at each level. Step S222 further performs hierarchical filtering on the requester's attribute set, discarding attribute codes unrelated to the target level, reducing the number of attribute codes that need to be traversed in the attribute domain partitioning prefix tree. The synergistic effect of steps S221 and S222 achieves dual pruning. Step S221 prunes from the retrieval space dimension of the attribute domain partitioning prefix tree, while step S222 prunes from the input dimension of the requester's attribute set; both are indispensable. If only the retrieval space pruning of step S221 is performed without the input pruning of step S222, attribute codes in the requester's attribute set that are unrelated to the target level will still be sent to the attribute domain partitioning prefix tree for retrieval one by one. Although the retrieval will terminate at the retrieval entry node due to the mismatch of the hierarchical prefix segment, unnecessary retrieval initiation overhead is still generated. If only the input pruning of step S222 is performed without the retrieval space pruning of step S221, the attribute codes in the attribute subset after hierarchical filtering still need to be retrieved from the root node in the complete attribute domain partitioning prefix tree, involving additional routing judgment steps from the root node to the first-level branch node.

[0071] S23: Construct a sparse bit vector table for strategy matching based on the candidate attribute matching path set.

[0072] Further, step S23 includes:

[0073] S231: Obtain the encrypted access policy corresponding to the target level identifier. The encrypted access policy is the access control policy embedded in the encrypted data by the data owner when encrypting medical data, and is represented using a linear secret sharing scheme. Convert the encrypted access policy into a linear secret sharing matrix. The linear secret sharing matrix is ​​an integer matrix with the number of rows equal to the number of policy attribute labels and the number of columns equal to the dimension of the secret sharing parameters. The conversion process is performed using the standard policy tree to matrix conversion method in the linear secret sharing scheme. Extract all policy attribute labels from the linear secret sharing matrix. The policy attribute labels are the attribute identifiers associated with each row in the linear secret sharing matrix. Arrange the policy attribute labels in row order to form a policy attribute label sequence. The policy attribute label sequence is an ordered list data structure. The first element in the list is the policy attribute label associated with the first row of the linear secret sharing matrix, and so on.

[0074] S232: Create a policy matching sparse bit vector table, which is a two-dimensional bit matrix data structure. The number of rows equals the number of policy attribute labels in the policy attribute label sequence, and the number of columns equals the number of complete path records in the candidate attribute matching path set. Each position in the matrix stores 1 bit value, and initially, all positions have a bit value of 0. See also Figure 6 This is a schematic representation of the policy matching sparse bit vector table provided in this application embodiment. As shown in the figure, the left side is the complete two-dimensional bit matrix form of the policy matching sparse bit vector table. The rows correspond to the 6 policy attribute labels in the encrypted access policy, and the columns correspond to the 4 candidate paths in the candidate attribute matching path set. There are 24 intersection positions in the matrix. The figure highlights the 4 positions with a bit value of 1 with a bold border, and the bit values ​​of the remaining 20 positions are all 0, which intuitively shows the high sparsity of the matrix. The right side shows the storage form after sparse compression, which only records the row and column coordinates of the 4 valid matching bits in the index pair list. The data storage is compressed from 24 bits to 4 index pairs. The bottom further marks the set of valid row indexes extracted from the compressed index pairs. This set directly points to the rows in the linear secret sharing matrix that need to participate in the reconstructible decision operation. In the medical Internet of Things, data owners usually set up relatively complex encrypted access policies to protect sensitive medical data. The number of policy attribute labels may reach dozens, while the number of valid attributes held by a single requester at a certain level is usually only a single digit. Therefore, the sparsity of the policy matching sparse bit vector table is high. Sparse compression not only reduces storage overhead, but more importantly, it enables subsequent steps to directly locate the valid rows in the linear secret sharing matrix based on the index, avoiding a row-by-row scan of all rows and reducing the input size of the policy verification calculation from the total number of policy attributes to the actual number of matched attributes.

[0075] S233: Traverse each row and column intersection position of the sparse bit vector table for policy matching. For the intersection position of the i-th row and i-th column, read the attribute code associated with the i-th policy attribute label in the policy attribute label sequence and the i-th complete path record in the candidate attribute matching path set. Extract the attribute value segment of the attribute code. Perform a consistency comparison between the policy attribute label and the attribute value segment. The consistency comparison is to determine whether the string content of the policy attribute label is completely the same as the string content of the attribute value segment. If they are completely the same, set the bit value of the intersection position to 1; otherwise, keep it as 0.

[0076] S234: Perform sparse compression on the policy matching sparse bit vector table. The sparse compression operation involves traversing all intersection positions in the policy matching sparse bit vector table, extracting the row and column coordinates of the positions with a bit value of 1, forming index pairs from the row and column coordinates of all positions with a bit value of 1, storing them in the form of an index pair list, discarding the position information with a bit value of 0 in the policy matching sparse bit vector table, and generating a compressed policy matching sparse bit vector table. The data structure of the compressed policy matching sparse bit vector table is an index pair list, and each index pair contains two integer values: row coordinate and column coordinate. For example, suppose the policy matching sparse bit vector table has 6 rows and 3 columns, with only 4 intersection positions having a bit value of 1, located in the 1st row and 2nd column, the 3rd row and 1st column, the 4th row and 3rd column, and the 6th row and 2nd column, then the compressed policy matching sparse bit vector table stores 4 index pairs: (1,2), (3,1), (4,3), and (6,2), reducing the data storage from 18 bits to 4 index pairs and a total of 8 integer values.

[0077] Specifically, the policy matching sparse bit vector table is a crucial intermediate data structure connecting attribute domain pruning and policy verification calculations. In attribute-based encryption schemes, the essential operation of policy verification is to determine whether the attribute set held by the requester meets the requirements of the ciphertext access policy. In linear secret sharing schemes, this determination is transformed into a reconfigurability assessment of the linear secret sharing matrix. In traditional schemes, reconfigurability assessment requires operations on all rows of the linear secret sharing matrix. However, the policy matching sparse bit vector table accurately identifies which rows in the linear secret sharing matrix match the requester's attributes and which do not by recording the matching relationship between the attribute codes in the candidate attribute matching path set and the policy attribute labels. After sparse compression, the policy matching sparse bit vector table only retains the position indices of the valid matching bits. Subsequent step S31 can directly extract matching rows from the linear secret sharing matrix based on these position indices without needing to check for matching row by row. In the medical IoT, the number of policy attribute tags in the encrypted access policy is usually much larger than the number of valid attributes held by a single requester. Therefore, the number of positions with a bit value of 1 in the policy matching sparse bit vector table is much smaller than the total number of elements in the matrix, resulting in high sparsity. Sparse compression can significantly reduce storage overhead and subsequent traversal overhead. Step S23 depends on the candidate attribute matching path set output in step S22 and the encrypted access policy obtained in step S231. If the hierarchical targeted retrieval in step S22 is missing, the candidate attribute matching path set will contain attribute matching results from all levels, increasing the number of columns in the policy matching sparse bit vector table, reducing sparsity, weakening the effect of sparse compression, and consequently reducing the pruning effect of subsequent policy verification calculations.

[0078] S3: Based on the policy matching sparse bit vector table, perform local policy verification under hierarchical attribute domain pruning, calculate the reconstructability determination result of the linear secret sharing matrix, obtain the access authorization determination vector, and generate a hierarchical decryption delegation token based on the access authorization determination vector.

[0079] Further, step S3 includes:

[0080] S31: Based on the compressed policy matching sparse bit vector table output in step S234, extract the row coordinates of all index pairs in the compressed policy matching sparse bit vector table. After removing duplicate row coordinates, obtain the effective row index set. Extract the row vectors from the linear secret sharing matrix corresponding to each row coordinate in the effective row index set, and arrange them in ascending order of row coordinates to form a pruned secret sharing submatrix. The pruned secret sharing submatrix is ​​a row subset matrix of the linear secret sharing matrix, with the number of rows equal to the number of row coordinates in the effective row index set, and the number of columns the same as the number of columns in the linear secret sharing matrix. See also Figure 7This is a schematic diagram of the pruned secret sharing submatrix provided in this application embodiment. As shown in the figure, the left side is the complete linear secret sharing matrix (4 rows and 3 columns), where the 2nd and 4th rows are row vectors corresponding to the effective row index set {2, 4}. The arrow in the middle, labeled "Extracted based on effective row indexes," points to the pruned secret sharing submatrix on the right. This submatrix only contains the 2nd row [0,1,1] and the 4th row [1,1,1] of the original matrix, reducing the number of rows from 4 to 2, while keeping the number of columns unchanged at 3. The lower right side indicates that this submatrix is ​​used for secret reconfigurability determination. In the attribute-based encryption scheme of the medical IoT, the number of rows in the linear secret sharing matrix is ​​equal to the total number of policy attribute tags in the ciphertext access policy. When the data owner sets a complex access policy containing multiple condition combinations, the number of matrix rows may be large. However, after attribute domain pruning and sparse bit vector compression, only a few rows actually match the requester's attributes. The computational complexity of Gaussian elimination is proportional to the cube of the number of rows in the matrix. By pruning the operand from a complete matrix to a submatrix containing only valid rows, the computational complexity is significantly reduced as the number of valid rows decreases. This greatly shortens the computation time in the policy verification phase, which is particularly crucial for clinical diagnosis and remote consultation scenarios in the Internet of Things for healthcare that require rapid response.

[0081] S32: Perform linearity verification and secret reconstructibility determination on the pruned secret shared submatrix.

[0082] Further, step S32 includes:

[0083] S321: Perform Gaussian elimination on the clipped secret shared submatrix. The Gaussian elimination is the process of transforming the clipped secret shared submatrix into a row echelon form matrix through elementary row operations. Calculate the number of non-zero rows in the row echelon form matrix. The number of non-zero rows is the rank of the clipped secret shared submatrix.

[0084] S322: Read the column number of the linear secret sharing matrix, and determine whether the rank of the pruned secret sharing sub-matrix calculated in step S321 is equal to the column number of the linear secret sharing matrix. If the rank of the pruned secret sharing sub-matrix is ​​equal to the column number of the linear secret sharing matrix, then the secret is determined to be reconstructable, a reconstructable flag is generated, and the value of the reconstructable flag is set to true. If the rank of the pruned secret sharing sub-matrix is ​​not equal to the column number of the linear secret sharing matrix, then the secret is determined to be unreconstructable, a reconstructable flag is generated, and the value of the reconstructable flag is set to false. The reconstructable flag is a Boolean variable, with a value of true or false.

[0085] S323: If the value of the reconstructable flag in step S322 is true, then calculate the reconstruction coefficient vector corresponding to the pruned secret shared submatrix. The reconstruction coefficient vector is a numerical vector with a length equal to the number of rows of the pruned secret shared submatrix, satisfying the condition that the weighted linear combination of all row vectors of the pruned secret shared submatrix equals the target vector. The target vector is a unit vector with the first component being 1 and the remaining components being 0. The reconstruction coefficient vector is calculated by solving the linear equation system composed of the transpose of the pruned secret shared submatrix and the target vector, and using Gaussian elimination back substitution to obtain the values ​​of each component of the reconstruction coefficient vector. For example, suppose the linear secret sharing matrix has 3 columns. After pruning, the secret sharing submatrix is ​​a 4x3 matrix with row vectors [1,1,0], [0,1,1], [1,0,1], and [1,1,1], and the target vector is [1,0,0]. After solving the linear equation system, the reconstructed coefficient vector is [ω1,ω2,ω3,ω4], such that ω1×[1,1,0]+ω2×[0,1,1]+ω3×[1,0,1]+ω4×[1,1,1]=[1,0,0].

[0086] Specifically, the physical meaning of the secret reconstructibility determination in step S32 is as follows: In a linear secret sharing scheme, the data owner splits the secret value of the encryption key into multiple secret sharing components during encryption. Each secret sharing component is associated with a row of the linear secret sharing matrix and a policy attribute label. Only when the row vectors of the linear secret sharing matrix corresponding to the policy attribute label held by the requester can be linearly combined to reconstruct the target vector, can the requester recover the complete secret value of the encryption key through the secret sharing components corresponding to these row vectors. The rank of the pruned secret sharing submatrix is ​​equal to the number of columns of the linear secret sharing matrix, meaning that the row space of the pruned secret sharing submatrix covers the entire column space of the linear secret sharing matrix. The target vector must be located in the row space of the pruned secret sharing submatrix, therefore the secret is reconstructible.

[0087] S33: Generate an access authorization decision vector based on the reconfigurable flag and the reconfiguration coefficient vector.

[0088] Further, step S33 includes:

[0089] S331: If the reconfigurable flag value in step S322 is true, create an access authorization determination vector. The access authorization determination vector is a structured data record containing four fields: an authorization status field, a coefficient field, a hierarchy field, and an attribute summary field. Set the authorization status field of the access authorization determination vector to authorized. Write the reconfigurable coefficient vector calculated in step S323 into the coefficient field of the access authorization determination vector. Write the target hierarchy identifier extracted in step S21 into the hierarchy field of the access authorization determination vector. Write the hash value obtained by concatenating all attribute codes in the requester attribute set extracted in step S21 in order and performing a SHA-256 hash operation as the digest value into the attribute summary field of the access authorization determination vector.

[0090] S332: If the value of the reconfigurable flag in step S322 is false, create an access authorization determination vector, set the authorization status field of the access authorization determination vector to authorization denial, set the coefficient field of the access authorization determination vector to null, write the target level identifier extracted in step S21 into the level field of the access authorization determination vector, and write the digest value of the requester attribute set extracted in step S21 into the attribute digest field of the access authorization determination vector after calculating it according to the same hash operation method in step S331.

[0091] S34: Generate a hierarchical decryption delegate token based on the access authorization determination vector.

[0092] Further, step S34 includes:

[0093] S341: Read the authorization status bit field of the access authorization determination vector. If the value of the authorization status bit field is authorization denied, generate an empty token and terminate the subsequent process. The empty token is a placeholder data structure that does not contain any valid decryption information and only carries an authorization denied status identifier to notify the requester that access has been denied.

[0094] S342: If the value of the authorization status bit field is authorization passed, extract the reconstruction coefficient vector stored in the coefficient field and the target level identifier stored in the level field from the access authorization judgment vector. Calculate a partial decryption intermediate value based on the reconstruction coefficient vector. The calculation process of the partial decryption intermediate value is as follows: extract the ciphertext secret shared component corresponding to each row coordinate in the valid row index set from the ciphertext data. The ciphertext secret shared component is a bilinear pairing operation element embedded in the ciphertext when the data owner encrypts it. Perform the exponential operation in the bilinear pairing operation on each ciphertext secret shared component and the corresponding component in the reconstruction coefficient vector. Perform a cumulative multiplication operation on the target group to obtain a partial decryption intermediate value. The partial decryption intermediate value is a group element on the target group.

[0095] S343: The four data items calculated in step S342—the partial decryption intermediate value, the value of the hierarchy field in the access authorization determination vector, the value of the attribute digest field in the access authorization determination vector, and the current system timestamp—are encapsulated into a hierarchy decryption delegation token. This hierarchy decryption delegation token is a structured data record containing four fields: the partial decryption intermediate value field, the hierarchy field, the attribute digest field, and the timestamp field. After concatenating all fields of the hierarchy decryption delegation token, a SHA-256 hash value is calculated. An RSA digital signature operation is performed on this hash value using the private key of the key management center. The resulting digital signature is appended to the hierarchy decryption delegation token as a signature field. This digital signature is used in subsequent step S41 for the target hierarchy terminal to verify the integrity and authenticity of the hierarchy decryption delegation token. See also... Figure 8 This is a schematic diagram of the hierarchical decryption delegation token format provided in this application embodiment. As shown in the figure, the hierarchical decryption delegation token consists of five fields arranged in sequence: partial decryption intermediate value, hierarchy, attribute digest, timestamp, and signature. Each field is connected to an explanatory box by a leader line, indicating the specific data type of each field: the partial decryption intermediate value is a group element on the target group, the hierarchy is the target hierarchy identifier, the attribute digest is the SHA-256 hash value of the requester's attribute set, the timestamp is the system time, and the signature is the RSA digital signature from the key management center. The signature calculation range is marked at the bottom of the figure with a horizontal line, covering the concatenated content of the first four fields; the signature field itself does not participate in the signature calculation. In the medical IoT, the hierarchical decryption delegation token plays a crucial role in securely transmitting the computationally intensive results of the policy verification phase to terminals with limited computing resources. The partial decryption intermediate value field encapsulates the cumulative result of multiple bilinear pairing operations, eliminating the need for the terminal to perform these high-overhead calculations itself. The RSA digital signature ensures that the token is not tampered with during transmission in the medical IoT network, preventing attackers from forging partial decryption intermediate values ​​or tampering with the hierarchy identifier to bypass access control policies. The timestamp field provides a basis for validating the validity of the token, preventing expired tokens from being exploited by replay attacks.

[0096] Specifically, the local policy verification and hierarchical decryption delegation token generation in step S3 are key steps in solving the decryption response latency problem in the medical IoT. Local policy verification, through step S31, extracts the pruned secret shared sub-matrix based on the effective row index set in the compressed policy-matching sparse bit vector table. This restricts the reconstructability determination operation of the linear secret shared matrix to a subset of row vectors matching the requester's attributes. The number of rows in the pruned secret shared sub-matrix is ​​typically much smaller than that of the linear secret shared matrix. Since the computational complexity of Gaussian elimination is proportional to the cube of the number of rows, reducing the number of rows significantly lowers computational complexity. The hierarchical decryption delegation token encapsulates the result of the bilinear pairing operation, which has the highest computational cost in attribute-based encryption and decryption, as a partial decryption intermediate value. This is performed by the policy verification stage on a key management center or edge computing node with strong computing capabilities, rather than on the medical IoT terminal with limited computing resources. This design, which shifts the decryption computation overhead from the terminal to the policy verification stage, allows the terminal to recover the plaintext medical data by performing only a lightweight final decryption operation in step S4, significantly reducing the terminal's decryption response latency. Step S3 and step S2 form a close functional dependency. The compressed policy matching sparse bit vector table output by step S2 provides accurate and effective row index information for step S31. Without the attribute domain pruning and sparse bit vector construction in step S2, step S31 would be unable to determine which rows in the linear secret sharing matrix need to participate in the reconstructible decision operation, and would have to perform operations on all rows of the linear secret sharing matrix, degenerating into a traditional full-domain traversal matching method. At the same time, the hierarchical decryption delegation token output by step S3 provides necessary partial decryption intermediate values ​​for the lightweight final decryption in step S4. Without the partial decryption computation in step S3, the terminal in step S4 would need to perform all bilinear pairing operations on its own. Performing a large number of bilinear pairing operations on terminals with limited computing resources in the medical IoT would lead to unacceptable decryption response latency.

[0097] S4: Based on the hierarchical decryption delegation token, perform lightweight final decryption on the target hierarchical terminal to restore the plaintext of medical data, and update the local attribute domain partition prefix tree cache and access session state of the terminal according to the decryption result.

[0098] Further, step S4 includes:

[0099] S41: The target-level terminal receives the level decryption delegation token generated in step S343, reads the signature field from the level decryption delegation token, and performs an RSA digital signature verification operation on the signature field using the public key of the key management center. The digital signature verification operation involves concatenating all fields in the level decryption delegation token except the signature field, calculating a SHA-256 hash value, decrypting the signature field using the public key of the key management center to obtain the original hash value, and comparing the calculated hash value with the decrypted original hash value. If they do not match, the signature verification is deemed to have failed, the level decryption delegation token is discarded, and the timestamp of this signature verification failure event, the timestamp field value of the level decryption delegation token, and the failure reason code are recorded in the terminal's local exception log file. If they match, the signature verification is deemed to have passed, and the partial decryption intermediate value stored in the partial decryption intermediate value field and the target level identifier stored in the level field are extracted from the level decryption delegation token.

[0100] S42: The target terminal performs the final decryption operation based on its own attribute private key and the partial decryption intermediate value extracted in step S41 to restore the plaintext of the medical data.

[0101] Further, step S42 includes:

[0102] S421: The target-level terminal reads the attribute private key component corresponding to the digest value stored in the attribute digest field of the hierarchical decryption delegation token from the local key storage. The attribute private key component is a specific component in the attribute base encryption private key generated and distributed by the key management center for the terminal during the attribute registration stage. The local key storage is a secure storage area on the terminal device, which stores the corresponding attribute private key component with the attribute digest value as the index key.

[0103] S422: Using the attribute private key component read in step S421, perform a single exponentiation operation on the partial decryption intermediate value extracted in step S41. The single exponentiation operation is to perform a power operation on the partial decryption intermediate value with the attribute private key component as the exponent on the target group of the bilinear pairing operation to calculate the session decryption key. The session decryption key is a group element on the target group, which is the embedded representation of the symmetric encryption key used by the data owner during encryption on the target group.

[0104] S423: Perform a symmetric decryption operation on the ciphertext data using the session decryption key calculated in step S422. The symmetric decryption operation uses the AES-256-GCM algorithm. The session decryption key is mapped from the target group element to a 256-bit symmetric key and then used as the decryption key input for the AES-256-GCM algorithm. The symmetric ciphertext part in the ciphertext data is used as the input to be decrypted. After performing the AES-256-GCM decryption operation, the plaintext medical data is obtained.

[0105] Specifically, the final decryption operation in step S42 only includes one exponential operation on the target group and one AES-256-GCM symmetric decryption operation. In contrast, the complete decryption process of traditional attribute-based encryption schemes requires multiple bilinear pairing operations proportional to the number of matching attributes. Step S342 already aggregates the results of multiple bilinear pairing operations into a partial decryption intermediate value during the policy verification phase. Step S42 only requires a single exponential operation on this partial decryption intermediate value using the attribute private key component to restore the session decryption key on the terminal. In the medical IoT, the computing power of sensing layer terminals, such as physiological signal acquisition devices and medical wearable terminals, is limited. Their processor clock speed and memory capacity are far lower than those of server-level devices. Bilinear pairing operations involve large integer multiplication and exponential operations on elliptic curves. The execution time of a single pairing operation on resource-constrained terminals can reach tens of milliseconds, and the total execution time increases linearly with the number of matching attributes. By transferring the bilinear pairing operation to the policy verification stage and completing it on a node with strong computing power, the terminal only undertakes one exponential operation and one symmetric decryption operation, which greatly shortens the execution time of the decryption operation, enabling the terminal to complete decryption and obtain the plaintext of medical data in a shorter time.

[0106] S43: Update the local attribute domain partition prefix tree cache of the terminal based on the decryption result.

[0107] Further, step S43 includes:

[0108] S431: Cache each complete path record in the candidate attribute matching path set successfully matched in step S224 to the local storage of the target-level terminal. Establish a mapping relationship between the target-level identifier and each complete path record in the candidate attribute matching path set. The mapping relationship is stored in key-value pairs, where the key is the target-level identifier and the value is a list of all complete path records in the candidate attribute matching path set. This forms a local cache of the attribute domain partition prefix tree. The local cache of the attribute domain partition prefix tree is a partial data copy of the attribute domain partition prefix tree stored in the local storage of the target-level terminal, containing only path information related to the terminal's historical accesses. See also Figure 9This is a schematic diagram of terminal local caching and audit feedback provided in this application embodiment. As shown in the figure, the upper part of the figure shows the internal structure of the target-level terminal, including a local cache table of the attribute domain partition prefix tree. This table uses the target level as the key, the complete path record list as the value, and the lifetime as the expiration control field, storing historical retrieval path records of the perception layer, application layer, and data layer, respectively. The lifetime of each layer is set to 12 hours. Below the cache table are the mechanisms for directly using the local path record to skip remote retrieval when the cache hits and for marking and clearing the cache when the lifetime is greater than or equal to the preset expiration time. The lower part of the figure shows the audit feedback closed loop: the terminal synchronizes the access session log to the security audit node, the security audit node calculates the average decryption response latency of each layer, and when the average decryption response latency of a certain layer exceeds the preset latency alarm threshold, a reconstruction notification is sent to the key management center. The key management center reconstructs the attribute domain partition prefix tree based on the latest attribute encoding to restore retrieval efficiency. In the actual operation of the Internet of Things (IoT) in healthcare, clinical diagnostic workstations typically access the same level of medical data continuously over a period of time during routine diagnosis and treatment. Attribute domain partitioning and local caching of the prefix tree allow terminals to directly reuse historical search results when repeatedly initiating access requests at the same level within a short period, avoiding the network communication and computational overhead of repeatedly performing remote searches. A time-to-live (TTL) mechanism ensures that cached data expires promptly after changes in attribute registration information, preventing authorization errors due to expired cache. An audit feedback loop enables the system to automatically trigger prefix tree reconstruction when dynamic changes in attribute registration information cause the prefix tree structure to no longer fit the current attribute distribution, continuously maintaining high-efficiency decryption response performance.

[0109] S432: Set a lifetime field for each complete path record in the local cache of the attribute domain partition prefix tree. The lifetime field records the time when the complete path record is cached. When the difference between the cache time recorded in the lifetime field of a complete path record in the local cache of the attribute domain partition prefix tree and the current system time is greater than or equal to a preset validity period, mark the complete path record as invalid and remove it from the local cache of the attribute domain partition prefix tree. The preset validity period is determined based on the average update cycle of attribute registration information in the medical Internet of Things. The preset validity period should not be greater than the average update cycle of attribute registration information to ensure that the path information in the local cache of the attribute domain partition prefix tree will not be used after it becomes invalid due to changes in attribute registration information. For example, if the average update cycle of attribute registration information is 24 hours, the preset validity period can be set to 12 hours.

[0110] S433: When the target-level terminal initiates another access request with the same target-level identifier stored in the local cache of the attribute domain partition prefix tree, the corresponding complete path record list is retrieved first in the local cache of the attribute domain partition prefix tree using the target-level identifier as the key. If the local cache of the attribute domain partition prefix tree contains a list of undated complete path records corresponding to the target-level identifier, it is determined to be a cache hit. The list of complete path records stored in the local cache of the attribute domain partition prefix tree is directly used as the candidate attribute matching path set, skipping the remote retrieval operation of the attribute domain partition prefix tree in step S22, and directly executing step S23 to construct the strategy matching sparse bit vector table. If the local cache of the attribute domain partition prefix tree does not contain a list of undated complete path records corresponding to the target-level identifier, it is determined to be a cache miss. The remote retrieval operation of the attribute domain partition prefix tree is executed according to the complete process of step S22.

[0111] S44: Update access session state.

[0112] Further, step S44 includes:

[0113] S441: Create or append an access session log locally on the target-level terminal. The access session log is a log file stored in structured text format. Each log record contains four fields: the target-level identifier of this access, the access timestamp, the value of the authorization status bit, and the decryption time. The decryption time is the time elapsed from the start of the final decryption operation in step S42 to the acquisition of the plaintext medical data, recorded in milliseconds.

[0114] S442: The target-level terminal synchronizes newly written log records in the access session log to the security audit node through the network layer communication channel of the medical IoT. The security audit node is a dedicated audit server deployed in the network layer of the medical IoT. After receiving the access session logs synchronized by each terminal, the security audit node groups the log records in the access session log according to the target level identifier, calculates the arithmetic mean of the decryption time field value of all log records in each level within a preset statistical time window, and obtains the average decryption response latency of that level. The preset statistical time window is determined based on the operation and maintenance monitoring cycle of the medical IoT. For example, the preset statistical time window can be set to 1 hour. The security audit node compares the average decryption response latency of each level with a preset latency alarm threshold. The latency alarm threshold is determined based on the upper limit of the decryption response latency requirements for each level of the medical IoT terminal, set by the system administrator according to the real-time requirements of medical services. For example, the latency alarm threshold for the perception layer can be set to 200 milliseconds, the application layer to 500 milliseconds, and the data layer to 1000 milliseconds. If the average decryption response latency of a certain level exceeds the corresponding latency alarm threshold, the security audit node sends a notification to the key management center to rebuild the attribute domain partition prefix tree for that level. Upon receiving the notification, the key management center re-executes step S13, rebuilding the attribute domain partition prefix tree based on the latest hierarchical attribute encoding set in the attribute registration information database. The updated attribute domain partition prefix tree replaces the original attribute domain partition prefix tree for hierarchical targeted retrieval of subsequent access requests.

[0115] Specifically, step S4, through three stages—lightweight final decryption, local caching of the attribute domain partition prefix tree, and update of the access session state—completes the final restoration from ciphertext to plaintext and provides closed-loop feedback on the system's operational status. The introduction of the attribute domain partition prefix tree local caching mechanism is designed to address the scenario in the medical IoT where terminals frequently and repeatedly access the same level of resources. In clinical diagnostic scenarios, the same clinical diagnostic workstation typically accesses the same level of medical data continuously over a period of time, and its attribute set does not change in a short period. Therefore, the candidate attribute matching path set has high reusability in a short time. By caching the candidate attribute matching path set locally on the terminal and setting a time-to-live (TTL) for timeliness control, the repeated execution of remote retrieval operations on the attribute domain partition prefix tree when the terminal repeatedly initiates the same level of access requests in a short period is avoided, further reducing the overall processing latency of access requests. The TTL mechanism ensures that data in the attribute domain partition prefix tree local cache will not continue to be used after attribute registration information changes, avoiding authorization judgment errors caused by expired cached data. Access session logs and security audit nodes form a closed loop for monitoring and feedback on decryption response latency. When the average decryption response latency at a certain level exceeds the latency alarm threshold, the reconstruction of the attribute domain partition prefix tree is triggered. A continuous increase in average decryption response latency may stem from large-scale changes to the attribute registration information at that level, causing the attribute domain partition prefix tree structure to no longer adapt to the current attribute distribution, resulting in decreased path compression and reduced retrieval efficiency. By reconstructing the attribute domain partition prefix tree, its structure is re-adapted to the latest attribute distribution, restoring retrieval efficiency and path compression.

[0116] Step S4 and step S1 form a feedback loop through the reconstruction notification of the attribute domain partition prefix tree, enabling the entire system to maintain high decryption response performance continuously in an environment where attribute registration information changes dynamically, rather than only being efficient during initial deployment. The local caching of the attribute domain partition prefix tree in step S43 and the hierarchical targeted retrieval in step S22 form a synergistic optimization relationship. Step S22 achieves hierarchical attribute domain pruning through the attribute domain partition prefix tree, while step S43 achieves time-dimensional retrieval overhead pruning through the local caching of the attribute domain partition prefix tree. If only the hierarchical targeted retrieval in step S22 is relied upon without the local caching of the attribute domain partition prefix tree in step S43, the terminal must perform a remote retrieval of the attribute domain partition prefix tree every time it initiates an access request. In high-frequency access scenarios, the network communication overhead and retrieval computation overhead of remote retrieval will accumulate and become a bottleneck affecting decryption response latency. If only the attribute domain partitioning prefix tree local caching in step S43 is relied upon, without the hierarchical targeted retrieval in step S22, the candidate attribute matching path set stored in the cache will contain matching results from all levels, increasing the storage overhead of the cache and reducing the cache hit rate. The synergistic effect of the two allows the results of hierarchical targeted retrieval to be reused in the time dimension through the caching mechanism, further reducing the system's decryption response latency when accessed concurrently by a large number of terminals.

[0117] For example, the workflow of the above steps is illustrated using a medical IoT deployment scenario. A hospital has deployed a medical IoT system. The perception layer includes 120 physiological signal acquisition devices and 80 environmental monitoring sensors; the application layer includes 30 clinical diagnostic workstations and 10 remote consultation platforms; and the data layer includes 5 electronic medical record storage servers and 3 medical image archiving nodes. In step S11, the key management center collects 680, 150, and 90 attribute registration information entries from the perception layer, application layer, and data layer, respectively. In step S12, hierarchical attribution labeling and attribute encoding are performed on the 920 attribute registration information entries. The attribute encoding subset for the perception layer contains 680 attribute codes, the attribute encoding subset for the application layer contains 150 attribute codes, and the attribute encoding subset for the data layer contains 90 attribute codes. In step S13, an attribute domain partitioning prefix tree is constructed. The perception layer subtree contains 680 leaf nodes, the application layer subtree contains 150 leaf nodes, and the data layer subtree contains 90 leaf nodes. After path compression, the depth of the perception layer subtree is reduced from 6 layers to 4 layers. A clinical diagnostic workstation initiates a request to access application layer electronic medical record data. The requester attribute set of the clinical diagnostic workstation contains 12 attribute codes, of which 5 have a hierarchical prefix segment of "02" corresponding to the application layer, 4 have a hierarchical prefix segment of "01" corresponding to the perception layer, and 3 have a hierarchical prefix segment of "03" corresponding to the data layer. In step S221, the first-level branch node of the application layer attribute domain is located according to the target hierarchical identifier, skipping the 680 leaf nodes of the perception layer subtree and the 90 leaf nodes of the data layer subtree. In step S222, 5 attribute codes with a hierarchical prefix segment of "02" are selected from the 12 attribute codes to form a hierarchically filtered attribute subset, and the remaining 7 attribute codes are discarded. In step S223, the five attribute codes are traversed character by character in the application layer subtree. Four hit leaf nodes, and one miss is discarded, resulting in a candidate attribute matching path set containing four complete path records. In step S23, it is assumed that the linear secret sharing matrix corresponding to the ciphertext access strategy has 8 rows and 3 columns, the strategy attribute label sequence contains 8 strategy attribute labels, and the strategy matching sparse bit vector table has 8 rows and 4 columns with 32 intersection positions, of which only 3 intersection positions have a bit value of 1. After sparse compression, only 3 index pairs are stored. In step S31, the row coordinates of the 2nd, 5th, and 7th rows are extracted from the 3 index pairs. Three row vectors are extracted from the linear secret sharing matrix to form a pruned secret sharing submatrix, which has 3 rows and 3 columns. In step S321, Gaussian elimination is performed on the pruned secret sharing submatrix, and the rank is calculated to be 3, which is equal to the number of columns in the linear secret sharing matrix (3), indicating that the secret is reconstructible. In step S323, the reconstruction coefficient vector is solved. In step S342, the reconstructed coefficient vector is used to perform a bilinear pairing operation on the three ciphertext secret shared components and multiply them to obtain a partial decryption intermediate value.In step S42, the clinical diagnostic workstation uses the attribute private key component to perform a single exponential operation on a portion of the decryption intermediate values ​​to obtain the session decryption key. Using this session decryption key, it performs AES-256-GCM symmetric decryption to obtain the plaintext electronic medical record data. Throughout the process, attribute domain pruning reduces the retrieval space from 920 attribute codes to 150 application layer subtrees corresponding to attribute codes; input pruning reduces the number of retrievals from 12 to 5; policy verification calculations are reduced from 8 rows of matrix operations to 3 rows; and terminal decryption operations are reduced from 3 bilinear pairing operations to 1 exponential operation and 1 symmetric decryption operation.

[0118] Example 2:

[0119] This embodiment, based on Embodiment 1, provides an IoT hierarchical data access control system based on attribute-based encryption, such as... Figure 10 As shown, it includes:

[0120] Attribute registration and prefix tree construction module: used to collect attribute registration information and access request data of terminals at all levels of medical IoT, perform hierarchical attribution labeling and attribute encoding on attribute registration information to obtain a hierarchical attribute encoding set, and construct an attribute domain partitioning prefix tree based on the hierarchical attribute encoding set;

[0121] Access Request Processing and Sparse Bit Vector Construction Module: This module receives access request data, extracts the target level identifier and requester attribute set from the access request data, performs hierarchical targeted retrieval on the requester attribute set based on the attribute domain partitioning prefix tree, obtains a candidate attribute matching path set, and constructs a strategy matching sparse bit vector table based on the candidate attribute matching path set.

[0122] The strategy verification and delegation token generation module is used to perform local strategy verification under hierarchical attribute domain pruning based on the sparse bit vector table of strategy matching, calculate the reconstructability determination result of the linear secret sharing matrix, obtain the access authorization determination vector, and generate hierarchical decryption delegation tokens based on the access authorization determination vector.

[0123] Terminal decryption and status update module: It is used to perform lightweight final decryption on the target level terminal based on the hierarchical decryption delegation token, restore the plaintext of medical data, and update the local attribute domain partition prefix tree cache and access session status of the terminal according to the decryption result.

[0124] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A layered data access control method for the Internet of Things based on attribute-based encryption, characterized in that, The method includes: Collect attribute registration information and access request data of terminals at all levels of the medical Internet of Things, perform hierarchical attribution labeling and attribute encoding on the attribute registration information to obtain a hierarchical attribute encoding set, and construct an attribute domain partitioning prefix tree based on the hierarchical attribute encoding set; Receive access request data, extract the target level identifier and requester attribute set from the access request data, perform hierarchical targeted retrieval on the requester attribute set based on the attribute domain partitioning prefix tree, obtain a candidate attribute matching path set, and construct a strategy matching sparse bit vector table based on the candidate attribute matching path set. Based on the policy matching sparse bit vector table, local policy verification is performed under hierarchical attribute domain pruning, the reconstructability determination result of the linear secret sharing matrix is ​​calculated, the access authorization determination vector is obtained, and a hierarchical decryption delegation token is generated based on the access authorization determination vector. Based on the hierarchical decryption delegation token, a lightweight final decryption is performed on the target-level terminal to restore the plaintext of the medical data, and the local attribute domain partition prefix tree cache and access session state are updated according to the decryption result.

2. The IoT hierarchical data access control method based on attribute-based encryption according to claim 1, characterized in that, The steps for constructing an attribute domain partitioning prefix tree based on a hierarchical attribute encoding set include: The terminal's attribute registration information is collected from the sensing layer, application layer, and data layer of the medical Internet of Things. The attribute registration information includes device identifier, user role identifier, attribute name, and level identifier. The attribute registration information is hierarchically labeled and encoded to obtain a hierarchical attribute code set; Based on the hierarchical attribute encoding set, construct an attribute domain partitioning prefix tree.

3. The IoT hierarchical data access control method based on attribute-based encryption according to claim 2, characterized in that, The steps for obtaining the hierarchical attribute encoding set include: Read the attribute registration information one by one from the attribute registration information database. Based on the value of the level identifier field in the attribute registration information, label each attribute registration information as one of the three level affiliation tags: perception layer attribute, application layer attribute, or data layer attribute. For each attribute registration information marked with a hierarchical affiliation tag, an attribute code is generated. The attribute code is a fixed-length string, which is composed of three segments in sequence: hierarchical prefix segment, role type segment, and attribute value segment. All generated attribute codes are grouped and summarized according to hierarchical affiliation labels to obtain a hierarchical attribute code set. The hierarchical attribute code set is a set data structure containing three subsets: the perception layer attribute code subset, the application layer attribute code subset, and the data layer attribute code subset.

4. The IoT hierarchical data access control method based on attribute-based encryption according to claim 2, characterized in that, The steps for constructing the attribute domain partition prefix tree include: Create the root node of the attribute domain partition prefix tree, and set 3 first-level branch nodes under the root node. The first first-level branch node corresponds to the perception layer attribute domain, the second first-level branch node corresponds to the application layer attribute domain, and the third first-level branch node corresponds to the data layer attribute domain. Each first-level branch node uses the value of the hierarchical prefix segment as the branch key. Insert the role type segment of each attribute code in the perception layer attribute coding subset into the first-level branch node corresponding to the perception layer attribute domain character by character to form the perception layer subtree; insert each attribute code in the application layer attribute coding subset into the first-level branch node corresponding to the application layer attribute domain in the same character-by-character insertion manner to form the application layer subtree; insert each attribute code in the data layer attribute coding subset into the first-level branch node corresponding to the data layer attribute domain in the same character-by-character insertion manner to form the data layer subtree. Each leaf node of the attribute domain partitioning prefix tree stores the complete attribute value segment and attribute metadata corresponding to the attribute code; each first-level branch node stores the total number of attribute codes and the common prefix length of the attribute codes within that attribute domain. Path compression is performed on the subtrees under each first-level branch node in the attribute domain partitioning prefix tree. The path compression operation involves traversing each path from the first-level branch node to the leaf node in the subtree. When a continuous sequence of intermediate nodes containing only a single child node appears in the path, the continuous sequence of intermediate nodes is merged into a single node.

5. The IoT hierarchical data access control method based on attribute-based encryption according to claim 1, characterized in that, The steps of constructing a strategy-matching sparse bit vector table based on the candidate attribute matching path set include: Receive access request data and extract the target level identifier and requester attribute set from the access request data; Based on the attribute domain partitioning prefix tree, a hierarchical targeted search is performed on the requester's attribute set to obtain a set of candidate attribute matching paths; Based on the candidate attribute matching path set, a sparse bit vector table for strategy matching is constructed.

6. The IoT hierarchical data access control method based on attribute-based encryption according to claim 5, characterized in that, The steps involved in performing hierarchical targeted retrieval on the requester's attribute set based on the attribute domain partitioning prefix tree to obtain a set of candidate attribute matching paths include: Based on the extracted target level identifier, locate the first-level branch node corresponding to the target level identifier in the constructed attribute domain partitioning prefix tree, and determine the first-level branch node as the retrieval entry node; From the extracted requester attribute set, select attribute codes whose hierarchical prefix segments match the hierarchical prefix segment codes corresponding to the retrieval entry node, and form a hierarchical filtered attribute subset; For each attribute code in the attribute subset after hierarchical filtering, starting from the retrieval entry node, traverse down the attribute domain partition prefix tree character by character according to the role type segment of the attribute code, and record the complete path of the attribute code in the attribute domain partition prefix tree. By summing up all the complete paths that match, we obtain a set of candidate attribute matching paths.

7. The IoT hierarchical data access control method based on attribute-based encryption according to claim 1, characterized in that, The step of generating a hierarchical decryption delegation token based on the access authorization determination vector includes: Based on the compressed policy matching sparse bit vector table, the row coordinates of all index pairs in the compressed policy matching sparse bit vector table are extracted. After removing duplicate row coordinates, the effective row index set is obtained. The row vectors in the linear secret sharing matrix corresponding to each row coordinate in the effective row index set are extracted and arranged in ascending order of row coordinates to form the pruned secret sharing submatrix. Perform linearity verification and secret reconstructibility determination on the pruned secret shared submatrix; Based on the reconfigurable flag and the reconfiguration coefficient vector, an access authorization decision vector is generated; Generate hierarchical decryption delegate tokens based on access authorization determination vectors.

8. The IoT hierarchical data access control method based on attribute-based encryption according to claim 7, characterized in that, The steps for performing linear independence verification and secret reconstructability determination on the pruned secret shared submatrix include: Perform Gaussian elimination on the pruned secret shared submatrix to obtain a row echelon matrix. Calculate the number of non-zero rows in the row echelon matrix. The number of non-zero rows is the rank of the pruned secret shared submatrix. Read the column number of the linear secret sharing matrix, and determine whether the rank of the calculated pruned secret sharing submatrix is ​​equal to the column number of the linear secret sharing matrix. If it is equal, the secret is determined to be reconstructable, a reconstructable flag is generated and its value is set to true; if it is not equal, the secret is determined to be unreconstructable, a reconstructable flag is generated and its value is set to false. If the value of the reconstructable flag is true, then the reconstruction coefficient vector corresponding to the pruned secret shared submatrix is ​​calculated. The reconstruction coefficient vector is a numerical vector with a length equal to the number of rows of the pruned secret shared submatrix, satisfying the condition that the weighted linear combination of all row vectors of the pruned secret shared submatrix and each component of the reconstruction coefficient vector equals the target vector.

9. The IoT hierarchical data access control method based on attribute-based encryption according to claim 1, characterized in that, The steps of updating the local attribute domain partition prefix tree cache and access session state of the terminal based on the decryption result include: The target-level terminal receives the generated hierarchical decryption delegation token, reads the signature field from the hierarchical decryption delegation token, and performs RSA digital signature verification operation on the signature field using the public key of the key management center; The target-level terminal performs the final decryption operation based on its own attribute private key and the extracted partial decryption intermediate value to restore the plaintext of the medical data; Update the local attribute domain partition prefix tree cache on the terminal based on the decryption results; Update the access session state.

10. A layered data access control system for the Internet of Things (IoT) based on attribute-based encryption, used to implement the layered data access control method for the IoT based on attribute-based encryption as described in any one of claims 1-9, characterized in that, The system includes: Attribute registration and prefix tree construction module: used to collect attribute registration information and access request data of terminals at all levels of medical IoT, perform hierarchical attribution labeling and attribute encoding on attribute registration information to obtain a hierarchical attribute encoding set, and construct an attribute domain partitioning prefix tree based on the hierarchical attribute encoding set; Access Request Processing and Sparse Bit Vector Construction Module: This module receives access request data, extracts the target level identifier and requester attribute set from the access request data, performs hierarchical targeted retrieval on the requester attribute set based on the attribute domain partitioning prefix tree, obtains a candidate attribute matching path set, and constructs a strategy matching sparse bit vector table based on the candidate attribute matching path set. The strategy verification and delegation token generation module is used to perform local strategy verification under hierarchical attribute domain pruning based on the sparse bit vector table of strategy matching, calculate the reconstructability determination result of the linear secret sharing matrix, obtain the access authorization determination vector, and generate hierarchical decryption delegation tokens based on the access authorization determination vector. Terminal decryption and status update module: It is used to perform lightweight final decryption on the target level terminal based on the hierarchical decryption delegation token, restore the plaintext of medical data, and update the local attribute domain partition prefix tree cache and access session status of the terminal according to the decryption result.

Images