Time-sequenced encrypted storage and expiration shredding of external device monitoring data

Abstract

The application belongs to the field of data security, and particularly relates to a time-sequencing encryption storage and expiration pulverization method of external device monitoring data, comprising: obtaining an external device monitoring data stream, segmenting according to a preset time window and deriving a unique encryption key for each segment; encrypting the corresponding window data with the key and storing to obtain a time-sequencing encryption data block; in response to a joint analysis request, distributing a specified window key to a calculation party according to a preset authorization strategy for it to perform secure multi-party computation on the window data block; simultaneously, monitoring the data block life cycle in real time, automatically erasing the data and destroying the corresponding key when expired, generating a pulverization verifiable evidence, and uploading to a storage chain constructed by a general data platform root key and each calculation party key combined with a blockchain; the application guarantees data storage security and joint analysis compliance, avoids residual key risk, ensures pulverization operation traceability, and improves multi-party cooperation credibility.

Description

Technical Field

[0001] This invention belongs to the field of data security, and in particular relates to a method for time-series encrypted storage and expired data shredding of external device monitoring data. Background Technology

[0002] With the explosive growth in the number of external devices connected to general data platforms in the era of the Internet of Things (IoT), the massive amounts of monitoring data generated have distinct characteristics of high time sequence, high privacy correlation, and a clearly defined lifecycle. The core technical dilemma currently faced by the platform lies in the fact that its data processing solutions cannot synergistically balance time-series joint analysis and full lifecycle privacy protection. Specifically, because the entire data stream is encrypted with static keys, it is impossible to efficiently and securely support joint analysis of encrypted data by multiple organizations in time segments, forcing business parties to choose between decrypting all data or abandoning the analysis. At the same time, there is a lack of an automated security shredding mechanism that links the data expiration with the encryption key, resulting in expired data being merely marked for deletion rather than physically destroyed. This makes it extremely easy to recover and leak, and it is impossible to provide collaborators with verifiable evidence that the data has been completely destroyed. This deficiency causes general computing platforms to encounter bottlenecks in both compliance and data analysis efficiency, restricting cross-organizational collaboration and value mining based on sensitive time-series data. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention proposes a time-series encrypted storage and expiration shredding method for external device monitoring data. This method first acquires the external device monitoring data stream to be processed, divides the data into segments according to preset time windows, and derives a unique encryption key for each segment. Then, it uses this key to encrypt and store the monitoring data within the corresponding window, obtaining time-series encrypted data blocks. When responding to a multi-party joint analysis request, it distributes the unique encryption key for the specified window to the computing party according to a preset authorization policy, allowing them to directly perform secure multi-party computation on the time-series encrypted data block of that window. Simultaneously, it monitors the preset lifecycle of each time-series encrypted data block in real time, automatically triggering a secure shredding process upon expiration. This erases the data block's stored content and simultaneously destroys the corresponding unique encryption key, generating a verifiable shredding operation record, which is then uploaded to a storage chain constructed using a blockchain algorithm combining the root key of a general data platform and the unique encryption keys of each computing party. This method ensures data storage security and compliance of joint analysis, avoids the risk of residual keys, ensures traceability of the shredding operation, and enhances the credibility of multi-party collaboration.

[0004] To achieve the above objectives, the present invention provides the following technical solution:

[0005] Methods for time-series encrypted storage and expired data shredding of external device monitoring data include:

[0006] Acquire the external device monitoring data stream to be processed, divide the data into segments according to a preset time window, and derive a unique encryption key for each time window data segment;

[0007] The monitoring data within the corresponding time window is encrypted and stored based on the derived unique encryption key to obtain the time-series encrypted data block.

[0008] In response to a joint analysis request initiated by multiple organizations, a unique encryption key corresponding to a specified time window is distributed to the computing parties participating in the joint analysis based on a preset authorization strategy. This allows the computing parties to directly perform secure multi-party computation on time-series encrypted data blocks within the specified time window. The organizations and computing parties are either in one-to-one or one-to-many correspondence.

[0009] The preset lifecycle of each time-series encrypted data block is monitored in real time, and a secure shredding process is automatically triggered when any of the time-series encrypted data blocks reaches the lifecycle period.

[0010] Specifically, the secure shredding process includes: erasing the original storage content of time-series encrypted data blocks that have reached their lifespan, simultaneously destroying the unique encryption key corresponding to the time-series encrypted data block, generating verifiable evidence of the shredding operation of the time-series encrypted data block, and uploading the verifiable evidence to the storage chain of the general data platform for storage; the storage chain is constructed by combining the root key corresponding to the general data platform, the unique encryption key corresponding to each computing party, and the corresponding reputation score with a blockchain algorithm.

[0011] Specifically, a unique encryption key is derived for each time window data segment, including:

[0012] Based on the type of external device and the data sampling frequency, the duration of the preset time window is obtained through a weighted linear regression algorithm.

[0013] Based on the preset time window duration and external device monitoring data, a timestamp is generated, and the monitoring data segment corresponding to each time window is obtained through a data stream sliding algorithm.

[0014] Based on the unique external device identifier, time window start stamp, and root key pre-stored on the general data platform corresponding to each time window monitoring data segment, the initial key material is obtained through SHA-256 hash operation. The unique device identifier is used to ensure that the data segment keys of different devices are not duplicated, and the time window start stamp is used to ensure that the data segment keys of the same device in different time windows are not duplicated.

[0015] Based on the initial key material and the key fragments pre-allocated by each participating institution, a unique encryption key for each time window data segment is obtained through the Shamir secret sharing algorithm.

[0016] Specifically, the process of obtaining the root key pre-stored in the general data platform includes:

[0017] Based on the combined hash value of the core hardware identifier of the general data platform, the unique identifier list of the initially connected external devices, and the initialization timestamp of the general data platform, a 256-bit initial random number is generated using a cryptographically secure random number generator.

[0018] Based on the SHA-256 hash value of the initial random number and the core hardware identifier, the combined SHA-256 hash value of the external device unique identifier list, and the SHA-256 hash value of the general data platform initialization timestamp, the key expansion is performed through the HKDF key derivation function to obtain a 256-bit root key.

[0019] Based on the 256-bit root key, it is split into a preset number of key fragments using the Shamir secret sharing algorithm and distributed to multiple trusted nodes of the general data platform for storage. At the same time, the root key is hashed using the SHA-256 hash algorithm to generate a root key hash value, and the root key hash value is written into the storage chain for evidence preservation.

[0020] Specifically, the monitoring data within the corresponding time window is encrypted and stored based on the derived unique encryption key, including:

[0021] Based on the unique encryption key derived from the monitoring data segment of the corresponding time window, the unique identifier of the external device associated with the corresponding time window, and the start stamp of the time window, the monitoring data segment is encrypted using a symmetric encryption algorithm, and the unique identifier of the external device and the start stamp of the time window are embedded synchronously to obtain the encrypted data.

[0022] Based on the encrypted data and the composite index constructed from the unique identifier of the external device and the start stamp of the time window, storage operations are performed through the storage chain of the general data platform to obtain the associated storage record of the encrypted data and the composite index;

[0023] Based on the associated storage records of encrypted data and composite indexes, and the associated identifier of unique encryption keys, a time-series encrypted data block is obtained through an association analysis algorithm. The time-series encrypted data block includes at least: the device unique identifier used to identify the external device to which the time-series encrypted data block belongs, the time window start stamp used to distinguish different time windows under the same external device, and the composite index used to locate the corresponding time window during composite analysis.

[0024] Specifically, the process of constructing an authorization strategy includes:

[0025] Based on the identity identifiers, qualification certificate types, and initial reputation scores based on historical compliance records of the computing parties participating in the joint analysis, a preset dynamic identity qualification mapping is performed to obtain a basic authorization list; the basic authorization list at least includes the association between computing party identity identifiers and qualification certificate types;

[0026] Based on the qualification certificate type, initial reputation score, and unique external device identifier of each computing party in the basic authorized list, the range of unique external device identifiers accessed by each computing party is defined by a dynamic permission mapping algorithm, and the association rule between the computing party's identity identifier and the range of unique external device identifiers is obtained; wherein the size of the unique identifier range is adjusted by combining the preset basic range size with the ratio of the corresponding computing party's real-time reputation score to the preset accessible reputation score threshold.

[0027] Based on the association rules between the computing party's identity and the unique identifier of the external device, the start stamp of the time window, and the historical data access frequency, a dynamic time window interval for each computing party to obtain the key is set through a dynamic time window authorization algorithm; the dynamic time window interval is adjusted according to the magnitude of the historical data access frequency of each computing party.

[0028] Specifically, the process of constructing the authorization strategy also includes:

[0029] Based on the dynamic time window range of each computing party's key acquisition, real-time reputation score, and historical key usage compliance score, the validity period of the unique encryption key is configured through a dynamic key validity configuration algorithm to obtain the correspondence rule between the computing party's identity and the validity period of the unique encryption key; the length of the validity period of the unique encryption key is proportional to the real-time reputation score and historical key usage compliance score of each computing party.

[0030] Based on the basic authorized list, the association rules between the computing party's identity and the unique identifier range of external devices, the binding relationship between the computing party's identity and the dynamic time window interval, and the corresponding rules between the computing party's identity and the validity period of the unique encryption key, a request verification rule is generated through a dynamic rule integration algorithm to obtain a dynamically adjusted preset authorization strategy.

[0031] The request verification rules require the submission of the computing party's identity identifier, joint analysis project filing information, target time window, and corresponding external device unique identifier. The request verification rules are automatically updated as the computing party's real-time reputation score and historical behavior data change.

[0032] Specifically, based on a preset authorization policy, unique encryption keys corresponding to a specified time window are distributed to the computing parties participating in the joint analysis, including:

[0033] Based on joint analysis requests initiated by multiple organizations, the request parsing algorithm configured on the general data platform is used to extract the identifiers of each participating organization, joint analysis project filing information, common target time window, and unique identifier range of associated equipment contained in the joint analysis request to obtain the request data to be verified.

[0034] Based on the identifiers of each participating organization in the request data to be verified and the basic authorization list in the preset authorization policy, the identifiers of each participating organization and the qualification certificate types of each organization are verified by the federated identity verification algorithm based on X.509 certificates. At the same time, the correlation between the joint analysis project filing information and the equipment data corresponding to the unique identifier range of the associated equipment is verified by the joint project compliance verification algorithm, so as to obtain the multi-organization joint identity verification result.

[0035] When the multi-organization joint authentication result is passed, the association rules between the unique identifier range of the associated device in the request data to be verified and the identity identifier of each participating organization and the unique identifier range of the external device in the preset authorization policy are combined. The intersection of the unique identifier range of the external device of each participating organization is calculated by the multi-organization permission intersection algorithm to determine the unique identifier range of the device accessed by the joint analysis. The permission boundary verification algorithm is used to check whether the unique identifier of the associated device in the request data to be verified is within the unique identifier range of the device accessed by the joint analysis, and the external device permission verification result is obtained.

[0036] Specifically, distributing unique encryption keys corresponding to a specified time window to participating computing parties based on a preset authorization policy also includes:

[0037] When the external device permission verification result is within the range, the binding relationship between the target time window in the request data to be verified and the calculation party identity in the preset authorization policy and the dynamic time window interval is combined. The time window matching algorithm is used to check whether the start timestamp of the target time window is later than the authorization start timestamp of the dynamic time window interval, and whether the end timestamp of the target time window is earlier than the authorization end timestamp of the dynamic time window interval, so as to obtain the time window verification result.

[0038] When the time window verification result meets the matching threshold, the following operations are performed using the key reconstruction status query algorithm:

[0039] Extract the key shard index table corresponding to the target time window, send a key shard submission command carrying the start stamp of the time window to the participating institutions recorded in the key shard index table, receive the key shards and shard signatures returned by the participating institutions, verify the validity of the shard signatures using the ECDSA digital signature verification algorithm with the participating institutions' preset public key, compare the received shard numbers with the shard numbers recorded in the key shard index table using a shard number matching algorithm, filter out the valid key shards that have passed the double verification, count the number of valid key shards using a shard count algorithm, compare the counted number with a preset number threshold, if the counted number is not less than the preset number threshold, perform a joint operation on the valid key shards using the Shamir secret sharing reconstruction algorithm to generate a unique encryption key candidate value, compare the unique encryption key candidate value with the joint hash value of the device unique identifier and the start stamp of the time window using a key verification algorithm, if the verification is successful, the result is that the key availability is usable.

[0040] Specifically, distributing unique encryption keys corresponding to a specified time window to participating computing parties based on a preset authorization policy also includes:

[0041] When the key availability result is available, the corresponding rules of the computing party identity identifier and the validity period of the unique encryption key in the preset authorization policy, as well as the real-time reputation score and historical key usage compliance score of the corresponding computing party, are combined. The validity period of the unique encryption key is calculated by the key validity generation algorithm according to the weighted ratio of the real-time reputation score and the historical key usage compliance score. A unique encryption key with a specified time window and a validity period restriction is generated. The unique encryption key is associated with the device unique identifier and the time window start stamp by the association binding algorithm to obtain the key package to be distributed.

[0042] Based on the key packet to be distributed, the key packet is transmitted to the computing party through an encrypted transmission channel. At the same time, a log structured recording algorithm is used to record the computing party's identity, distribution time, key validity period, target time window, and unique device identifier in a structured manner, generating a key distribution record containing the hash value of the record information. The key distribution record is then uploaded to the storage chain of the general data platform for notarization using a blockchain writing algorithm. This allows the computing party to use the unique encryption key to perform secure multi-party computation on time-series encrypted data blocks with unique device identifiers within the specified time window during the validity period.

[0043] Compared with the prior art, the beneficial effects of the present invention are:

[0044] This invention addresses the shortcomings of existing technologies by deriving a unique encryption key for each time window, thus overcoming the limitation of static encryption in supporting segmented analysis. This enables multiple institutions to efficiently and securely perform joint computations on encrypted data within a specified time period, avoiding the privacy risks associated with full decryption. Through an automated, lifecycle-triggered secure shredding process, the data itself and its keys are completely destroyed, leaving immutable evidence and ensuring that expired data is unrecoverable, strictly adhering to the principle of minimum data retention. A dynamic authorization strategy binds data access permissions to the reputation and behavior of the computational parties in real time, achieving fine-grained, adaptive access control. This collaborative design, while ensuring high data privacy and relevance, adapts to the high temporal-series analysis requirements, providing secure, reliable, flexible, and efficient underlying technical support for joint research by multiple institutions based on external device monitoring data. Attached Figure Description

[0045] Figure 1 This is a flowchart of the method for time-series encrypted storage and expired data shredding of external device monitoring data according to the present invention;

[0046] Figure 2 This is a logic diagram for obtaining the root key pre-stored in the platform of this invention. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of the embodiments of this application more apparent and understandable, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0048] Please see Figure 1 One embodiment of the present invention provides a method for time-series encrypted storage and expired data shredding of external device monitoring data, comprising:

[0049] S1. Obtain the external device monitoring data stream to be processed, divide the data into segments according to a preset time window, and derive a unique encryption key for each time window data segment.

[0050] S2. Encrypt and store the monitoring data within the corresponding time window based on the derived unique encryption key, and obtain the time-series encrypted data block.

[0051] S3. In response to a joint analysis request initiated by multiple organizations, a unique encryption key corresponding to a specified time window is distributed to the computing parties participating in the joint analysis based on a preset authorization strategy, so that the computing parties can directly perform secure multi-party computation on the time-series encrypted data blocks within the specified time window.

[0052] S4. Monitor the preset lifecycle of each time-series encrypted data block in real time, and automatically trigger the security shredding process when any of the time-series encrypted data blocks reaches the lifecycle period.

[0053] It should be further explained that the secure shredding process in this embodiment includes: erasing the ontological storage content of time-series encrypted data blocks that have reached their lifespan, simultaneously destroying the unique encryption key corresponding to the time-series encrypted data block, generating verifiable evidence of the shredding operation of the time-series encrypted data block, and uploading the verifiable evidence to the storage chain of the general data platform for storage; the storage chain is constructed by combining the root key corresponding to the general data platform, the unique encryption key corresponding to each computing party, and the corresponding reputation score with a blockchain algorithm.

[0054] It should be further explained that one implementation process of the storage chain in this embodiment includes:

[0055] A1. Based on the trustworthiness and functionality requirements of the storage chain in the general data platform, and using the trustworthiness and functionality requirements as input, the system characteristic variables, including storage chain base layer variables, storage chain data layer variables, storage chain consensus layer variables, storage chain initialization seed and computational information writing trigger conditions, are defined and assigned values ​​through variable definition rules. The basic parameter set consisting of the defined and assigned system characteristic variables is then obtained as the output.

[0056] The storage chain base layer variables include a blockchain node list and consensus mechanism parameters. The blockchain node list is limited to trusted computing nodes verified by the general data platform; for example, the preset number of nodes is 5. The consensus mechanism parameters include the voting weight configuration of the practical Byzantine fault-tolerant consensus nodes; for example, the voting weight of the core trusted computing node is configured as 1.2, and the voting weight of the ordinary trusted computing node is configured as 1.0.

[0057] The storage chain data layer variable defines a data block structure as an output variable. This data block structure includes a root key hash value field, a unique encryption key hash value field for the computer, a computer reputation score field, and an operation timestamp field. The root key hash value field is 256 bits long and is generated using the SHA-256 hash algorithm. The unique encryption key hash value field for the computer is associated with the computer's identity and is also 256 bits long. The computer reputation score field ranges from 0 to 100. The operation timestamp field has millisecond precision and follows the ISO 8601 standard.

[0058] The storage chain consensus layer variables include Practical Byzantine Fault-Tolerant Consensus Algorithm (PBT) parameters and block generation interval parameters. The PBT parameters include consensus timeout and a voting pass rate threshold. For example, the consensus timeout is set to 5000 milliseconds, and the voting pass rate threshold is set to two-thirds of the total number of consensus nodes. The block generation interval parameter is set based on the data update frequency, and its value is defined as half of the average data update cycle length. For example, when the average update cycle of data monitored by external devices is 60 seconds, the block generation interval parameter is set to 30 seconds.

[0059] The storage chain initialization seed is generated by the root key of the general data platform using the SHA-256 hash algorithm. After generation, it is encrypted and stored by a hardware security module that conforms to the standards of the International Organization for Standardization and the International Electrotechnical Commission 11889. The storage chain initialization seed is an output variable with a length of 256 bits.

[0060] The trigger condition for writing the computing party information is defined as either the computing party successfully obtaining the key for the first time or the computing party's reputation score being updated. The trigger condition is an output variable. When the trigger condition is the computing party successfully obtaining the key for the first time, a globally unique key distribution record number must be attached. When the trigger condition is the computing party's reputation score being updated, a description of the reason for the score update must be attached. The reason description must include at least "task successfully completed" or "key misuse".

[0061] A2. Based on the storage chain initialization seed and system characteristic variables set in A1, a usable storage chain underlying network is obtained as output through the blockchain node configuration algorithm and the practical Byzantine fault-tolerant consensus parameter initialization algorithm.

[0062] The blockchain node configuration algorithm takes the initial membership requirements of the blockchain node list defined in A1 as input, executes a node hardware security module detection process and an identity authentication process based on X.509 digital certificates, and outputs a list of filtered and certified trusted computing nodes. The hardware security module detection process requires the module to meet FIPS 140-2 Level 3 or a higher security certification level.

[0063] The Practical Byzantine Fault-Tolerant Consensus Parameter Initialization Algorithm takes the Practical Byzantine Fault-Tolerant Consensus Algorithm Parameters and Block Generation Interval Parameters defined in A1 as input, and outputs the configured consensus-related operating parameters.

[0064] The trusted computing node list output by the blockchain node configuration algorithm only includes trusted computing nodes that simultaneously meet the following three conditions: possessing hardware security modules that meet security certification levels, passing identity authentication based on X.509 digital certificates, and having no anomalies in historical storage records over the past 90 days. The number of nodes participating in the practical Byzantine fault-tolerant consensus is set to two-thirds of the total number of trusted computing nodes; this value serves as a preset threshold for consensus success.

[0065] After the underlying network of the storage chain is built, a network node connectivity test algorithm based on Transmission Control Protocol and Internet Protocol is used. The network address information of the trusted computing node list is used as input to send Internet Control Message Protocol request packets and count the round-trip delay and packet loss rate to verify the stability of data transmission between nodes. The network connectivity verification result is output to ensure that the underlying network of the storage chain meets the data interaction requirements.

[0066] A3. The underlying network of the storage chain built on A2 and the root key of the general data platform set in A1 are used to obtain the initialized storage chain as output through the root key hash writing algorithm and the genesis block digital signature algorithm.

[0067] The root key hash writing algorithm integrates the SHA-256 hash algorithm, takes the root key of the general data platform as input, performs hash operation within the hardware security module, and outputs a root key hash value with a length of 256 bits.

[0068] The genesis block digital signature algorithm adopts the elliptic curve digital signature algorithm, specifically using the secp256r1 elliptic curve parameter.

[0069] The specific operations include: invoking the root key hash writing algorithm to obtain the root key hash value as the output; using the root key hash value, the initialization timestamp of the general data platform, and the hash value of the node list of the underlying storage chain network output by A2 as the core data input of the genesis block, and writing it into the underlying storage chain network constructed by A2. Simultaneously, using the root public key of the general data platform to sign the genesis block using the elliptic curve digital signature algorithm, obtaining a digital signature, and associating this signature with the genesis block to complete the initialization of the storage chain.

[0070] A4. When the computing party successfully obtains the key for the first time in the computing party information writing trigger condition defined in A1, based on the preset basic authorization list and the storage chain data layer variable set in A1, the following operations are performed to obtain the encapsulated and verified data unit as output:

[0071] First, the identity identifier of the computing party is retrieved. Using an identity comparison algorithm based on the X.509 digital certificate, a consistency verification is performed with the computing party's identity identifier and the basic authorized list as input. The consistency verification result is output to confirm whether the computing party's identity is within the authorized scope.

[0072] Secondly, after the unique encryption key of the computing party is distributed, the SHA-256 hash algorithm is immediately used to perform the operation with the unique encryption key as input, and outputs a SHA-256 hash value of the key with a length of 256 bits.

[0073] Furthermore, the general data platform uses a comprehensive scoring algorithm to evaluate and output the initial reputation score of the computing party, based on its qualification certificate level, compliance filing status, and historical cooperation records, according to preset rules. The score ranges from 0 to 100.

[0074] Subsequently, using a data encapsulation algorithm, the verified identity of the computing party, the obtained SHA-256 hash value of the key, the assessed initial reputation score, and the current operation timestamp are used as inputs. The data is then integrated and encapsulated according to the data block structure defined by the storage chain data layer variables in A1, and an unverified data unit is output.

[0075] Finally, using the field integrity verification algorithm, the unverified data unit is taken as input to check that each field is complete, the timestamp format conforms to the preset ISO 8601 standard, and the reputation score is within the range of 0 to 100. The verification result is output. If the verification passes, the encapsulated and verified data unit is obtained as the final output.

[0076] A5. Based on the encapsulated and verified data unit obtained in A4 and the trusted computing node list determined and output in A2, a new block is obtained as the output by using a practical Byzantine fault-tolerant consensus algorithm, block generation algorithm, blockchain connection algorithm and chain structure verification algorithm to achieve chain link with the storage chain data layer.

[0077] The specific operation includes: calling the practical Byzantine fault-tolerant consensus algorithm through the block generation algorithm, using the data unit and the trusted computing node list as input, and having the trusted computing nodes perform legality verification on the data unit. The legality verification takes the computing party identity identifier in the data unit and the basic authorized list, as well as the key hash value and key distribution record hash value in the data unit as input, and outputs two sets of verification results: identity consistency and hash consistency.

[0078] After successful verification, the block generation algorithm takes the data unit, the node signature set generated by each consensus node using the elliptic curve digital signature algorithm, and the SHA-256 hash value of the block calculated based on the block content as input, and generates a new block as output.

[0079] The blockchain linking algorithm uses the hash values ​​of the new block and the latest block in the storage chain as input, writes the hash value of the previous block into the header of the new block, and outputs the new block completing the linking operation. After the linking is completed, the chain structure verification algorithm uses the updated storage chain as input to verify the continuity and integrity of the chain structure, outputs the chain structure verification result, and ensures that the new block is legally connected to the storage chain.

[0080] A6. When the computational reputation score update event in the trigger condition for writing computational information as defined in A1 is met, based on the new block generation and linking process of A5, the dynamically updated storage chain is obtained as the output through the reputation score update algorithm, data encapsulation algorithm, practical Byzantine fault-tolerant consensus algorithm and update record association algorithm.

[0081] The specific operation includes: the general data platform uses the reputation score update algorithm, taking the key usage compliance record and analysis result validity record of the computing party as input, and calculates and outputs the updated reputation score according to the predefined addition and subtraction rules.

[0082] Using the data encapsulation algorithm, the identity of the computing party, the updated reputation score, the score update reason description defined by A1, and the current operation timestamp are used as inputs. According to the format requirements of the storage chain data layer variables described in A1, a consensus-pending data unit containing the above information is generated and output.

[0083] Repeatedly execute the practical Byzantine fault-tolerant consensus verification, block generation, and linking operations in A5, using the data unit to be reached as input, and obtain a new block to be linked into the chain as output. In the block generation process, add format verification for the score update reason description field.

[0084] Simultaneously, through the update record association algorithm, the identity identifier in the newly generated data unit and the historical data unit of the computing party in the storage chain are used as input. An association index is established through the identity identifier, and the association relationship record is output to realize the dynamic update and traceability of storage chain data.

[0085] A7. Based on the updated storage chain in A6 and the root key hash value generated in A3, a storage chain query service with data immutability, key element association integrity and query credibility is obtained as output through the storage chain query interface algorithm, identity authentication and permission verification algorithm and query result hash verification algorithm.

[0086] The storage chain query interface algorithm adopts a representation state transition application programming interface architecture and provides query service access points based on the Hypertext Transfer Security Protocol.

[0087] The identity authentication and permission verification algorithm adopts the Open Authorization 2.0 protocol, takes the access token provided by the query requester as input, and outputs the authentication and authorization results by verifying the token signature and permission scope.

[0088] The query result hash verification algorithm uses the SHA-256 hash algorithm.

[0089] The specific operations include: providing query services through the storage chain query interface algorithm, allowing only authorized institutions that have completed authentication and verification through the identity authentication and permission verification algorithm to call this interface. When an authorized institution calls the interface, it can submit a query request to retrieve the root key hash value, the key hash value of any computing party, and their current reputation score from the updated storage chain data layer as the original query result output. During the retrieval process, the query result hash verification algorithm calculates a real-time SHA-256 hash value using the original query result data as input, and compares this real-time SHA-256 hash value with the hash value stored in the corresponding block in the storage chain, outputting the hash comparison result to ensure that the retrieved data has not been tampered with. Finally, based on the original query result and the hash comparison result, the trusted query function of the storage chain is realized.

[0090] It should be further explained that, in this embodiment, the specific process of distributing a unique encryption key corresponding to a specified time window to the computing parties participating in the joint analysis based on a preset authorization strategy, so that the computing parties can directly perform secure multi-party computation on the time-series encrypted data blocks within the specified time window, is as follows:

[0091] B1. Based on the need to initiate joint analysis, participating organizations submit joint analysis request documents to the general data platform.

[0092] The joint analysis request file contains the following input variables:

[0093] The target data time window is formatted as a start timestamp and an end timestamp, with timestamp precision in milliseconds.

[0094] Analyze the requirement type, which is a task type identifier based on secure multi-party computation, such as "lateral federated learning model training" or "cryptographic collaborative reasoning".

[0095] The expected result format defines the output format of the analysis results, such as "encrypted global model parameter file".

[0096] The organization's own qualification certificate is a digital certificate file that contains the organization's identity and complies with the X.509 standard.

[0097] B2. Based on the joint analysis request file received by the general data platform, it is processed through a request verification algorithm.

[0098] The request verification algorithm takes the institutional qualification certificate and request content in the joint analysis request file as input.

[0099] The request verification algorithm verifies the legitimacy of the executing agency's qualifications, specifically by verifying the signature validity and expiration date of the X.509 digital certificate file to ensure that the certificate has not expired or been revoked.

[0100] The request verification algorithm also performs request content compliance verification, specifically verifying that the format of the target data time window is compliant and that the analysis request type belongs to the list of types supported by the platform.

[0101] The request verification algorithm outputs a request verification result, which is either "passed" or "failed".

[0102] If the request verification result is "passed", then perform the following operations:

[0103] Based on the target data time window, all data blocks whose timestamps fall within the window are matched from the stored time-series encrypted data blocks to form a target data block set.

[0104] Invoke the preset authorization policy, using the analysis requirement type and the verified organization identifier as input.

[0105] Based on the authorization strategy, computing providers that simultaneously meet the following conditions are selected from the list of computing providers registered on the platform, forming a candidate computing provider set output. The conditions include:

[0106] First, the analytical qualifications marked by the computing provider in its registration information include the analytical requirement type.

[0107] Second, the current real-time reputation score of the calculation party is not lower than the preset reputation threshold, which is set to 80 points.

[0108] Third, the computing provider has a pre-registered commissioned cooperation relationship with the organization that initiated the request, or its suitability score is determined to be higher than 90 points by the platform matching algorithm. The platform matching algorithm takes the computing provider's historical task success rate and hardware computing power configuration as inputs and outputs a suitability score.

[0109] B3. Based on the candidate computing party set output by B2, the general data platform sends an authorization notification to the computing parties in the candidate computing party set.

[0110] The authorization notification includes the scope of analysis permissions and the data access time limit; the scope of analysis permissions precisely limits the computing party to only access the target data block set formed in B2; the data access time limit is set to a specific duration, such as 72 hours from the time of key distribution.

[0111] After receiving confirmation of receipt of the authorization notification from the computing party, the general data platform distributes a unique encryption key corresponding to the target data time window to the computing party through a key security transmission channel based on TSL 1.3.

[0112] Simultaneously, the application programming interface address for accessing the time-series encrypted data block of the corresponding target is pushed to the computing party.

[0113] B4. Based on the time-series encrypted data block obtained by the computing party through the application programming interface address and the received unique encryption key, the computing party performs computation within its own deployed trusted execution environment, specifically as follows:

[0114] The computing party uses the unique encryption key to decrypt the time-series encrypted data block to obtain the plaintext data.

[0115] The secure multi-party computation takes the plaintext data as input and generates only intermediate computation results that do not contain the original plaintext data during the computation process, such as generating encrypted model gradients in a federated learning scenario.

[0116] The computing party performs secure aggregation processing on the intermediate calculation results within a trusted execution environment, and outputs the final analysis results after the calculation is completed.

[0117] The computing party uses the public key of the general data platform to encrypt the final analysis result, forming an encrypted final result.

[0118] The computing party calculates the SHA-256 hash value of the final encryption result as integrity verification information.

[0119] The computing party uploads the final encrypted result and its integrity verification information as output to the general data platform.

[0120] B5. Based on the final encrypted result and its integrity verification information received by the general data platform, the result integrity verification algorithm is used for processing.

[0121] The result integrity verification algorithm takes the received encrypted final result data and its accompanying SHA-256 hash value as input.

[0122] The result integrity verification algorithm recalculates the SHA-256 hash value of the received encrypted final result data and compares it with the accompanying SHA-256 hash value.

[0123] The result integrity verification algorithm outputs an integrity verification result, which is either "consistent" or "inconsistent".

[0124] If the integrity verification result is "consistent", the general data platform will forward the final encryption result to the participating institution that initiated the request in B1.

[0125] Meanwhile, the general data platform records the entire chain of operation information in a structured manner and generates evidence storage data blocks.

[0126] The input variables included in the evidence storage data block are: the identifier of the organization that initiated the request, the timestamp of the organization that received the result, the identifier of the computing party that performed the calculation, the time point record of the computing party key call, and the task identifier and calculation time of the calculation task in B4.

[0127] The evidence-preserving data block is output and persistently stored by calling a blockchain smart contract to write it into the storage chain of a general data platform.

[0128] B6. Based on the feedback on the validity of the results submitted to the general data platform by the requesting organization after decrypting and obtaining the final analysis results, a reputation assessment is conducted on the computing party that performed the calculation.

[0129] The validity feedback of the results is structured data, including a determination of "valid" or "invalid" and a description of the specific reasons.

[0130] The general data platform processes data using a reputation score update algorithm.

[0131] The reputation score update algorithm takes the result validity feedback, the historical reputation record of the calculating party, and the compliance record of the calculation process stored in B5 as input.

[0132] The reputation score update algorithm calculates and outputs the updated reputation score according to preset rules.

[0133] The default rule example is as follows: if the feedback is "valid" and the process is fully compliant, 5 points will be added to the original reputation score, with a maximum score of 100 points; if the feedback is "invalid" and the reason is the responsibility of the calculation party, 20 points will be deducted from the original reputation score, with a minimum score of 0 points.

[0134] It should be further explained that, in this embodiment, the process of generating only intermediate calculation results that do not contain the original plaintext data includes:

[0135] S201. Based on the security management requirements of the intermediate calculation results of the secure multi-party computation process, a set of intermediate feature variables is set.

[0136] The intermediate feature variables include:

[0137] Intermediate result temporary encryption key is defined as a one-time encryption key derived from the unique encryption key obtained by the computing party. The key length is set to 256 bits, and its purpose is limited to encrypting the intermediate computing results generated in a single computing task. It expires immediately after the computing task is completed.

[0138] The intermediate result transmission channel is defined as a communication channel with end-to-end encryption features dedicated to transmitting encrypted intermediate computation results. This channel is built on TSL 1.3, and the session key of this channel needs to be protected by secondary encryption based on the public keys of the participating collaborative computation parties.

[0139] The intermediate result hashing evidence storage strategy is defined as a security audit strategy. Its core content is to perform SHA-256 hash operation only on the encrypted intermediate calculation result, and submit the 256-bit hash value obtained by the operation along with the relevant context information to the evidence storage system, while prohibiting the transmission or storage of the intermediate calculation result data body.

[0140] The intermediate result destruction trigger condition is defined as a specific event that triggers the deletion operation of intermediate calculation results and related key materials. It includes at least the following two types of events: the event that the computing party successfully generates the final analysis result; and the event that the unique encryption key held by the computing party reaches the preset expiration time, wherein the expiration time is represented by a specific Unix timestamp.

[0141] S202. Based on the unique encryption key already obtained by the computing party, generate an intermediate temporary encryption key through a key derivation function.

[0142] Specifically, the unique encryption key is used as the basic key material, and the identity string of the computing party and the task identifier string of the current computing task are used as derived parameters to call the HMAC-based key derivation function for processing.

[0143] The HMAC-based key derivation function uses the HKDF-SHA-256 algorithm, taking the basic key material and derivation parameters as input, and outputs a 256-bit derivation key, which is the intermediate result temporary encryption key.

[0144] The temporary encryption key for the generated intermediate results must be immediately stored in the protected key storage area of ​​the computing party's hardware security module. The plaintext form of this key is prohibited from being stored or transmitted outside the hardware security module.

[0145] S203. Based on the intermediate result temporary encryption key generated in S202, encrypt the intermediate results generated during the calculation process.

[0146] Specifically, the computing party executes a secure multi-party computation algorithm in its trusted computing environment to generate plaintext intermediate result data.

[0147] Subsequently, an encryption algorithm based on the Galois counter mode of the Advanced Encryption Standard is invoked, using the temporary encryption key of the output intermediate result as the encryption key, to encrypt the intermediate result data of the plaintext. The encryption algorithm adopts the AES-256-GCM mode.

[0148] The encryption operation outputs two results: the first result is the encrypted data ciphertext, i.e., the intermediate encryption result; the second result is an authentication label used to verify the integrity and authenticity of the data, which is 128 bits long.

[0149] S204. Based on the encrypted intermediate results and authentication tags output by S203, select whether to securely transmit them or securely store them locally, depending on the type of computing task.

[0150] The task type judgment logic determines whether the current computing task is a multi-party collaborative computing task or a single-party computing task.

[0151] If the task is determined to be a multi-party collaborative computing task, the encrypted intermediate results and authentication tags are sent to other participating computing parties through a secure transmission channel. The secure transmission channel is built based on TSL 1.3 and uses the public keys of all participating computing parties to perform secondary encryption protection on the channel's session key. The public key algorithm is RSA-2048 or ECCsecp256r1.

[0152] If the task is determined to be a one-party computation task, the encrypted intermediate results and authentication tags will be stored directly in the trusted storage area on the computation party's local machine. Access to this storage area will be restricted to authorized processes related to secure multi-party computation.

[0153] S205. Based on the encrypted intermediate results output by S203, generate the corresponding evidence storage record and upload it.

[0154] The SHA-256 hash algorithm is invoked, and the encrypted intermediate result is used as input data to perform a hash operation, outputting a hash value of length 256 bits, which is used as the intermediate result hash value.

[0155] The intermediate result hash value, the identity identifier of the computing party that generated the intermediate result, the task identifier of the current computing task, and the intermediate result generation timestamp accurate to milliseconds are combined and encapsulated into a single evidence data unit.

[0156] By calling the application programming interface for evidence storage provided by the general data platform, the evidence storage data unit is submitted as input to the storage chain for immutable evidence storage. This process does not involve uploading the encrypted intermediate result ontology.

[0157] S206. When the "event in which the computing party completes the final analysis result" in the intermediate result destruction trigger condition defined in S201 is met, the destruction operation of the intermediate result and related key materials is performed.

[0158] The computing party locates and deletes the following three pieces of data through a local destruction procedure: the temporary encryption key for intermediate results stored in the hardware security module, the encrypted intermediate results stored in the local trusted storage area, and the authentication tag associated with the encrypted intermediate results.

[0159] After the destruction operation is completed, an intermediate result destruction record is generated. This record contains the task identifier of the current computing task and a destruction operation timestamp accurate to milliseconds. This destruction record is then encrypted using the platform's public key and uploaded to the general data platform storage chain, and associated with the evidence storage data unit generated in S205 through the task identifier.

[0160] S207. When the "unique encryption key reaches the preset expiration time" event in the intermediate result destruction triggering condition defined in S201 is met, and the relevant computing task has not yet been completed, the intermediate result destruction is remotely triggered by the general data platform.

[0161] The general data platform sends a digitally signed remote destruction instruction to the corresponding computing party. This instruction contains the task identifier of the computing task, and the signing algorithm is the elliptic curve digital signature algorithm.

[0162] Upon receiving the instruction, the computing party first verifies the validity of the digital signature attached to the instruction. Once the verification is successful, it immediately executes the same local destruction procedure as S206, forcibly deleting the intermediate result temporary encryption key, encrypted intermediate result, and authentication tag associated with the task identifier, to ensure that the intermediate computation result is not retained after the key expires.

[0163] In this embodiment, a unique encryption key is derived for each time window data segment, including:

[0164] A101. Based on the external device type and data sampling frequency, a suitable preset time window duration is obtained through a weighted linear regression algorithm; it should be further explained that one implementation process of the weighted linear regression algorithm in this embodiment includes:

[0165] Based on the current external device type to be processed, and the preset mapping table between external device types and weight coefficients, a query operation is performed.

[0166] The query operation takes the external device type as input, searches for the weight coefficient value that uniquely corresponds to the corresponding type in the mapping table, and outputs the found value as the weight coefficient of the external device type.

[0167] The mapping table between external device types and weight coefficients is a predefined static configuration table; for example, in this table, the weight coefficient associated with medical monitoring devices is set to 1.2; the weight coefficient associated with industrial sensor devices is set to 1.0; and the weight coefficient associated with civil environmental monitoring devices is set to 0.8.

[0168] Based on the sampling frequency of the current external device monitoring data, and the pre-set table of correspondence between sampling frequency intervals and weight coefficients, interval matching and coefficient extraction operations are performed.

[0169] The interval matching and coefficient extraction operation takes the value of the sampling frequency as input, compares it with multiple frequency intervals defined in the correspondence table, determines the target interval to which the sampling frequency belongs, and outputs the weight coefficient value of the target interval as the data sampling frequency weight coefficient.

[0170] The table showing the correspondence between sampling frequency ranges and weighting coefficients is a predefined static configuration table. For example, in this table, a sampling frequency greater than or equal to 100 times per second is defined as a high-frequency range, and the associated weighting coefficient is set to 1.1; a sampling frequency between 10 times per second and 100 times per second is defined as a mid-frequency range, and the associated weighting coefficient is set to 1.0; a sampling frequency less than 10 times per second is defined as a low-frequency range, and the associated weighting coefficient is set to 0.9.

[0171] The comprehensive weight coefficient is obtained by weighting the output external device type weight coefficient, the output data sampling frequency weight coefficient, and a preset weight ratio parameter.

[0172] The preset weighting percentage parameter is used to characterize the relative importance of the equipment type factor in the comprehensive calculation. Its value is set to 0.6, that is, the equipment type is given a weight of 60%.

[0173] The specific process of the weighted calculation is as follows: multiply the weight coefficient of the external device type by 0.6 to obtain the first weighted value; multiply the weight coefficient of the data sampling frequency by 0.4, i.e., 1-0.6, to obtain the second weighted value; finally, add the first weighted value and the second weighted value together, and the sum is the comprehensive weight coefficient.

[0174] The initial time window duration is calculated using a multiplication operation based on a preset base time window duration and the output comprehensive weight coefficient.

[0175] The basic time window duration is a baseline value preset according to the general needs of the system, and its specific value is set to 3600 seconds.

[0176] The multiplication operation takes the base time window duration (3600 seconds) and the comprehensive weight coefficient as input, multiplies the two, and the resulting product is the initial time window duration.

[0177] Based on the initial time window duration, a preset lower limit for the time window duration, and a preset upper limit for the time window duration, the final time window duration is determined through boundary comparison and adjustment operations.

[0178] The lower limit of the time window duration is set to 300 seconds, and the upper limit of the time window duration is set to 14400 seconds.

[0179] The boundary comparison and adjustment operation compares the initial time window duration with 300 seconds and 14400 seconds, respectively.

[0180] If the initial time window duration is greater than 14400 seconds, then 14400 seconds will be output as the final time window duration.

[0181] If the initial time window duration is less than 300 seconds, then 300 seconds will be output as the final time window duration.

[0182] If the initial time window duration is greater than or equal to 300 seconds and less than or equal to 14400 seconds, then the initial time window duration will be directly output as the final time window duration.

[0183] The final time window duration is the preset time window duration used to divide the data segments.

[0184] A102. Based on the preset time window duration and combined with external device monitoring data, a timestamp is generated, and the monitoring data segment corresponding to each time window is obtained through a data stream sliding algorithm.

[0185] It should be further explained that one specific implementation of the data flow sliding algorithm in this embodiment is as follows:

[0186] Based on the need to balance data integrity and storage efficiency during data stream partitioning, a set of data characteristic variables are defined. These data characteristic variables include: external device data sampling period, data redundancy tolerance, historical data overlap rate threshold, basic sliding step size, and adjusted sliding step size.

[0187] The external device data sampling period refers to the time interval between two consecutive data collections by the external device, measured in seconds.

[0188] The data redundancy tolerance is a preset proportional threshold used to limit the maximum overlap of monitoring data allowed between two adjacent time windows. Its value ranges from 0 to 1, with a specific example being 0.3.

[0189] The historical data overlap rate threshold is a reference ratio threshold derived from the statistics of actual data overlap within a historical time period. It is used to characterize the minimum reasonable overlap level for maintaining data integrity, and its value is lower than the data redundancy tolerance. A specific example of a value is 0.1.

[0190] The basic sliding step size is the time window movement interval calculated based on the data sampling period of the external device.

[0191] The adjusted sliding step size is the optimized and finalized time window movement interval used in actual division.

[0192] The external device data sampling period is calculated based on the timestamp sequence generated from external device monitoring data. The calculation process is as follows: obtain the timestamps of all monitoring data generation within a preset statistical duration, and count the total number of timestamps within that duration; divide the preset statistical duration by the total number of timestamps, and the quotient obtained is the external device data sampling period. For example, if 600 data points are collected within a 60-second statistical duration, the sampling period is 0.1 seconds.

[0193] The basic sliding step size is calculated based on the calculated external device data sampling period and a preset minimum data block size.

[0194] The minimum data size of the preset data block is a lower limit set for the amount of data within a single time window to ensure the effectiveness of subsequent analysis, such as 1000 data records.

[0195] The calculation process for the basic sliding step size is as follows: First, multiply the minimum data size of the preset data block by the data sampling period of the external device to obtain a theoretical data block duration. Then, multiply a preset data size coefficient greater than 1 by the data sampling period of the external device to obtain the basic sliding step size. The data size coefficient in this embodiment is set to make the data size within the window divided by this step size approach the minimum data size of the preset data block; a specific numerical example is 1.2. Therefore, the basic sliding step size is equal to the data sampling period of the external device multiplied by this data size coefficient. The theoretical data block duration in this embodiment is calculated by multiplying the preset minimum data block size by the external device's data sampling period. The core implementation logic is as follows: using the preset minimum data block size as the basic data size benchmark for data block division, combined with the fixed data sampling period of the external device, the ideal time length required to meet the minimum data size benchmark is obtained through multiplication operations, which is the theoretical data block duration. This theoretical data block duration does not directly participate in the final calculation of the basic sliding step size, but provides a clear technical anchor for setting the data size coefficient, so that the value of the data size coefficient can be accurately set around the goal of "making the data size within the window divided according to the basic sliding step size approach the preset minimum data size", ensuring that the design of the basic sliding step size has a reasonable technical derivation basis, rather than being blindly selected.

[0196] Based on a preset time window duration and a calculated basic sliding step size, the theoretical overlap ratio of adjacent time windows is calculated. The calculation process is as follows: subtract the basic sliding step size from the preset time window duration to obtain the difference; divide this difference by the preset time window duration, and the quotient obtained is the theoretical overlap ratio.

[0197] Based on the calculated theoretical overlap ratio, the data redundancy tolerance, and the historical data overlap rate threshold, the basic sliding step size is adjusted to obtain the adjusted sliding step size.

[0198] The adjustment process follows these logical judgments and operations:

[0199] First, determine whether the theoretical overlap ratio is greater than the data redundancy tolerance; if so, increase the basic sliding step size by a preset adjustment value to obtain the adjusted sliding step size. The preset adjustment value is a fixed time increment, such as 0.1 seconds. This operation aims to reduce excessive data overlap.

[0200] If the determination is negative, then it is further determined whether the theoretical overlap ratio is less than the historical data overlap rate threshold.

[0201] If the second judgment is yes, then the basic sliding step size is reduced by the preset adjustment value to obtain the adjusted sliding step size. This operation aims to avoid data omissions that may be caused by insufficient data overlap.

[0202] If the second judgment is negative, that is, if the theoretical overlap ratio is between the historical data overlap rate threshold and the data redundancy tolerance, then the basic sliding step size is kept unchanged and directly used as the adjusted sliding step size.

[0203] The adjusted sliding step size is dynamically updated based on a preset periodic update cycle; the periodic update cycle is a preset time interval, such as 24 hours.

[0204] At the arrival of each update cycle, the external device data sampling cycle is recalculated based on the new timestamp data, and the statistical value of the historical data overlap rate threshold is updated using recent historical data. Then, the adjusted sliding step size is recalculated and updated. This mechanism ensures that the sliding step size can continuously adapt to the changes in the external device data sampling characteristics and maintain an optimal balance between redundancy and integrity in the division of monitoring data segments.

[0205] A103. Based on the unique external device identifier corresponding to each time window monitoring data segment, the time window start stamp, and the root key pre-stored on the general data platform, initial key material is obtained through SHA-256 hash operation. The unique external device identifier ensures that the monitoring data segment keys for different devices are not duplicated, and the time window start stamp ensures that the monitoring data segment keys for the same device in different time windows are not duplicated. For example, in this embodiment, the unique external device identifier is a 16-byte ASCII encoded string, such as "Device_7B3A9F". The time window start stamp is a Unix timestamp with millisecond precision and a length of 13 digits, such as "1672531200000" representing 2023-01-01 00:00:00.000. The root key pre-stored on the general data platform is a 32-byte cryptographic key generated through a key derivation function. The specific process for obtaining the initial key material is as follows: First, the string of the unique identifier of the external device, the string of the start stamp of the time window, and the binary data of the root key are concatenated in sequence to form the original input data; then, the SHA-256 hash algorithm is called, and the original input data is used as the only input to perform a hash operation; the algorithm outputs a fixed-length binary data of 32 bytes, which is the initial key material.

[0206] A104. Based on the initial key material and the key fragments pre-allocated by each participating institution, a unique encryption key for each time window data segment is obtained through the Shamir secret sharing algorithm.

[0207] Further explanation is needed; please refer to [link / reference]. Figure 2 The process of obtaining the root key pre-stored in the general data platform in this embodiment includes:

[0208] Based on the combined hash value of the core hardware identifier of the general data platform, the unique identifier list of the initially connected external devices, and the initialization timestamp of the general data platform, a 256-bit initial random number is generated using a cryptographically secure random number generator.

[0209] Based on the SHA-256 hash value of the initial random number and the core hardware identifier, the combined SHA-256 hash value of the external device unique identifier list, and the SHA-256 hash value of the general data platform initialization timestamp, key expansion is performed through the HKDF key derivation function to obtain a 256-bit root key. It should be further explained that the specific process of key expansion through the HKDF key derivation function in this embodiment includes:

[0210] B101. Based on the first hash value, the second hash value, and the third hash value, the input key material is obtained through a sequential concatenation operation.

[0211] The first hash value is a 32-byte hash value calculated using the SHA-256 hash algorithm to obtain the core hardware identifier. The second hash value is a 32-byte combined hash value calculated using the SHA-256 hash algorithm to obtain the unique identifier list of external devices. The third hash value is a 32-byte hash value calculated using the SHA-256 hash algorithm to obtain the initialization timestamp of the general data platform. The sequential concatenation operation involves concatenating the first, second, and third hash values ​​in a predetermined order to form a binary data block with a total length of 96 bytes. This data block is the input key material.

[0212] B102. Based on a predefined salt value, input key material, and a fixed context information string, a pseudo-random key is obtained through an extraction phase operation based on a key derivation function.

[0213] The salt value is a cryptographically secure random number with a length of 32 bytes.

[0214] The context information string is a preset ASCII encoded string used to identify the purpose of the key, such as "EXTERNAL_DEVICE_DATA_ROOT_KEY", which means "external device data root key";

[0215] The extraction phase operation invokes the configured HMAC-SHA256 message authentication code algorithm, using the salt value as the key and the input key material as the message, to perform a message authentication code calculation. This function outputs a pseudo-random key of 32 bytes.

[0216] B103, based on the pseudo-random key obtained from B102, the defined context information string, and the preset key length requirement, the root key is obtained through an expansion phase operation based on the key derivation function. The preset key length requirement is 256 bits, or 32 bytes. The expansion phase operation is executed iteratively according to the following steps:

[0217] Initialize an empty output key material byte array; set a counter with an initial value of 1.

[0218] The loop process proceeds as follows: First, using the pseudo-random key as the key, concatenate the current counter's single-byte representation, the context information string byte array, and the block data generated in the previous iteration (this item is empty in the first iteration) to form a message. Then, call the SHA-256 hash function to calculate and generate a 32-byte block data. Next, append this block data to the output key material byte array; then, increment the counter value; repeat this process until the total length of the output key material byte array is greater than or equal to 32 bytes.

[0219] Finally, the first 32 bytes of the output key material byte array are extracted to form a 32-byte binary data, which is the 256-bit root key.

[0220] Based on the 256-bit root key, it is split into a preset number of key fragments using the Shamir secret sharing algorithm and distributed to multiple trusted nodes of the general data platform for storage. At the same time, the root key is hashed using the SHA-256 hash algorithm to generate a root key hash value, and the root key hash value is written into the storage chain for evidence preservation.

[0221] It should be further explained that the process of obtaining trusted nodes in this embodiment includes:

[0222] Based on the node admission criteria preset by the general data platform, the initial qualified candidate nodes are screened through automated detection of candidate node information; wherein, the node admission criteria include technical requirements for four aspects: hardware security module configuration, network isolation measures, access control rules, and log auditing system.

[0223] Among them, the hardware security module configuration requirement is that the node must be equipped with a certified hardware security module that meets the FIPS 140-2 Level 3 or higher security level.

[0224] Network isolation measures require that the network where the node is located must deploy firewalls and intrusion detection systems, and that the production network must be physically or logically isolated from the office network.

[0225] Access control rules require that the node operating system enable role-based access control policies and minimize access permissions for the root directory and critical system files.

[0226] The log auditing system requires nodes to deploy centralized log recording functions. The log content must include operation time, subject, object and result information, and have the ability to retain logs for no less than 90 days.

[0227] The automated detection is achieved by running a preset configuration check script and a security baseline verification tool. The detection takes the network address and security access credentials of the candidate node as input, performs remote detection, and outputs a detection report containing the compliance judgment results of various technologies. Only when the compliance judgment results of all key technology items in the detection report are positive, the corresponding candidate node is included in the initial qualified candidate node list, and the initial qualified candidate node list is output.

[0228] Based on the output initial list of qualified candidate nodes, the legitimacy of the node's identity is confirmed by cryptographically verifying the identity credentials submitted by the node.

[0229] The identity credentials include an X.509 format digital certificate issued by an authoritative certificate authority, and a unique device identifier code pre-written into the node's hardware security module.

[0230] The verification process specifically includes: First, verifying the signature validity of the node digital certificate using the root certificate of the certificate authority and checking its validity period; second, verifying whether the subject name or subject alternative name field recorded in the digital certificate is completely consistent with the node identity information pre-registered on the platform; and finally, verifying the cryptographic signature assertion generated by the node hardware security module, which contains its unique device identifier.

[0231] Only when all of the above verifications are successfully passed will the node be determined as a legitimate node and output to the list of nodes whose identity has been verified.

[0232] The authentication based on the output is performed through a list of nodes. By simulating real business loads and abnormal scenarios, the continuous service capability of the nodes is tested.

[0233] The test continuously simulates the following three core scenarios:

[0234] Data storage scenario simulation: Continuously send encrypted data packets to the node under test, requiring it to run continuously for 24 hours under a load of no less than 1,000 write operations per second, and verify the integrity of all written data.

[0235] Data access scenario simulation: During storage testing, concurrent random data read requests are initiated, requiring nodes to process no less than 500 read operations per second while maintaining data consistency.

[0236] Abnormal recovery scenario simulation: During the test, simulated network interruption, abnormal process termination or storage transient failure is randomly triggered, requiring the critical processes of the node to restart and restore services within 30 seconds.

[0237] The testing process is executed by an automated testing platform, which records and outputs the node's performance metrics, error rate, and recovery time in various scenarios. Only when a node's performance in all test scenarios meets the preset performance and stability thresholds is it ultimately included in the trusted node list. This method, through a progressive three-layer screening mechanism of qualification review, identity authentication, and security and stability testing, systematically constructs a set of trusted nodes that are compliant in technical configuration, authentic and trustworthy in identity, and continuously stable in service capabilities. This provides a solid infrastructure guarantee for the platform's subsequent secure key storage and reliable computing tasks.

[0238] It should be further explained that the steps for splitting using the Shamir secret sharing algorithm in this embodiment include:

[0239] Based on the 256-bit root key, the preset total number of key fragments, and the key reconstruction threshold, the secret sharing algorithm is initialized through parameter configuration operations.

[0240] The preset total number of key fragments is an integer greater than 1, used to determine how many independent key fragments the root key will be split into. A specific example value is 5.

[0241] The key reconstruction threshold is an integer less than or equal to the preset total number of key fragments and greater than 1, used to determine the minimum number of key fragments required to reconstruct the original root key. A specific numerical example is 3.

[0242] The parameter configuration operation is used to set two core parameters required for the algorithm to run: the polynomial order and the finite field parameter. The polynomial order is set to the number of key reconstruction thresholds minus 1. The finite field parameter is set to a sufficiently large prime number, whose value must be greater than the value of the 256-bit root key and the total number of preset key fragments, to ensure that all operations are reversible and secure within the finite field defined by this prime number. A typical example is choosing a prime number greater than 2 to the power of 256. After completing this step, an initialized, parameterized secret sharing algorithm instance is obtained.

[0243] Based on the initial secret sharing algorithm example, the 256-bit root key is converted into multiple key fragments through key splitting operations.

[0244] The key splitting operation uses a 256-bit root key as the secret value to be split. The specific operation process is as follows: First, a random polynomial is constructed, with the constant term of the polynomial set as the secret value, i.e., the value corresponding to the 256-bit root key. Second, the order of this polynomial is consistent with the polynomial order set in the parameter configuration operation, and the coefficients of its terms higher than the first degree are all non-zero values ​​randomly selected within the finite field parameter range preset in the parameter configuration operation. Then, an input parameter is assigned to each key fragment to be generated. This input parameter must satisfy the condition that it is non-zero and distinct within the finite field. A common implementation method is to use consecutive natural numbers starting from 1 as input parameters. Finally, each selected input parameter is substituted into the random polynomial for calculation to obtain the corresponding polynomial output value. Each input parameter and its corresponding polynomial output value form a pair, which is an independent key fragment. Through the above process, a set of key fragments equal to the preset total number of key fragments can be generated.

[0245] Based on the generated key fragment set, management metadata is attached to each key fragment through an identifier generation operation, forming an identifiable key fragment set.

[0246] The identifier generation operation specifically involves assigning a globally unique key fragment identifier to each generated key fragment. This identifier is structured data and associates at least the following three pieces of information:

[0247] The first item is the fragment number, which indicates the order of the fragment in the overall set, such as an integer starting from 1.

[0248] The second item is the shard generation timestamp, which records the moment the shard was created. The timestamp accuracy is at least in milliseconds.

[0249] The third item is the corresponding node adaptation information, which records the identity code or network address of the target trusted node to be distributed or stored in the sharding plan.

[0250] By binding the above identification information with the corresponding key fragment data, a set of key fragments with identification is obtained.

[0251] The method first configures the key parameters of the secret sharing algorithm, then uses the algorithm to split the core secret, the root key, into multiple mathematically related fragments, and finally attaches a unique identifier containing management information to each fragment, thereby transforming a single key secret into a set of distributed data units with clear reconstruction conditions that are easy to securely distribute, store and manage.

[0252] It should be further explained that, in this embodiment, the key fragmentation and distribution to multiple trusted nodes of the general data platform for storage includes:

[0253] Based on the hardware storage performance indicators and network transmission stability indicators of each node in the trusted node list, the key fragmentation storage adaptability of each trusted node is quantitatively scored through a capability assessment operation.

[0254] The hardware storage performance indicators include at least the storage medium type, sequential write speed, and storage capacity, and the network transmission stability indicators include at least network latency, packet loss rate, and recent service availability.

[0255] The capability assessment operation specifically involves calculating a comprehensive score for each trusted node. This score is obtained by weighted summing of the hardware storage performance score and the network transmission stability score. The hardware storage performance score is calculated based on a comparison of the node's hardware storage performance indicators with a preset benchmark value, while the network transmission stability score is calculated based on the node's historical network transmission stability statistics. The weighting coefficients can be configured according to the system's different emphases on storage performance and network stability, for example, both can be set to 0.5. The output result is a key sharding storage adaptability score for each trusted node.

[0256] Based on the obtained key fragment storage adaptability score and the set of identified key fragments to be distributed, the key fragments are bound one by one to trusted nodes through the allocation operation.

[0257] The allocation operation follows these rules: First, the list of trusted nodes is sorted from highest to lowest based on their key fragment storage compatibility score. Second, the key fragments in the identified key fragment set are sequentially allocated to the top N trusted nodes with the highest scores, where N equals the total number of key fragments. During allocation, it is ensured that each trusted node receives and stores at most one independent key fragment. Finally, a mapping table between key fragments and trusted nodes is output.

[0258] Based on the output key fragment and trusted node mapping table, key fragment deployment is completed through secure transmission and storage operations.

[0259] The secure transmission operation employs end-to-end encryption, specifically: the public key of the target trusted node is used to encrypt the key fragment data to be transmitted, forming encrypted fragment data packets, which are then transmitted to the node through a secure channel.

[0260] The storage operation is performed locally by the trusted node. Specifically, after receiving the encrypted fragmented data packet, the node decrypts it using its own private key to recover the plaintext key fragment. It then immediately imports this plaintext key fragment into its local hardware security module, where it performs internal encryption and secure storage. After storage is complete, the node deletes the plaintext key fragment from memory.

[0261] Based on the completed key fragment storage operation, the integrity of the storage is confirmed through verification and evidence preservation operations, and an immutable record is generated.

[0262] The verification process involves sending a storage verification command to each trusted node that has stored key fragments. Upon receiving the command, each node reads the stored encrypted fragment data from its hardware security module, calculates the cryptographic hash value of the data (e.g., a SHA-256 hash value), and returns it as the storage hash value. The sender compares the received storage hash value with the original fragment hash value calculated locally before transmission. If they match, a successful key fragment storage verification result is generated; otherwise, a failure result is generated.

[0263] The evidence storage operation is performed based on the storage verification results: each storage record is written to the storage chain of the general data platform. Each storage record contains at least the following fields: the unique identifier of the stored key fragment, the trusted node information storing the key fragment, the timestamp of the fragment storage completion, and the storage verification result of the key fragment. This operation completes the traceability record of the entire key fragment storage process.

[0264] Based on the request to reconstruct the root key, key fragments are obtained from trusted nodes by calling operations.

[0265] The specific invocation operation involves sending a key fragment extraction command to all trusted nodes that store the key fragments corresponding to the target root key. The extraction command includes authorization information digitally signed by the platform. After verifying the validity of the command signature, each trusted node securely extracts the stored key fragment from its local hardware security module, encrypts the fragment using the requester's public key or session key, and returns the encrypted fragment data.

[0266] Based on the returned encrypted fragment data, valid key fragments are filtered out through receiving and verification operations.

[0267] The receiving and verification operation is specifically as follows: First, each received encrypted fragment data is decrypted. Second, the integrity of each decrypted fragment is verified, for example, by checking its attached message authentication code. Finally, the identification information of each fragment is checked to confirm that it belongs to the fragment set of the target root key, and the fragments that pass the integrity verification and have the correct identification are marked as valid key fragments.

[0268] Based on the collected valid key fragments, the original root key is recovered using a secret sharing reconstruction algorithm. Specifically, the process involves checking whether the number of collected valid key fragments reaches or exceeds the preset key reconstruction threshold number when the root key was split. If the condition is met, these valid key fragments are used as input to execute the secret sharing reconstruction algorithm. This algorithm reconstructs the original 256-bit root key value using polynomial interpolation based on the input parameters and output values ​​contained in the fragments, and outputs this value.

[0269] Based on the reconstructed 256-bit root key, its integrity and correctness are verified through hash comparison operations.

[0270] The hash comparison operation is as follows: First, using the same hash algorithm as when the key was generated, such as the SHA-256 hash algorithm, the reconstructed 256-bit root key is calculated to obtain its real-time hash value. Second, the original hash value of the 256-bit root key, which was stored during its initial generation, is retrieved from the storage chain of the general data platform. Finally, the calculated real-time hash value is compared with the original hash value retrieved from the storage chain. If the two hash values ​​are completely identical, the reconstructed 256-bit root key is determined to be usable; if they are inconsistent, the reconstruction is deemed to have failed, and an error handling process is triggered.

[0271] Intelligent allocation is achieved by assessing node capabilities, and end-to-end encryption and hardware secure storage ensure the security of shard transmission and silent operation. Storage verification and blockchain notarization enable auditability and traceability of operations. By securely collecting shards, verifying shard validity, reconstructing keys based on thresholds, and finally verifying the integrity and authenticity of the reconstructed keys by comparing the hash values ​​of on-chain notarization, a closed-loop security management system is formed, from key splitting and distributed storage to secure reconstruction and integrity verification.

[0272] It should be further explained that the subsequent use process of writing the root key hash value into the storage chain for evidence preservation in this embodiment includes:

[0273] Based on the unique root key identifier corresponding to the reconstructed root key that needs to be verified, the evidence storage record associated with the root key identifier is obtained by calling the storage chain access interface of the general data platform.

[0274] Extract the pre-stored root key hash value with a length of 256 bits from the evidence storage record and output it as the evidence storage root key hash value.

[0275] Based on multiple valid key fragments belonging to the same target root key collected from distributed trusted nodes, the root key is reconstructed and hashed.

[0276] First, check the number of collected key fragments. The number of collected key fragments must reach or exceed the preset key reconstruction threshold. This threshold is a positive integer that is less than the preset total number of key fragments and greater than 1. For example, in an implementation with a total number of fragments of 5, the threshold can be set to 3.

[0277] Next, the collected valid key fragments are used as input and processed using the Shamir secret sharing reconstruction algorithm. The algorithm outputs a 256-bit binary data, which is the reconstructed root key.

[0278] Finally, using the reconstructed root key as input data, the SHA-256 hash function is called to perform a hash operation. This operation outputs a 256-bit hash value, which serves as the real-time hash value of the reconstructed root key.

[0279] Based on the obtained evidence root key hash value and the generated real-time hash value, a consistency comparison operation is performed, including: the comparison operation compares the two 256-bit hash values ​​bit by bit; if each bit of the two hash values ​​is exactly the same, a binary comparison result indicating "verification passed" is output, such as the boolean value "true"; if the two hash values ​​differ in any bit, a binary comparison result indicating "verification failed" is output, such as the boolean value "false".

[0280] Based on the output hash comparison result, the integrity status of the reconstructed root key is determined, and subsequent operations are performed accordingly.

[0281] If the received hash comparison result is "verification passed", the reconstructed root key is determined to be complete, authentic, and usable. This key is identified as a usable 256-bit root key for use in subsequent key derivation operations.

[0282] If the received hash comparison result is "verification failed," it is determined that the integrity of the reconstructed root key has been compromised. This anomaly may be caused by the key fragments being tampered with or damaged during transmission or storage. In this case, a preset anomaly handling procedure is immediately triggered. The anomaly handling procedure includes at least the following two operations: First, re-collect key fragments from the relevant trusted nodes and repeat the key fragment reconstruction, root key generation, and hash verification process to obtain a valid and usable root key; Second, initiate anomaly detection and security audit procedures for the trusted nodes that provide the key fragments to investigate whether the nodes have been compromised, have had their data tampered with, or face other security risks.

[0283] This process provides a terminal verification mechanism for the core key reconstruction process by rigorously comparing the original stored hash value of the root key obtained from an immutable storage chain with the real-time hash value of the root key reconstructed based on distributed key fragmentation. This method effectively addresses the security risk of reconstructing incorrect keys due to component failures or attacks in distributed key management scenarios, thereby ensuring the security and reliability of the entire subsequent cryptographic application system based on this root key.

[0284] It should be further explained that in this embodiment, the monitoring data within the corresponding time window is encrypted and stored based on the derived unique encryption key, including:

[0285] C101. Based on the unique encryption key derived from the monitoring data segment of the corresponding time window and the unique identifier of the external device associated with the corresponding time window and the start stamp of the time window, the monitoring data segment is encrypted using a symmetric encryption algorithm and the unique identifier of the external device and the start stamp of the time window are embedded synchronously to obtain the encrypted data.

[0286] It should be further explained that the specific implementation steps of the symmetric encryption algorithm in this embodiment include:

[0287] Based on the monitoring data segment to be encrypted, the unique identifier of the associated external device, and the start stamp of the time window, perform data preparation operations to obtain the initial data to be encrypted.

[0288] The data preparation operation includes: First, converting the monitoring data segment, the unique identifier of the external device, and the start stamp of the time window into a byte array format to obtain standardized data; Second, concatenating the byte array of the unique identifier of the external device and the byte array of the start stamp of the time window before the byte array of the monitoring data segment in a preset fixed order to form a continuous byte array as the initial data to be encrypted, wherein the unique identifier of the external device is an ASCII encoded string with a length of 16 bytes, and the start stamp of the time window is a 13-bit Unix timestamp.

[0289] Based on the requirements of encryption security and data processing efficiency, the complete parameter configuration of the symmetric encryption algorithm is obtained through algorithm selection and parameter matching.

[0290] The algorithm selection and parameter matching operation is performed according to the following logic:

[0291] Algorithm type selection includes: choosing a symmetric encryption algorithm based on the required level of encryption security. If the requirement level is high, choose the Advanced Encryption Standard (AES) algorithm with a 256-bit key length; if the requirement level is medium, choose the AES algorithm with a 128-bit key length; if it is a resource-constrained scenario, choose the ChaCha20 stream cipher algorithm.

[0292] The encryption mode selection involves choosing an encryption mode based on the selected algorithm type and the requirements for data integrity and parallel processing. If high security and data integrity authentication are required, the Galois counter mode should be selected; if high parallel processing efficiency is required, the counter mode should be selected; and if basic security is required, the cipher block chaining mode should be selected.

[0293] The padding method selection includes choosing the padding method based on the selected encryption mode and the length characteristics of the data to be encrypted. If the encryption mode is cipher block chaining and the data length is not fixed, then PKCS7 padding is selected; if the data length is a fixed value and is an integer multiple of the algorithm block size, then no padding is selected.

[0294] Based on the obtained symmetric encryption algorithm parameter configuration and the unique encryption key derived for this data segment, the encryption operation environment is initialized, and an initialized encryptor instance is obtained.

[0295] The initialization process for the encryption operation environment includes the following steps: First, calling a cryptographically secure random number generator to generate a random number with the same length as the selected encryption mode as the encryption vector. For example, for the Galois counter mode, the encryption vector length is usually 96 bits. Second, importing the unique encryption key according to the requirements of the selected algorithm to complete the key configuration. Finally, using the encryption vector to initialize the encryption algorithm instance with the configured key, obtaining an initialized encryptor instance, ready to perform encryption operations.

[0296] Based on the initial data to be encrypted and the initialized encryptor instance, perform encryption operations and data encapsulation to obtain the final encrypted data.

[0297] The encryption operation and data encapsulation include: calling an initialized encryptor instance, taking the initial data to be encrypted as input, performing an encryption operation, and outputting the encrypted data body; associating and encapsulating the generated encryption vector with the encrypted data body, with the encapsulation format being that the encryption vector is placed before the encrypted data body, together forming a complete encrypted data packet.

[0298] This process constructs a clear encrypted object by standardizing and spatiotemporally assembling monitoring data and its identifiers; dynamically configures the encryption algorithm, mode, and padding method based on security and efficiency requirements through a system decision-making logic; initializes the key and vector according to cryptographic best practices; and finally executes encryption and encapsulates the output ciphertext data packet, thus achieving a unity of data security, processing efficiency, and structural standardization.

[0299] C102. Based on the encrypted data and the composite index constructed by the unique identifier of the external device and the start stamp of the time window, a storage operation is performed through the storage chain of the general data platform to obtain the associated storage record of the encrypted data and the composite index;

[0300] C103. Based on the association storage records of encrypted data and composite indexes, and the association identifier of unique encryption keys, time-series encrypted data blocks are obtained through association analysis algorithms;

[0301] The time-series encrypted data block includes at least: a device unique identifier for identifying the external device to which the time-series encrypted data block belongs, a time window start stamp for distinguishing different time windows under the same external device, and a joint index for quickly locating the corresponding time window during joint analysis.

[0302] It should be further explained that the authorization policy construction process in this embodiment includes:

[0303] D101. Based on the identity identifiers, qualification certificate types, and initial reputation scores based on historical compliance records of the computing parties participating in the joint analysis, a preset dynamic identity qualification mapping is performed to obtain a basic authorization list; the basic authorization list at least includes the association between the computing party identity identifiers and qualification certificate types.

[0304] It should be further explained that one method for constructing a basic authorization list includes:

[0305] Based on the registration information submitted by the computing party applying to participate in the joint analysis and the historical records stored on the platform, the core information tuple of the computing party is obtained.

[0306] The core information tuple includes the following three data items:

[0307] The first item is the computing party's identity identifier, a unique string assigned to the platform, such as a UUID with a length of 16 bytes.

[0308] The second item is the type of qualification certificate, which is obtained by parsing the electronic qualification documents submitted by the computing party. This type corresponds to a predefined classification code, such as "National-level Confidentiality Assessment Institution" or "Industry Data Security Certification Enterprise".

[0309] The third item is the initial reputation score, which is obtained by querying the platform's database. This score is an integer between 0 and 100, calculated based on the historical task completion status of the computing party.

[0310] Based on the type of qualification certificate obtained, verification is performed according to preset qualification validity rules to generate a qualification verification result. The verification includes two checks:

[0311] First, check whether the qualification certificate type belongs to the list of qualification types recognized by the platform and conforming to industry standards. This list is a predefined static list. Second, verify whether the qualification is currently valid, not expired, and not revoked by calling the certificate status query interface of the authoritative institution.

[0312] If both of the above checks pass, a verification result of "qualification valid" will be generated; otherwise, a verification result of "qualification invalid" will be generated.

[0313] Based on the obtained initial reputation score and a preset reputation threshold, a reputation compliance judgment is performed to generate a reputation assessment result. The preset reputation threshold is a fixed integer value, such as 80 points. The reputation compliance judgment logic is as follows: the initial reputation score is compared with the preset reputation threshold. If the initial reputation score is greater than or equal to the preset reputation threshold, an assessment result of "reputation qualified" is generated. If the initial reputation score is less than the preset reputation threshold, an assessment result of "reputation unqualified" is generated.

[0314] Based on the obtained computing party identity and qualification certificate type, the generated qualification verification results, and the generated reputation assessment results, filtering and association operations are performed to generate a basic authorized list.

[0315] The rules for the screening and association operations are as follows: the calculation is only included in the authorized scope when both the qualification verification result is "qualified" and the credit assessment result is "creditworthy".

[0316] For each computing provider that meets the above criteria, create a record in the basic authorized list. This record must contain at least two fields: the first field is the computing provider's identity identifier, and the second field is the associated qualification certificate type. Repeat this process to enter information for all eligible computing providers, ultimately forming a complete basic authorized list.

[0317] This process systematically collects the identity, qualifications, and historical reputation data of computing providers, and sequentially performs qualification verification based on industry standards and timeliness, and reputation compliance judgment based on fixed thresholds. In the end, only computing providers with valid qualifications and compliant reputation are associated and recorded, thereby constructing a basic authorized list that has undergone double filtering, is credible and compliant, and provides a reliable original basis for subsequent fine-grained authorization.

[0318] D102. Based on the qualification certificate type, initial reputation score, and unique identifier of external device of each computing party in the basic authorization list, the range of unique identifiers of external devices that each computing party can access is defined by a dynamic permission mapping algorithm to obtain the association rule between the computing party's identity identifier and the range of unique identifiers of external devices; wherein the size of the unique identifier range is adjusted by combining the preset basic range size with the ratio of the real-time reputation score of the corresponding computing party to the preset accessible reputation score threshold.

[0319] D103. Based on the association rules between the computing party's identity identifier and the unique identifier range of the external device, the start stamp of the time window, and the historical data access frequency, a dynamic time window interval for each computing party to obtain the key is set through a dynamic time window authorization algorithm; the dynamic time window interval is adjusted according to the magnitude of the historical data access frequency of each computing party. The specific implementation method is as follows:

[0320] D1031. Based on the computing party's identity identifier and the preset association rules between the computing party's identity identifier and the unique identifier range of external devices, perform data extraction and statistical operations to obtain the computing party's historical data access frequency.

[0321] The data extraction and statistical operations are as follows: First, based on the association rules, determine the unique set of identifiers for specific external devices that the computing party is authorized to access. Second, extract all data access records of the computing party to the unique set of identifiers for specific external devices within a preset historical statistical period from the access log database of the general data platform. For example, the preset historical statistical period is 30 days. Finally, obtain the historical data access frequency through frequency calculation, count the total number of access records, divide it by the total duration of the historical statistical period, and obtain the average number of accesses per unit time, which is output as the historical data access frequency, with the unit being "times / hour". For example, if the total number of accesses in 30 days is 720, then the historical data access frequency is 1 time / hour.

[0322] D1032. Based on the obtained historical data access frequency, a preset base time window length, and a set of preset frequency adjustment mapping rules, calculate the base length of the dynamic time window.

[0323] The preset base time window length is an initial value set according to the regular data analysis cycle, such as 24 hours.

[0324] The frequency adjustment mapping rule defines the length adjustment coefficient corresponding to different access frequency ranges. For example, when the access frequency is greater than or equal to 10 times / hour, the length adjustment coefficient is 1.2; when the access frequency is between 2 times / hour and 10 times / hour, the length adjustment coefficient is 1.0; and when the access frequency is less than 2 times / hour, the length adjustment coefficient is 0.8.

[0325] The calculation process is as follows: based on the historical data access frequency, query the frequency adjustment mapping rule, determine the corresponding length adjustment coefficient, multiply the basic time window length by the length adjustment coefficient, and the resulting product is the basic length of the dynamic time window.

[0326] D1033. Based on the starting timestamp of the target time window to be authorized access and the historical access time distribution characteristics of the calculation method within the historical statistical period, the starting point is calibrated.

[0327] The specific operation involves analyzing historical data access records to identify the continuous time periods during which the computing entity's access behavior is most concentrated, i.e., the historical peak access periods. For example, statistics show that the computing entity's access volume is highest between 9:00 AM and 12:00 PM every day.

[0328] Subsequently, the start timestamp of the target time window is adjusted to the start time of the nearest future historical peak access period. For example, if the target start time is 2 PM on a certain day, and the peak period is from 9 AM to 12 PM, it is calibrated to 9 AM on the next calendar day. This calibrated time point serves as the calibrated start time of the dynamic time window.

[0329] D1034. Based on the base length of the dynamic time window and the start time after calibration, calculate the end time of the dynamic time window to form the dynamic time window interval.

[0330] The calculation method is as follows: add the base length of the dynamic time window to the calibrated start time, and the result is the end time of the dynamic time window.

[0331] In addition, a periodic update mechanism is set up, such as automatically triggering an update process every 7 days. During each update, D1031 to D1034 are re-executed, and the dynamic time window interval is recalculated and updated based on the latest historical data access records of the computing party, ensuring that it always matches the actual access pattern of the computing party.

[0332] This process dynamically adjusts the length of the authorization window by analyzing the historical access frequency of the computing party and calibrates the starting position of the window according to its access habits, thereby generating a dynamic time window interval that is highly adapted to the actual usage pattern of the computing party. This method, combined with periodic recalculation, achieves adaptive optimization of the authorization strategy, improving the rationality and efficiency of data access while ensuring security control.

[0333] D104. Based on the dynamic time window interval of each computing party's key acquisition, real-time reputation score, and historical key usage compliance score, the validity period of the unique encryption key is configured through a dynamic key validity configuration algorithm to obtain the correspondence rule between the computing party's identity and the validity period of the unique encryption key; the length of the validity period of the unique encryption key is proportional to the real-time reputation score and historical key usage compliance score of each computing party; the specific implementation method is as follows:

[0334] Based on the target computing party's identity, the platform database is queried to obtain the authorization configuration and behavior evaluation data associated with that computing party. The query operation uses the computing party's identity as input and retrieves and outputs the following three data items from the database: the dynamic time window range authorized for the computing party, which includes the start and end timestamps; the computing party's current real-time reputation score, which is an integer between 0 and 100; and the computing party's historical key usage compliance score, which is an integer between 0 and 100, calculated based on the audit results of its past key usage records.

[0335] Based on a dynamic time window interval, the validity period of a basic key is calculated as follows: First, subtract the start timestamp from the end timestamp of the dynamic time window interval to obtain the total duration of the interval in seconds. Second, multiply the total duration of the interval by 0.5, i.e., take half of it, to obtain the number of seconds of the validity period of the basic key.

[0336] A comprehensive score is obtained by weighting the real-time reputation score and the historical key usage compliance score. The weighting calculation is performed according to the following formula: Comprehensive score = Real-time reputation score × Reputation weight coefficient + Historical key usage compliance score × Compliance weight coefficient.

[0337] The reputation weight coefficient and compliance weight coefficient are preset constants, and their sum is 1. For example, the reputation weight coefficient can be set to 0.6, and the compliance weight coefficient can be set to 0.4. The calculated comprehensive score is still a value between 0 and 100.

[0338] Based on the calculated comprehensive score and a predefined mapping table between score ranges and adjustment coefficients, the corresponding validity period adjustment coefficient is queried and determined.

[0339] The mapping table defines the validity period adjustment coefficients corresponding to different comprehensive score ranges. These coefficients are real numbers greater than zero, and the principle is that the higher the comprehensive score, the larger the corresponding validity period adjustment coefficient. For example, the following can be set: a comprehensive score greater than or equal to 90 points, the adjustment coefficient is 1.5; a comprehensive score between 70 and 90 points, the adjustment coefficient is 1.2; a comprehensive score between 60 and 70 points, the adjustment coefficient is 1; and a comprehensive score below 60 points, the adjustment coefficient is 0.8.

[0340] Based on the calculated validity period of the base key and the determined validity period adjustment coefficient, the validity period of the final unique encryption key is calculated. This calculation is accomplished through multiplication: the value of the validity period of the base key is multiplied by the value of the validity period adjustment coefficient, and the resulting product is the number of seconds of the unique encryption key's validity period.

[0341] Based on the computing party's identity identifier and the validity period of the unique encryption key, a key validity period authorization rule for the computing party is generated, which associates and stores the computing party's identity identifier with the validity period of the unique encryption key.

[0342] In addition, a regular update mechanism should be established, for example, once every 24 hours. Each update involves retrieving the latest real-time reputation score and historical key usage compliance score of the computing party, and recalculating and updating the validity period of the unique encryption key associated with that computing party's identity.

[0343] This process, based on the computing party's authorized timeframe, real-time reputation, and historical compliance behavior, dynamically determines and periodically updates the key's validity period through a set of quantitative calculation logic. This method directly links the key's lifecycle to the computing party's trustworthiness and behavior, enabling personalized and dynamic adjustments to security policies.

[0344] D105. Based on the basic authorized list, the association rules between the computing party's identity and the unique identifier of the external device, the binding relationship between the computing party's identity and the dynamic time window interval, and the corresponding rules between the computing party's identity and the validity period of the unique encryption key, a request verification rule is generated through a dynamic rule integration algorithm to obtain a dynamically adjusted preset authorization strategy.

[0345] The request verification rules require the submission of the computing party's identity identifier, joint analysis project filing information, target time window, and corresponding external device unique identifier. The request verification rules are automatically updated as the computing party's real-time reputation score and historical behavior data change.

[0346] This process ensures compliance by dynamically mapping identity qualifications to the basic authorization list, which includes only qualified and reputable computing entities. It defines the access scope of external devices based on qualifications and reputation, achieving precise matching between device permissions and computing entity capabilities to prevent unauthorized access. A dynamic time window is set based on historical access frequency to align authorization time with the actual needs of computing entities, reducing invalid authorizations. Dynamic key validity periods are configured based on real-time reputation and key usage compliance, enhancing key management security. Finally, dynamic rules are integrated to generate an authorization policy that automatically updates with the real-time status and historical behavior of computing entities. This achieves refined and dynamic management of permissions, prevents unauthorized access risks through multi-dimensional verification, and ensures the flexibility and security of joint analysis, forming a fully controllable and adaptable authorization system.

[0347] It should be further explained that, in this embodiment, the distribution of a unique encryption key corresponding to a specified time window to the computing parties participating in the joint analysis based on a preset authorization strategy includes:

[0348] E101. Based on a joint analysis request initiated by multiple organizations, the request parsing algorithm configured on the general data platform is used to extract the identifiers of each participating organization, the joint analysis project filing information, the common target time window, and the range of unique identifiers of associated equipment contained in the joint analysis request to obtain the request data to be verified. In this embodiment, the request parsing algorithm configured on the general data platform extracts the following specific variables from the joint analysis request initiated by multiple organizations to constitute the request data to be verified: the identifier variables of each participating organization, including the unique code and organization name of each organization; the joint analysis project filing information variables, including the project unique identifier, filing number, project status, and filing date; the common target time window variables, including the start and end timestamps of the time window; and the range of unique identifiers of associated equipment variables, including the list of unique identifiers of equipment and equipment type information.

[0349] E102. Based on the identifiers of each participating organization in the request data to be verified and the basic authorization list in the preset authorization policy, the identifiers of each participating organization and the qualification certificate types of each organization are verified by the federated identity verification algorithm based on X.509 certificates. At the same time, the correlation between the joint analysis project filing information and the equipment data corresponding to the unique identifier range of the associated equipment is verified by the joint project compliance verification algorithm to obtain the multi-organization joint identity verification result.

[0350] It should be further explained that the implementation process of the federated authentication algorithm based on X.509 certificates in this embodiment includes:

[0351] Based on the request data to be verified, the identifiers of all participating organizations are obtained through an organization identifier extraction algorithm.

[0352] Based on the participating institution identifiers and the basic authorized list, the list matching algorithm is used to check whether each participating institution identifier exists in the basic authorized list, and a list matching result is generated.

[0353] Based on the qualification certificate type corresponding to the participating organization's identifier, the qualification certificate type recorded in the basic authorized list, and the qualification certificate type matching rules, the qualification type comparison algorithm verifies whether the two meet the matching rules and generates a qualification matching result.

[0354] Based on the list matching results and qualification matching results, a single-institutional identity verification result is generated for each participating institution through a single-institutional verification algorithm. If all results are passed, the verification is considered successful; otherwise, the verification is considered unsuccessful.

[0355] Based on the authentication results of all single-institutional organizations, a multi-institutional collaborative algorithm is used to determine whether all participating institutions have passed the authentication. If all of them pass, the authentication is successful; otherwise, it is a failure, and the multi-institutional collaborative authentication result is obtained.

[0356] Based on the request data to be verified, the joint analysis project filing information is obtained through the filing information extraction algorithm, and the range of unique identifiers of associated devices is obtained through the device identifier set extraction algorithm.

[0357] Based on the range of unique identifiers of associated devices and the device data attribute library, the applicable scenarios of the device data type corresponding to each unique identifier of device are obtained through the device attribute query algorithm, and the set of associated device data attributes is obtained.

[0358] Based on the analysis purpose data usage, associated equipment data attribute set and correlation matching rules in the joint analysis project filing information, the correlation degree verification algorithm verifies whether the project analysis purpose matches the equipment data type and whether the project data usage is within the scope of the equipment's applicable scenario, and generates correlation matching results.

[0359] Based on the correlation matching results, a compliance verification result is generated through a compliance judgment algorithm;

[0360] Based on the results of multi-organization collaborative verification and compliance verification, the two conclusions are merged through a joint verification algorithm. If both are passed, the multi-organization joint identity verification result is considered successful; otherwise, it is considered a failure, thus obtaining the multi-organization joint identity verification result.

[0361] Among them, the basic authorized list refers to the list of institutions whose identities and qualifications meet the authorization conditions after dynamic identity and qualification mapping; the qualification certificate type matching rule refers to the correspondence between the qualifications required for different joint analysis projects and the qualifications actually possessed by the institutions; the equipment data attribute library refers to the database that stores the equipment data type and applicable scenarios corresponding to the unique identifier of each equipment; the correlation matching rule refers to the correlation conditions that the analysis purpose data use in the project filing information and the equipment data attributes should meet.

[0362] E103. When the multi-organization joint authentication result is passed, the association rules between the unique identifier range of the associated device in the request data to be verified and the identity identifier of each participating organization and the unique identifier range of the external device in the preset authorization policy are combined. The intersection of the unique identifier range of the external device of each participating organization is calculated by the multi-organization permission intersection algorithm to determine the unique identifier range of the device accessed by the joint analysis. The unique identifier range of the device accessed by the joint analysis is determined by the permission boundary verification algorithm. The external device permission verification result is obtained.

[0363] E104. When the external device permission verification result is within the range, combine the target time window in the request data to be verified and the binding relationship between the calculation party identity and the dynamic time window interval in the preset authorization policy. Use the time window matching algorithm to check whether the start timestamp of the target time window is later than the authorization start timestamp of the dynamic time window interval and whether the end timestamp of the target time window is earlier than the authorization end timestamp of the dynamic time window interval to obtain the time window verification result.

[0364] E105. When the time window verification result meets the matching threshold, the following operations are performed using the key reconstruction status query algorithm:

[0365] Extract the key shard index table corresponding to the target time window, send a key shard submission command carrying the start stamp of the time window to the participating institutions recorded in the key shard index table, receive the key shards and shard signatures returned by the participating institutions, verify the validity of the shard signatures using the ECDSA digital signature verification algorithm with the participating institutions' preset public key, compare the received shard numbers with the shard numbers recorded in the key shard index table using a shard number matching algorithm, filter out the valid key shards that have passed the double verification, count the number of valid key shards using a shard count algorithm, compare the counted number with a preset number threshold, if the counted number is not less than the preset number threshold, perform a joint operation on the valid key shards using the Shamir secret sharing reconstruction algorithm to generate a unique encryption key candidate value, compare the unique encryption key candidate value with the joint hash value of the device unique identifier and the start stamp of the time window using a key verification algorithm, if the verification is successful, the result is that the key availability is usable.

[0366] E106. When the key availability result is available, the corresponding rules of the computing party's identity identifier and the validity period of the unique encryption key in the preset authorization policy, as well as the real-time reputation score and historical key usage compliance score of the corresponding computing party, are combined. The validity period of the unique encryption key is calculated by the key validity generation algorithm according to the weighted ratio of the real-time reputation score and the historical key usage compliance score. A unique encryption key with a specified time window and a validity period restriction is generated. The unique encryption key is associated with the device's unique identifier and the time window start stamp by the association binding algorithm to obtain the key package to be distributed.

[0367] E107. Based on the key packet to be distributed, the key packet is transmitted to the computing party through an encrypted transmission channel. At the same time, the computing party's identity, distribution time, key validity period, target time window, and device unique identifier are recorded in a structured manner using a log structured recording algorithm. A key distribution record containing the hash value of the record information is generated. The key distribution record is uploaded to the storage chain of the general data platform for notarization using a blockchain writing algorithm. This allows the computing party to use the unique encryption key to perform secure multi-party computation on time-series encrypted data blocks with the unique identifier of the associated device within the specified time window during the validity period.

[0368] E108. Based on a unique encryption key with a specified time window and the public key certificate of the computing party, the unique encryption key is encrypted using an asymmetric encryption algorithm to generate encrypted key ciphertext. Based on the encrypted key ciphertext, the hash value of the device's unique identifier, and the hash value of the time window start stamp, the key package body is formed by concatenating the data according to a preset format using a data encapsulation algorithm. The key package body is then signed using the computing party's public key to generate a signed key package.

[0369] E109. Based on the identity certificates of the general data platform and the computing party, a two-way certified encrypted transmission channel is established through the TLS handshake protocol to verify the validity and revocation status of the certificates of both parties, negotiate the session key, and ensure the confidentiality and integrity of the channel transmission.

[0370] E110. After receiving the key packet, the computing party decrypts the key packet signature with its local private key, verifies the matching of the signature with the public key of the general data platform, and verifies the consistency of the hash value of the device's unique identifier with the start stamp of the time window through a hash comparison algorithm to confirm that the key packet has not been tampered with.

[0371] E111. The computing party stores the decrypted unique encryption key in a protected memory area through a hardware security module, sets access control policies, and only allows the secure multi-party computing process to read it within the validity period, and prohibits the key from being exported to external storage media.

[0372] E112. The general data platform starts a key usage timer, compares the current time with the expiration time of the key usage validity period in real time, and sends a notification to the computing party that the key is about to expire before the expiration time (such as 1 hour), reminding them to complete the calculation in time.

[0373] E113. During the use of the key by the computing party, the key call time, associated data access operations, and intermediate result generation records are recorded through behavior monitoring algorithms. A usage status report is generated every hour and uploaded to the general data platform storage chain.

[0374] E114. If it is detected that the computing party has not used the key within the key validity period or has used it beyond the authorized scope, a revocation instruction is sent to the computing party through the key remote revocation algorithm. After receiving the instruction, the computing party immediately deletes the key stored locally, and the general data platform updates the key status in the storage chain to revoked.

[0375] E115. After the computing party completes the secure multi-party computation, it autonomously deletes the unique encryption key stored locally through the key destruction algorithm, generates a key destruction certificate, which includes the destruction time and device identifier, and uploads it to the general data platform in encryption. The platform will associate the certificate with the key distribution record for evidence storage, forming a closed-loop record of the key's entire lifecycle.

[0376] For example, suppose three hospitals (Hospital A, Hospital B, and Hospital C) plan to jointly conduct a retrospective analysis of specific electrocardiogram (ECG) monitoring devices. Hospital A (with a Class A tertiary qualification) acts as the lead party and submits a joint analysis request to the general data platform. The target time window is from October 1st to October 7th, 2023, and the request is to access ECG data from devices identified as D1, D2, D3, D4, and D5. After receiving the request, the platform first performs joint identity verification: confirming that all three hospitals are on the basic authorized list and that their "medical data analysis" qualifications match the project. At the same time, it verifies that the purpose of the project, "arrhythmia analysis," is consistent with the type of ECG data and the clinical research scenario, and the verification is successful. Subsequently, the intersection of access permissions is calculated: assuming Institute A can access devices {D1, D2, D3, D4}, Institute B can access {D2, D3, D4, D5}, and Institute C can access {D1, D3, D4}, the final intersection is {D3, D4}. Based on this, the platform determines that devices D1, D2, and D5 in the request exceed the shared scope and requires the requester to reduce the access target to {D3, D4}. Next, it verifies whether the target time window is within the dynamic range authorized by the computing party (such as a third-party data analysis company). If successful, the platform collects fragments from the nodes storing key fragments for that time period (i.e., Institutes A, B, and C). After collecting at least 3 valid fragments, a unique encryption key is reconstructed. Based on the computing party's real-time reputation score of 85 and historical compliance score of 90, the platform calculates a comprehensive score of 87, with a weight of 0.6 for the real-time reputation score and 0.4 for the historical compliance score, and dynamically sets the key validity period to 14.4 hours accordingly. The platform uses the computer's RSA public key to encrypt the key and securely distributes it via a TLS 1.3 channel, while simultaneously storing the distribution record on the blockchain. The computer decrypts and uses the key in its hardware security module, completing the federated learning computation within 14.4 hours. The platform monitors key usage throughout the process. After computation, the computer destroys the key and uploads the proof, forming a closed loop.

[0377] This example demonstrates a complete multi-institutional secure collaborative analysis process: starting with requests from three hospitals, it goes through rigorous joint identity and compliance verification, device permission intersection calculation, dynamic time window authorization verification, to the secure reconstruction of keys based on secret sharing, and dynamically setting the key validity period (14.4 hours) according to the reputation and behavior of the computing parties. Finally, it is distributed through an encrypted channel, monitored throughout the process, and destroyed after use. This enables data to be used securely, compliantly, and auditably for collaborative computing without leaving the platform, ensuring the privacy of the original data and the traceability of the computing process.

[0378] It should be further explained that this embodiment provides a process for determining the preset lifecycle of a time-series encrypted data block, including:

[0379] Step 1: Set encryption feature variables, including data sensitivity level weight, industry compliance retention period, historical access frequency, initial lifespan, and adjustment coefficient. The data sensitivity level weight refers to a preset weight value corresponding to the data sensitivity level; the higher the data sensitivity level, the larger the weight value. For example, the weight value of medical monitoring data is higher than that of civilian environmental monitoring data. The industry compliance retention period refers to the minimum retention time determined by the regulations of the industry to which the time-series encrypted data block belongs. The historical access frequency refers to the number of times the time-series encrypted data block is accessed per unit time after storage. The initial lifespan refers to the basic data retention time calculated based on the data sensitivity level weight and the industry compliance retention period. The adjustment coefficient is a proportional coefficient determined based on the historical access frequency and used to adjust the initial lifespan; a coefficient value greater than 1 extends the lifespan, less than 1 shortens the lifespan, and equal to 1 keeps the lifespan unchanged.

[0380] Step 2: Obtain the external device type and data content corresponding to the time-series encrypted data block. Analyze the application scenario corresponding to the external device type (e.g., medical devices for medical scenarios, civilian monitoring devices for civilian scenarios) and the sensitive information contained in the data content (e.g., whether it involves personal privacy or core business data) through the data sensitivity level determination algorithm. Determine the data sensitivity level of the time-series encrypted data block. Then, extract the data sensitivity level weight corresponding to the data sensitivity level according to the preset sensitivity level and weight correspondence.

[0381] Step 3: Based on the determined data sensitivity level of the time-series encrypted data block and the industry to which the data block belongs, call the industry regulatory database through the compliance period query algorithm, retrieve the minimum data retention period corresponding to the data of the sensitivity level in the industry, and determine the period as the industry compliance retention period;

[0382] Step 4: Based on the extracted data sensitivity level weight and the obtained industry compliance retention period, the industry compliance retention period is multiplied by the data sensitivity level weight using the initial lifecycle calculation algorithm to obtain the initial lifecycle. The data sensitivity level weight should be set such that the higher the sensitivity level, the larger the weight value, to ensure that the initial lifecycle of highly sensitive data is not less than the industry compliance retention period and is appropriately extended, and the initial lifecycle of low-sensitivity data is not less than the industry compliance retention period.

[0383] Step 5: Obtain all access records after the time-series encrypted data block is stored. Use the access frequency statistics algorithm to count the total number of times the data block is accessed within a preset statistical period (e.g., the last 30 days). Divide the total number of times by the duration of the statistical period to calculate the number of times the data is accessed per unit time. Determine this number as the historical access frequency.

[0384] Step 6: Set a preset access frequency threshold. The preset access frequency threshold is a critical value set based on the industry's typical data access situation to distinguish the popularity of data access. Based on the calculated historical access frequency and the preset access frequency threshold, the algorithm execution judgment is determined by adjusting the coefficient: if the historical access frequency is higher than the preset access frequency threshold, the adjustment coefficient is set to be greater than 1; if the historical access frequency is lower than the preset access frequency threshold, the adjustment coefficient is set to be less than 1; if the historical access frequency is equal to the preset access frequency threshold, the adjustment coefficient is set to 1.

[0385] Step 7: Set a periodic update cycle. The periodic update cycle refers to the time interval set to adapt the lifecycle of the time-series encrypted data block to changes in access requirements, such as monthly. Within each periodic update cycle, based on the obtained initial lifecycle and the adjustment coefficient determined in S6, the initial lifecycle is multiplied by the adjustment coefficient using a dynamic lifecycle update algorithm to calculate the new lifecycle. At the same time, it is verified whether the new lifecycle is not less than the obtained industry compliance retention period. If the new lifecycle is not less than the industry compliance retention period, the new lifecycle is determined as the final lifecycle of the time-series encrypted data block. If the new lifecycle is less than the industry compliance retention period, the industry compliance retention period is determined as the final lifecycle. This ensures that the lifecycle of the time-series encrypted data block not only meets industry compliance requirements but can also be dynamically adjusted based on actual access requirements. This avoids invalid storage occupation due to an excessively long lifecycle or premature data destruction due to an excessively short lifecycle, which would fail to meet subsequent access requirements.

[0386] This process deeply integrates data sensitivity levels with industry compliance requirements, calculating the initial lifecycle based on the weight of each sensitivity level. This ensures that the lifecycle of highly sensitive data is not less than the compliance period and is appropriately extended, while low-sensitivity data also meets the compliance baseline. This fundamentally avoids legal risks caused by non-compliance in the lifecycle, while achieving differentiated adaptation of data security protection. By introducing historical access frequency and adjustment coefficients, the lifecycle of high-access-frequency data is extended to ensure subsequent analysis needs, while the lifecycle of low-access-frequency data is shortened to reduce invalid storage occupation. This accurately matches the actual data usage needs, avoiding resource waste and analysis interruptions caused by premature data destruction. By dynamically adjusting the lifecycle through regular update cycles, combined with a compliance period verification mechanism, this ensures that the data lifecycle is always within a reasonable range of "above the compliance baseline and within the requirements." It will not become invalid due to the inability of a fixed lifecycle to adapt to changes in access needs, and it will continuously comply with updated industry regulations. Ultimately, this achieves a multi-dimensional balance of data compliance, security, resource utilization efficiency, and access convenience, providing a scientific and flexible solution for the full lifecycle management of time-series encrypted data blocks.

[0387] It should be further explained that the process of erasing the storage content of the time-series encrypted data block that has reached its lifespan, and simultaneously destroying the unique encryption key corresponding to the time-series encrypted data block in this embodiment, includes:

[0388] Based on the monitoring results of the time-series encrypted data block reaching the preset lifespan period, the storage address of the time-series encrypted data block is obtained through the distributed storage module of the general data platform;

[0389] Based on the storage address, the DoD5220.22-M multi-round random overwrite algorithm is used to perform erase operations in blocks according to the corresponding physical storage sectors. Each round generates a random byte stream to overwrite the original data in the sector, and at least three rounds are executed. Specifically, the first round generates a 0x00 byte stream to overwrite the target sector, the second round generates a 0xFF byte stream to overwrite the same sector, and the third round generates a 128-bit random byte stream to overwrite the sector. After each round of overwriting, the storage controller confirms that the write was successful.

[0390] Based on the erased storage sectors, the WinHex data recovery detection algorithm scans the original binary data of the sectors, compares it with the encryption signature of the data blocks before erasure, confirms that there is no matching signature and that the valid data structure cannot be identified, and obtains the result of erasure of the storage content.

[0391] When the erasure operation is initiated, based on the Shamir secret sharing fragment information corresponding to the unique encryption key of the time-series encrypted data block, a key fragment invalidation instruction carrying the unique device identifier and the start stamp of the time window is sent to all participating institutions holding the key fragment through the encrypted communication channel. Based on the instruction, the key management module of the participating institution marks the corresponding fragment as invalid and deletes it from the local cache. The smart contract is called through the general data platform storage chain to record the fragment invalidation status of each participating institution and obtain the unique encryption key fragment invalidation result.

[0392] Based on the results of erasing the ontology storage content and invalidating the fragmented unique encryption key, the storage sector scan log and feedback information from participating institutions are hashed using the SHA-256 hash algorithm to obtain the hash value as the core data for verifiable evidence storage, ensuring that there are no remnants in the ontology storage content and that the unique encryption key cannot be reconstructed through fragmentation.

[0393] For example, in this embodiment, the general data platform detected that a group of time-series encrypted data blocks generated by a medical sensor with the unique device identifier HOSP_CT_DEV_001 within the time window from 08:00:00 to 12:00:00 on October 1, 2023, had reached their preset 7-day lifespan. The platform's distributed storage module located the data block in four consecutive storage sectors (512 bytes per sector) starting at physical address 0x3A7F2C1D. The erasure process was then initiated: in the first round, a stream of all zero bytes (0x00) was written to the target sector to overwrite it; in the second round, a stream of all one bytes (0xFF) was written to overwrite it; in the third round, a 128-bit random byte stream generated by a cryptographically secure random number generator was written to overwrite it. After each round of overwriting, the storage controller returned a confirmation of successful write. After the overwrite is completed, the platform calls the underlying tools to scan the original binary data of these sectors, confirming that the original AES-GCM encrypted data signature has completely disappeared and there is no recognizable data structure, obtaining the result that "the original storage content has been erased". Simultaneously, the platform sends a key fragment invalidation instruction to the three partner hospitals holding the key corresponding to this data block via a TLS 1.3 encrypted channel. The instruction explicitly includes the device's unique identifier HOSP_CT_DEV_001 and the time window start stamp 2023-10-01 08:00:00. Upon receiving the key fragment invalidation instruction, each hospital's key management module immediately marks the corresponding key fragment in its local storage as invalid and deletes it from the hardware security module cache, and records "invalidation performed" on the storage chain via a smart contract. Finally, the platform concatenates the sector scan log of this erasure operation with the invalidation confirmation information returned by the three hospitals, calculates its SHA-256 hash value, and uses this hash value as the core evidence of this secure shredding operation, permanently recording it in the storage chain.

[0394] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments under the guidance of the present invention without departing from the spirit and scope of the claims. All of these variations are within the protection scope of the present invention.

[0395] If the technical solution disclosed herein involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution disclosed herein involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

Claims

1. A method for time-series encrypted storage and expired data shredding of external device monitoring data, characterized in that, include: Acquire the external device monitoring data stream to be processed, divide the data into segments according to a preset time window, and derive a unique encryption key for each time window data segment; The monitoring data within the corresponding time window is encrypted and stored based on the derived unique encryption key to obtain the time-series encrypted data block. In response to a joint analysis request initiated by multiple organizations, a unique encryption key corresponding to a specified time window is distributed to the computing parties participating in the joint analysis based on a preset authorization strategy. This allows the computing parties to directly perform secure multi-party computation on time-series encrypted data blocks within the specified time window. The organizations and computing parties are either in one-to-one or one-to-many correspondence. The preset lifecycle of each time-series encrypted data block is monitored in real time, and a secure shredding process is automatically triggered when any of the time-series encrypted data blocks reaches the lifecycle period. The secure shredding process includes: erasing the storage content of time-series encrypted data blocks that have reached their lifecycle period, simultaneously destroying the unique encryption key corresponding to the time-series encrypted data block, generating verifiable evidence of the shredding operation of the time-series encrypted data block, and uploading the verifiable evidence to the storage chain of the general data platform for storage; the storage chain is constructed by combining the root key corresponding to the general data platform, the unique encryption key corresponding to each computing party, and the corresponding reputation score with a blockchain algorithm; The process of constructing the authorization policy includes: Based on the identity identifiers, qualification certificate types, and initial reputation scores based on historical compliance records of the computing parties participating in the joint analysis, a preset dynamic identity qualification mapping is performed to obtain a basic authorization list; the basic authorization list at least includes the association between computing party identity identifiers and qualification certificate types; Based on the qualification certificate type, initial reputation score, and unique external device identifier of each computing party in the basic authorized list, the range of unique external device identifiers accessed by each computing party is defined by a dynamic permission mapping algorithm, and the association rule between the computing party's identity identifier and the range of unique external device identifiers is obtained; wherein the size of the unique identifier range is adjusted by combining the preset basic range size with the ratio of the corresponding computing party's real-time reputation score to the preset accessible reputation score threshold. Based on the association rules between the computing party's identity and the unique identifier of the external device, the start stamp of the time window, and the historical data access frequency, a dynamic time window interval for each computing party to obtain the key is set through a dynamic time window authorization algorithm; the dynamic time window interval is adjusted according to the magnitude of the historical data access frequency of each computing party.

2. The method for time-series encrypted storage and expired data shredding of external device monitoring data as described in claim 1, characterized in that, The process of deriving a unique encryption key for each time window data segment includes: Based on the type of external device and the data sampling frequency, the duration of the preset time window is obtained through a weighted linear regression algorithm. Based on the preset time window duration and external device monitoring data, a timestamp is generated, and the monitoring data segment corresponding to each time window is obtained through a data stream sliding algorithm. Based on the unique external device identifier corresponding to each time window monitoring data segment, the time window start stamp, and the root key pre-stored on the general data platform, the initial key material is obtained through SHA-256 hash operation; Based on the initial key material and the key fragments pre-allocated by each participating institution, a unique encryption key for each time window data segment is obtained through the Shamir secret sharing algorithm.

3. The method for time-series encrypted storage and expired data shredding of external device monitoring data as described in claim 2, characterized in that, The process of obtaining the root key pre-stored in the general data platform includes: Based on the combined hash value of the core hardware identifier of the general data platform, the unique identifier list of the initially connected external devices, and the initialization timestamp of the general data platform, a 256-bit initial random number is generated using a cryptographically secure random number generator. Based on the SHA-256 hash value of the initial random number and the core hardware identifier, the combined SHA-256 hash value of the external device unique identifier list, and the SHA-256 hash value of the general data platform initialization timestamp, the key expansion is performed through the HKDF key derivation function to obtain a 256-bit root key. Based on the 256-bit root key, it is split into a preset number of key fragments using the Shamir secret sharing algorithm and distributed to multiple trusted nodes of the general data platform for storage. At the same time, the root key is hashed using the SHA-256 hash algorithm to generate a root key hash value, and the root key hash value is written into the storage chain for evidence preservation.

4. The method for time-series encrypted storage and expired data shredding of external device monitoring data as described in claim 3, characterized in that, The encryption and storage of monitoring data within the corresponding time window based on the derived unique encryption key includes: Based on the unique encryption key derived from the monitoring data segment of the corresponding time window, the unique identifier of the external device associated with the corresponding time window, and the start stamp of the time window, the monitoring data segment is encrypted using a symmetric encryption algorithm, and the unique identifier of the external device and the start stamp of the time window are embedded synchronously to obtain the encrypted data. Based on the encrypted data and the composite index constructed from the unique identifier of the external device and the start stamp of the time window, storage operations are performed through the storage chain of the general data platform to obtain the associated storage record of the encrypted data and the composite index; Based on the associated storage records of encrypted data and composite indexes, and the associated identifier of unique encryption keys, a time-series encrypted data block is obtained through an association analysis algorithm. The time-series encrypted data block includes at least: the device unique identifier used to identify the external device to which the time-series encrypted data block belongs, the time window start stamp used to distinguish different time windows under the same external device, and the composite index used to locate the corresponding time window during composite analysis.

5. The method for time-series encrypted storage and expired data shredding of external device monitoring data as described in claim 4, characterized in that, The process of constructing the authorization policy also includes: Based on the dynamic time window range of each computing party's key acquisition, real-time reputation score, and historical key usage compliance score, the validity period of the unique encryption key is configured through a dynamic key validity configuration algorithm to obtain the correspondence rule between the computing party's identity and the validity period of the unique encryption key; the length of the validity period of the unique encryption key is proportional to the real-time reputation score and historical key usage compliance score of each computing party. Based on the basic authorized list, the association rules between the computing party's identity and the unique identifier range of external devices, the binding relationship between the computing party's identity and the dynamic time window interval, and the corresponding rules between the computing party's identity and the validity period of the unique encryption key, a preset authorization strategy that is dynamically adjusted is obtained.

6. The method for time-series encrypted storage and expired data shredding of external device monitoring data as described in claim 5, characterized in that, The distribution of unique encryption keys corresponding to a specified time window to the computing parties participating in the joint analysis based on a preset authorization strategy includes: Based on joint analysis requests initiated by multiple organizations, the request parsing algorithm configured on the general data platform is used to extract the identifiers of each participating organization, joint analysis project filing information, common target time window, and unique identifier range of associated equipment contained in the joint analysis request to obtain the request data to be verified. Based on the identifiers of each participating organization in the request data to be verified and the basic authorization list in the preset authorization policy, the identifiers of each participating organization and the qualification certificate types of each organization are verified by the federated identity verification algorithm based on X.509 certificates. At the same time, the correlation between the joint analysis project filing information and the equipment data corresponding to the unique identifier range of the associated equipment is verified by the joint project compliance verification algorithm, so as to obtain the multi-organization joint identity verification result. When the multi-organization joint authentication result is passed, the association rules between the unique identifier range of the associated device in the request data to be verified and the identity identifier of each participating organization and the unique identifier range of the external device in the preset authorization policy are combined. The intersection of the unique identifier range of the external device of each participating organization is calculated by the multi-organization permission intersection algorithm to determine the unique identifier range of the device accessed by the joint analysis. The permission boundary verification algorithm is used to check whether the unique identifier of the associated device in the request data to be verified is within the unique identifier range of the device accessed by the joint analysis, and the external device permission verification result is obtained.

7. The method for time-series encrypted storage and expired data shredding of external device monitoring data as described in claim 6, characterized in that, The distribution of a unique encryption key corresponding to a specified time window to the computing parties participating in the joint analysis based on a preset authorization strategy also includes: When the external device permission verification result is within the range, the binding relationship between the target time window in the request data to be verified and the calculation party identity in the preset authorization policy and the dynamic time window interval is combined. The time window matching algorithm is used to check whether the start timestamp of the target time window is later than the authorization start timestamp of the dynamic time window interval, and whether the end timestamp of the target time window is earlier than the authorization end timestamp of the dynamic time window interval, so as to obtain the time window verification result. When the time window verification result meets the matching threshold, the following operations are performed using the key reconstruction status query algorithm: Extract the key shard index table corresponding to the target time window, send a key shard submission command carrying the start stamp of the time window to the participating institutions recorded in the key shard index table, receive the key shards and shard signatures returned by the participating institutions, verify the validity of the shard signatures using the ECDSA digital signature verification algorithm with the participating institutions' preset public key, compare the received shard numbers with the shard numbers recorded in the key shard index table using a shard number matching algorithm, filter out the valid key shards that have passed the double verification, count the number of valid key shards using a shard count algorithm, compare the counted number with a preset number threshold, if the counted number is not less than the preset number threshold, perform a joint operation on the valid key shards using the Shamir secret sharing reconstruction algorithm to generate a unique encryption key candidate value, compare the unique encryption key candidate value with the joint hash value of the device unique identifier and the start stamp of the time window using a key verification algorithm, if the verification is successful, the result is that the key availability is usable.

8. The method for time-series encrypted storage and expired data shredding of external device monitoring data as described in claim 7, characterized in that, The distribution of a unique encryption key corresponding to a specified time window to the computing parties participating in the joint analysis based on a preset authorization strategy also includes: When the key availability result is available, the corresponding rules of the computing party identity identifier and the validity period of the unique encryption key in the preset authorization policy, as well as the real-time reputation score and historical key usage compliance score of the corresponding computing party, are combined. The validity period of the unique encryption key is calculated by the key validity generation algorithm according to the weighted ratio of the real-time reputation score and the historical key usage compliance score. A unique encryption key with a specified time window and a validity period restriction is generated. The unique encryption key is associated with the device unique identifier and the time window start stamp by the association binding algorithm to obtain the key package to be distributed. Based on the key packet to be distributed, the key packet is transmitted to the computing party through an encrypted transmission channel. At the same time, a log structured recording algorithm is used to record the computing party's identity, distribution time, key validity period, target time window, and unique device identifier in a structured manner, generating a key distribution record containing the hash value of the record information. The key distribution record is then uploaded to the storage chain of the general data platform for notarization using a blockchain writing algorithm. This allows the computing party to use the unique encryption key to perform secure multi-party computation on time-series encrypted data blocks with unique device identifiers within the specified time window during the validity period.

Images