Judicial evidence storage method and system for preventing secondary evidence collection vulnerability

Abstract

The invention discloses a judicial evidence storage method and system for preventing a secondary evidence collection vulnerability, and relates to the field of electronic evidence storage safety. According to the method, a hardware trusted basis is constructed based on a mobile terminal TEE, when evidence is obtained for the first time, a camera, a microphone and / or a light sensor are called to collect scene dynamic characteristics, a scene unique identifier is generated through SIFT and MFCC algorithm processing, and the scene unique identifier and evidence storage data are bound and linked; and during secondary uploading, the current scene identifier is extracted to be compared with the first identifier on the chain, secondary evidence obtaining attack is judged if the similarity is lower than a threshold value, uploading is refused, and an alarm is given. According to the method, data-equipment-scene three-dimensional verification is constructed through the scene unique identifier, so that the risk of retransmission after an attacker tampers data is thoroughly blocked, the credibility of judicial evidence storage is improved, and the method is adaptive to an Android / iOS terminal and is high in compatibility.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electronic evidence storage security, and in particular to a judicial evidence storage method and system for preventing secondary evidence collection vulnerabilities. BACKGROUND

[0002] In the field of mobile terminal judicial evidence storage, the existing technology has formed a protection system combining hardware trusted root such as TEE, TrustZone, Secure Enclave with multi-dimensional data verification including time, space, and collection source verification and blockchain evidence storage, which can cope with three types of source-level tampering risks: time anchor forgery, space anchor forgery, and collection source forgery. However, the existing solution still has a key vulnerability, namely the secondary evidence collection vulnerability: an attacker can obtain the rights of the real evidence storage process through legal means, such as controlling the authorized evidence collection device and obtaining a legal operation account, collecting and storing real evidence data according to the normal process, including hardware identification, trusted timestamp, and location data, then tampering with the data, such as modifying image content and adjusting the infringement timestamp, and then calling the evidence storage App to upload the tampered data again.

[0003] The core reason why the existing solution cannot identify such attacks is that its protection logic only focuses on data integrity verification through hash checking, device uniqueness verification through hardware identification, and time and space authenticity verification through trusted timestamp and multi-modal positioning, without associating the unique dynamic characteristics of the evidence collection scene, namely the unique environment of the first evidence collection, such as temporary markers, real-time changing light and sound, and dynamic actions of on-site personnel. The existing solution does not bind such scene characteristics with evidence data, resulting in the fact that attackers can reuse legal devices and real time and location information, only tamper with the core evidence content, and then complete the secondary upload, ultimately making the false data pass the existing verification logic and damaging the credibility of judicial evidence storage.

[0004] For example, in the scene of traffic accident judicial evidence collection, the existing solution will verify the TrustZone hardware identification of the evidence collection device, the Beidou trusted timestamp, and the GPS location of the accident scene, but does not bind the environment image taken at the first evidence collection, which contains temporary warning signs such as temporary ice cream cones placed by law enforcement personnel. After obtaining the device, the attacker can reproduce a similar GPS location at another location, adjust the timestamp to a reasonable range, tamper with the accident image content, and then upload it again. The existing solution determines that the data is legal because the hardware identification, time, and location match, resulting in the flow of false evidence into the judicial process.

[0005] In the prior art, the separate encryption evidence storage architecture disclosed in Canadian patent CA2915277A1 and the TEE+blockchain scheme adopted by the domestic judicial evidence storage App do not involve the binding and secondary verification of scene unique identification; some anti-forensic technologies, such as immutable storage and chain-of-custody records, only target the data storage and transfer links and cannot cover the core dimension of scene correlation. Therefore, a technical solution that can deeply bind the unique dynamic characteristics of the forensic scene with the evidence storage data is urgently needed to fundamentally prevent secondary forensic vulnerabilities. SUMMARY

[0006] In view of the defects of the prior art that the judicial evidence storage scheme does not bind the "forensic scene unique identification" and cannot prevent secondary forensic vulnerabilities, the present application provides a judicial evidence storage method and system for preventing secondary forensic vulnerabilities, which extracts the dynamic unique characteristics of the forensic scene as "scene identification", binds and uploads the scene identification with the evidence storage data, verifies the consistency of the scene identification when uploading again, completely blocks the repeated uploading of tampered data, and guarantees the uniqueness and judicial effectiveness of electronic evidence.

[0007] To this end, the technical route adopted by the present application is as follows: taking the "non-reproducible dynamic characteristics of the forensic scene" as the unique identification, a "data-equipment-scene" three-dimensional verification system is constructed - when forensic evidence is first collected, the dynamic unique characteristics of the scene environment are extracted, such as images containing temporary markers, real-time environmental sound, and light and shadow change curves, a scene unique identification is generated and bound with the evidence storage data package, including hardware identification, trusted timestamp, and evidence hash, and is uploaded to the chain; when uploading again, the system automatically extracts the characteristics of the current scene and compares them with the first scene identification on the chain, and if the similarity is lower than the threshold, it is determined that it is a secondary forensic attack, and uploading is refused and an alarm is given.

[0008] The specific technical solution is as follows: A judicial evidence storage method for preventing secondary forensic vulnerabilities, comprising the following steps: S1: constructing a TEE based on a hardware trusted module built-in in a mobile terminal, the hardware trusted module being an Android TrustZone or an iOS Secure Enclave; pre-storing device unique hardware identification, native camera / microphone driver digital signature public key, heterogeneous trusted time source list, and scene identification extraction algorithm parameters in the TEE, performing SHA-256 hash calculation on the pre-stored data to generate a hardware reference hash value, and synchronizing the hardware reference hash value to a judicial evidence blockchain consortium chain including notary office and court nodes; S2: when starting the evidence storage function, the TEE runs a trusted state detection program to verify the integrity of the mobile terminal system partition and detect unauthorized communication links between the TEE and the REE, and if it is determined that the device is in an untrusted state, the evidence storage function is disabled and an abnormal alarm is sent to the blockchain; S3: first forensic scene identification generation and binding: S31: Collect scene image features and / or scene audio features and / or scene light features by calling the camera, microphone and / or light sensor of the mobile terminal through the TEE; S32: In the TEE, the scene image features and / or scene audio features and / or scene light features are spliced and then calculated by using the SHA-256 algorithm to generate a forensic scene unique identifier H_scene; S33: A trusted timestamp T_trust, trusted location data P_trust and evidence data hash H_evidence are generated by the TEE, H_scene is packed with "device unique hardware identifier + T_trust + P_trust + H_evidence" as a first forensic data packet D1, the D1 is signed by the TEE built-in private key and then uploaded to a judicial forensic blockchain consortium chain to obtain a unique forensic number ID1; S4: Secondary upload verification and interception: S41: When receiving the upload request again, the TEE repeats steps S31-S32 to generate a current scene identifier H_scene_new; S42: The TEE retrieves D1 from the blockchain through ID1 and extracts H_scene and the device unique hardware identifier; S43: Verify whether the current device hardware identifier is consistent with the device unique hardware identifier in D1, if not, reject the request; if consistent, calculate the similarity of H_scene and H_scene_new, if the similarity is less than a preset threshold, determine that it is a secondary forensic attack, stop uploading and send an alarm, if the similarity is greater than or equal to the preset threshold, allow to continue to store the evidence; S5: When judicial verification, D1 is retrieved through ID1 to verify the generation logic integrity of H_scene.

[0009] The application also provides a judicial evidence storage system for preventing secondary forensic vulnerabilities, which comprises: Hardware trusted module: Android TrustZone or iOS Secure Enclave, used for building a TEE, storing a device unique hardware identifier, a native camera / microphone driver digital signature public key, a heterogeneous trusted time source list and a scene identifier extraction algorithm parameter, and generating a hardware reference hash value; Device trusted detection module: running in the TEE, used for verifying the integrity of the mobile terminal system partition, detecting the unauthorized communication link between the TEE and the REE, and determining the device trusted state; Scene feature acquisition module: running in the TEE, used for calling the camera, microphone and / or light sensor of the mobile terminal to collect scene image features and / or scene audio features and / or scene light features; Scene Unique Identifier Generation Module: Running on TEE, it is used to concatenate the scene image features and / or scene audio features and / or scene light and shadow features and then calculate using the SHA-256 algorithm to generate a unique identifier H_scene for the evidence collection scene; The existing evidence storage execution module runs on a TEE and is used to generate trusted timestamps T_trust, trusted location data P_trust, and evidence data hashes H_evidence. Data packet binding and signing module: running on TEE, used to package H_scene and "device unique hardware identifier + T_trust + P_trust + H_evidence" into the first evidence storage data packet D1, and sign it with the TEE's built-in private key; Blockchain interaction module: used to upload D1 to the judicial evidence preservation blockchain consortium chain to obtain the evidence preservation number ID1, retrieve historical data packets, and send abnormal alarms; Secondary upload verification module: running on TEE, used to generate the current scene identifier H_scene_new, compare the similarity between H_scene and H_scene_new, and determine whether it is a secondary evidence attack; The exception log and alarm module is used to record secondary evidence collection attack logs and output prompt information on the evidence storage App.

[0010] Compared with Xi'an and other technologies, the beneficial technical effects of this invention are as follows: 1. Thoroughly prevent secondary forensics vulnerabilities: Construct an uncopyable identifier through dynamic and unique features of the scene. Even if an attacker reuses legitimate devices, real time and location information, they will not be able to reproduce the scene features of the first forensics. Situations such as the removal of temporary markers and changes in ambient sound will cause the scene identifier similarity to fail to meet the standard, and the upload request will be directly blocked. 2. Strong compatibility: The solution is based on the existing judicial evidence storage system TEE + blockchain extension, without the need to reconstruct the underlying architecture. It only adds a scene feature collection and identification generation secondary verification module, which can be adapted to mainstream Android and iOS terminals. 3. High judicial recognition: The unique scene identifier and evidence storage data are synchronously uploaded to the blockchain, and the complete association between evidence, device and scene can be traced during judicial verification, which meets the requirements of the integrity of the electronic evidence chain and further enhances the credibility of the evidence; 4. Flexibility and Adjustability: The feature types of scene identification, such as using only image features and similarity thresholds, can be adjusted through TEE configuration, which can adapt to different evidence collection scenarios, such as indoor fixed scenes and outdoor dynamic scenes. Detailed Implementation

[0011] The following example uses the Huawei Mate 60 Pro Android phone (integrated with TrustZone hardware trusted module) in a traffic accident judicial evidence collection scenario to illustrate the implementation process of this invention. Those skilled in the art can completely reproduce the implementation process of this solution based on the following description: Hardware environment preparation The evidence collection terminal is a Huawei Mate 60 Pro mobile phone. This device needs to integrate a TrustZone hardware trusted module to ensure that the TEE environment can be built normally. The rear camera of the mobile phone needs to have 4K shooting capability, the microphone sampling rate can reach 16kHz, and the light sensor measurement accuracy needs to be controlled within ±10 lux to meet the accuracy requirements of scene feature acquisition.

[0012] The judicial evidence preservation blockchain consortium chain needs to be deployed in advance. The consortium chain node configuration should include at least 2 notary office nodes and 1 court node. The consensus mechanism adopts the PBFT algorithm to ensure that the block generation time does not exceed 10 seconds, thus ensuring the efficiency and consistency of evidence preservation data on the chain.

[0013] The mobile phone needs to be equipped with a functional GPS module, Wi-Fi module, and cellular communication module for subsequent location data collection and blockchain communication.

[0014] Software environment configuration The Huawei Mate 60 Pro phone needs to have Android 14 or above installed to ensure that TrustZone is fully functional and supports secure communication between TEE and REE.

[0015] The mobile phone comes pre-installed with an evidence storage app that supports the technical solution of this invention. This evidence storage app needs to complete official certification from Huawei and obtain TEE call authorization. It also has core functions such as sensor data acquisition, algorithm processing, and blockchain communication.

[0016] The evidence storage app needs to connect to third-party service components in advance, including the SIFT feature extraction SDK, MFCC audio processing library, and light sensor data acquisition interface. All third-party components need to complete compatibility testing to ensure that the data processing process is stable and reliable.

[0017] Complete the integration and configuration of third-party API interfaces in advance, including the BeiDou satellite timing interface, the National Time Service Center NTP server interface, third-party map service API (used to obtain the physical address of Wi-Fi hotspots), and operator base station location query API (used to obtain the latitude and longitude range of base stations). Interface call permissions need to be applied for and configured in advance.

[0018] Scene preparation At the scene of a traffic accident, temporary signs must be set up by law enforcement officers. The signs must have a unique random number (e.g., JFS20241118001) and the number must be printed in a clear and recognizable font to ensure that the texture features can be accurately extracted after the camera takes the picture. The signs must be placed in a prominent position next to the accident vehicle to avoid being obstructed, and at the same time maintain a reasonable distance from the core area of ​​the accident to ensure that the scene image can include both the signs and key information of the accident scene.

[0019] Implementation steps Step S1: TEE initialization and benchmark data uploading After the evidence storage app is launched for the first time, it automatically calls the trusted basic service API interface provided by Huawei HarmonyOS system to send an activation request to the TrustZone hardware trusted module built into the phone. After the TrustZone module verifies the manufacturer signature of the evidence storage app (which has been filed on the Huawei developer platform), it automatically creates an independent TEE execution space and generates a pair of asymmetric keys. The private key is stored inside TrustZone, and the public key is uploaded to the trusted server of the judicial evidence storage blockchain consortium chain to complete the filing.

[0020] TEE reads the device's unique hardware identifier through the phone's hardware interface, specifically including the SoC serial number K9000S12345678, the camera sensor ID IMX800-7890, and the GPS chip number HWGPS-202401. All hardware identifiers must be read directly through the underlying hardware interface to ensure data authenticity.

[0021] Core configuration data is pre-stored in the TEE, including: Huawei's official native camera driver digital signature public key PublicKey_HW_Camera_2024; a list of heterogeneous trusted time sources, specifically including the BeiDou satellite timing interface address, the National Time Service Center NTP server address ntp.ntsc.ac.cn, and the court node IP address of the judicial evidence storage blockchain consortium chain 10.100.50.20; and scene identifier extraction algorithm parameters, specifically set as follows: SIFT feature point extraction threshold 0.04, MFCC audio processing sampling rate 16kHz, and light and shadow feature acquisition duration 10 seconds.

[0022] TEE uses the SHA-256 hash algorithm to perform hash calculations on the combined data of the hardware identifier, camera driver digital signature public key, heterogeneous trusted time source list, and scene identifier extraction algorithm parameters to generate a hardware baseline hash value. A specific example is a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2.

[0023] The hardware baseline hash value is uploaded to the judicial evidence preservation blockchain consortium chain via the HTTPS protocol. During the transmission process, the TEE's built-in private key must be attached for signature. After receiving the signature, the consortium chain node verifies its validity. Once verified, the hardware baseline hash value is associated with the device SoC serial number and stored, thus completing the TEE initialization and baseline data uploading process.

[0024] Step S2: Device Trustworthiness Testing TEE reads the / system partition of the Android system through the TrustZone file access interface, focusing on detecting whether there are root characteristic files in this partition. The specific detection paths include / system / xbin / su and / system / bin / su. At the same time, it checks whether there are installation directories of mainstream root tools such as Magisk in the / data / app directory. If any of the above files or directories are detected, the device is marked as root risk.

[0025] TEE monitors memory access requests initiated by REE (Android system) to TEE in real time, and only allows trusted interfaces (including time synchronization interface, sensor data reading interface, and data signature interface) pre-built by the evidence storage App to access TEE memory space. If an unregistered access request is detected, it is determined to be unauthorized communication and the device is marked as untrusted.

[0026] If the device is not marked as rooted or untrusted, the TEE returns a device trust confirmation signal to the evidence storage app, allowing the evidence storage app to start the evidence storage function. If the device is at risk, the evidence storage app immediately disables evidence collection-related functions such as taking pictures, recording videos, and locating the device, and sends an abnormal alarm to the judicial evidence storage blockchain consortium chain through the TEE. The alarm information includes the device SoC serial number, risk type, and detection timestamp. The consortium chain node records the alarm log for subsequent traceability.

[0027] Step S3: Initial scene identifier generation and storage Step S31: Scene Dynamic Feature Acquisition The TEE sends a camera access command to the evidence storage app, which then activates the phone's rear camera to capture an image of the accident scene, including temporary signs. The image resolution is set to 4K to ensure the accuracy of feature extraction. After the image is captured, the raw image data is directly transmitted to the TEE without being stored or processed by the REE.

[0028] TEE calls the built-in SIFT feature extraction SDK to perform feature extraction operations on the on-site image: First, multi-scale spatial extremum detection is performed to identify potential key points in the image; then, the key points are located, and low-contrast key points and edge response points are removed; next, a principal direction is assigned to each key point to ensure the rotation invariance of the feature description; finally, a 128-dimensional feature vector is generated to extract the edge contour and number texture features of the temporary sign, and finally a feature point set F1 containing 200 feature points is generated.

[0029] The TEE sends a microphone access command to the evidence storage app to start the microphone to collect ambient traffic sounds at the scene. The collection duration is set to 3 seconds, and the sampling rate is executed according to the pre-configured 16kHz. Human interference is avoided during the collection process to ensure the authenticity of the audio data. After the audio data is collected, it is directly transmitted to the TEE.

[0030] TEE calls the MFCC audio processing library to process the acquired audio data: First, the audio signal is pre-emphasized, framed, and windowed to reduce noise interference; then, a fast Fourier transform is performed to convert the time-domain signal into a frequency-domain signal; next, the Mel frequency coefficients are extracted through the Mel filter bank; finally, a discrete cosine transform is performed to obtain the 13-dimensional audio feature vector V1.

[0031] TEE sends a command to the evidence storage App to activate the light sensor and collect ambient light intensity data. The collection time is 10 seconds and the sampling interval is set to 1 second, acquiring a total of 10 sets of light intensity data. TEE analyzes the collected light intensity data, identifies the time points corresponding to the peak and valley values ​​in the data, specifically 0 seconds, 5 seconds, and 8 seconds, and generates a light and shadow feature sequence L1.

[0032] Step S32: Generating a Unique Scene Identifier TEE concatenates the three types of feature data in the order of "feature point set F1 + audio feature vector V1 + light and shadow feature sequence L1" to form a combined data string. The combined data string is then hashed using the SHA-256 hash algorithm to generate a unique identifier H_scene of a fixed length of 256 bits for the evidence collection scene. A specific example is c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2.

[0033] Step S33: Generation and uploading of evidence storage data packets TEE synchronously acquires three types of core evidence storage data: trusted timestamps, trusted location data, and evidence data hashes.

[0034] Trusted timestamp generation: The TEE obtains three sets of time data from the BeiDou satellite timing interface, the National Time Service Center NTP server, and the court node of the judicial evidence storage blockchain consortium chain. After removing abnormal time sources that deviate from the average value by more than ±5 seconds, the average value of the remaining time data is taken as the trusted timestamp T_trust. A specific example is 2024-11-18 15:30:00.001. After generation, the timestamp is signed using the TEE private key.

[0035] Trusted location data generation: The TEE calls the GPS module to obtain latitude and longitude data, specifically 31.2304°N and 121.4737°E, and verifies the hardware signature of the GPS chip to confirm the authenticity of the data source. Then, it calls the Wi-Fi module to collect the MAC addresses and signal strengths of surrounding Wi-Fi hotspots, and obtains the physical address latitude and longitude corresponding to the MAC address through the connected third-party map service API. It calls the cellular communication module to obtain the LAC (Location Area Code) and CI (Cell Identifier) ​​of the currently connected base station, and obtains the latitude and longitude range covered by the base station through the operator's base station location query API. The TEE cross-validates the GPS latitude and longitude with the Wi-Fi physical address latitude and longitude and the base station latitude and longitude range. After confirming that the GPS latitude and longitude falls within ±50 meters of the Wi-Fi physical address and overlaps with the base station latitude and longitude range, the trusted location data P_trust is determined.

[0036] Evidence data hash generation: TEE uses the SHA-256 algorithm to perform hash calculation on the raw image data (containing complete EXIF ​​information, including shooting time, equipment model, GPS location, etc.) taken at the accident scene to generate evidence data hash H_evidence. A specific example is e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2.

[0037] TEE packages and integrates the scene unique identifier H_scene, the device unique hardware identifier (SoC serial number, camera sensor ID, GPS chip number), the trusted timestamp T_trust and its corresponding signature, the trusted location data P_trust, and the evidence data hash H_evidence to form the first evidence storage data package D1.

[0038] TEE uses its built-in private key to sign the first evidence storage data packet D1, generating a data packet signature value; the evidence storage app uploads the "first evidence storage data packet D1 + data packet signature value" to the judicial evidence storage blockchain consortium chain via the HTTPS protocol.

[0039] After receiving the data packet, the nodes of the judicial evidence preservation blockchain consortium chain use the PBFT consensus algorithm to verify the data packet between nodes. Once the verification is successful, a unique evidence preservation number ID1 is generated, such as EZ202411181530001. At the same time, the evidence preservation data packet D1, the data packet signature value and the evidence preservation number ID1 are associated and stored, thus completing the initial evidence preservation process.

[0040] Step S4: Secondary upload interception After obtaining the evidence-gathering phone, the attacker tampered with the accident image stored initially, such as modifying vehicle collision marks or adding fake objects. Then, the attacker launched the evidence storage app, selected the evidence storage number ID1 corresponding to the initial evidence storage, and initiated a second upload request.

[0041] After receiving the second upload request, TEE repeats the scene dynamic feature acquisition process in step 2.3.1: It uses the camera, microphone, and / or light sensor to acquire image features, audio features, and lighting features of the current scene. At this point, the temporary sign placed during the initial evidence collection has been removed, and the ambient sound is traffic noise not from the original accident scene. After acquisition, the feature point set F2, audio feature vector V2, and lighting feature sequence L2 of the current scene are generated using the SIFT and MFCC algorithms. Then, the current scene identifier H_scene_new is generated through SHA-256 hash calculation. A specific example is shown below. f3e2d1c0b9a8b7c6d5e4f3e2d1c0b9a8b7c6d5e4f3e2d1c0b9a8b7c6d5e4f3e2.

[0042] TEE sends a data retrieval request to the judicial evidence preservation blockchain consortium chain via the evidence preservation number ID1. After the consortium chain node verifies the legality of the request, it returns the first evidence preservation data packet D1. TEE extracts the first scene identifier H_scene and the device's unique hardware identifier from D1.

[0043] TEE compares the current device's hardware identifier with the unique hardware identifier extracted from D1 one by one to confirm that the two are completely consistent, thus eliminating the risk of unauthorized device uploads.

[0044] TEE uses the SIFT feature point matching algorithm to calculate the matching rate between the feature point set F1 corresponding to the first scene identifier and the feature point set F2 corresponding to the current scene identifier. The result of this calculation is 50%. Meanwhile, the preset similarity threshold is 90%. Since 50% is lower than the preset threshold of 90%, TEE determines that this upload request is a secondary evidence attack.

[0045] The TEE immediately sends a stop upload command to the evidence storage app, and the app terminates the current upload process. Simultaneously, the TEE generates a tampering log, which includes the current scene identifier H_scene_new, the device's unique hardware identifier, and the timestamp of the secondary upload request. The evidence storage app sends a secondary evidence attack alarm to the judicial evidence storage blockchain consortium chain via the TEE, and the alarm information and tampering log are uploaded to the consortium chain simultaneously. The evidence storage app displays a "Scene abnormal, upload prohibited" message on the mobile interface, informing the operator that the current upload request has been blocked.

[0046] Step S5: Judicial Verification When judicial authorities (such as courts) need to verify the evidence data during the trial process, they can initiate a data retrieval request to the judicial evidence storage blockchain consortium chain through the evidence storage number ID1 to obtain the first evidence storage data packet D1, the data packet signature value, and related log information.

[0047] Judicial verifiers first use the public key registered in the consortium blockchain with the TEE to verify the signature value of the first evidence storage data packet D1, confirming that the data packet has not been tampered with during transmission and storage.

[0048] Verifiers extracted the evidence data hash H_evidence from D1, recalculated the SHA-256 hash of the submitted original accident scene images, compared the calculation result with H_evidence, and confirmed that the image content had not been tampered with.

[0049] Verification personnel extracted the trusted timestamp T_trust and the corresponding signature from D1, and verified the authenticity and accuracy of the timestamp by connecting to the BeiDou satellite timing system and the National Time Service Center's NTP server.

[0050] Verification personnel extracted the trusted location data P_trust from D1 and, in conjunction with third-party map service APIs and operator base station location query APIs, verified the consistency of GPS latitude and longitude, Wi-Fi hotspot physical address latitude and longitude, and base station latitude and longitude range to confirm the authenticity of the evidence-collected location.

[0051] Verification personnel extracted the scene unique identifier H_scene from D1 and checked its generation logic: confirmed that it contained a complete processing record including SIFT feature extraction, MFCC audio processing, and light and shadow feature analysis, and confirmed that the scene feature acquisition time was consistent with the trusted timestamp, and that the scene features were consistent with the actual situation at the accident site, thus determining that the scene unique identifier had not been tampered with.

[0052] Once all verification items have passed, the judicial authorities will determine that the stored data has judicial validity and can be used as legal evidence in the trial of the case.

[0053] The following are supplementary explanations regarding the specific implementation methods described above: Scene feature types can be flexibly selected. For example, in scenarios without audio acquisition conditions, such as silent environments, it is not necessary to forcibly collect the three types of features; only image features and lighting features need to be collected to generate a unique scene identifier H_scene. In specific implementation, a scene feature acquisition mode selection function can be added to the evidence storage app. Operators can manually select the appropriate acquisition type according to the actual environment. After selection, the relevant configuration parameters will be synchronized to the TEE, and the TEE will execute the subsequent acquisition and processing process according to the selected feature type.

[0054] In addition to scene feature types, the similarity threshold also supports flexible configuration. For outdoor dynamic scenes with significant changes in light, shadow, and sound, the similarity threshold can be lowered to 85%; for indoor fixed scenes with relatively stable light, shadow, and sound, the threshold can be raised to 95%. In practice, the threshold adjustment is completed through the TEE's built-in configuration interface. The adjusted threshold must be associated with the device's unique hardware identifier and stored, and synchronized to the judicial evidence storage blockchain consortium chain for filing, ensuring the traceability of the threshold during the judicial verification stage.

[0055] To further enhance the uniqueness of scene identification, temporary markers are recommended to be one-time use and non-replicable, such as paper signs with randomly generated QR codes. These QR codes are only valid for the first scan and automatically expire after subsequent scans. During implementation, a QR code generation function can be integrated into the evidence storage app. Before evidence collection, operators can generate random QR codes and print them on paper signs. When capturing scene images, it is essential to ensure the QR codes are clearly legible. During the feature extraction stage, the texture features of the QR codes should be included in the extraction scope to strengthen the uniqueness of the scene identification.

[0056] This solution is also adaptable to offline scenarios where there is no network signal at the evidence collection site. In this case, the TEE can first use the AES-256 encryption algorithm to locally encrypt and store the initial evidence storage data packet D1. The encryption key is randomly generated by the TEE and stored independently, without being associated with other data. After the network is restored, the evidence storage app will automatically detect the network status. Once the network is clear, it will decrypt the locally stored initial evidence storage data packet D1 through the TEE and then upload it to the judicial evidence storage blockchain consortium chain according to the normal process. The secondary upload verification logic in offline scenarios remains unchanged. The TEE can still extract the scene unique identifier H_scene from the locally stored initial evidence storage data packet D1 and compare it with the current scene identifier H_scene_new to ensure that the secondary evidence collection attack interception function is not affected.

[0057] If updates to algorithm components such as the SIFT feature extraction SDK and MFCC audio processing library are required during implementation, compatibility testing and security verification of the new algorithm version must be performed in the TEE beforehand. Only after confirming that the consistency and security of the algorithm output meet the standards can the old version components be replaced. After the algorithm version update is completed, the new version information must be synchronized to the judicial evidence preservation blockchain consortium chain for filing, ensuring that the algorithm version is traceable during judicial verification and guaranteeing the continuity and validity of the evidence preservation data.

[0058] Those skilled in the art can make appropriate modifications and variations to the above embodiments within the scope of the technical concept of the present invention, and such modifications and variations all fall within the protection scope of the present invention.

Claims

1. A judicial evidence preservation method to prevent loopholes in secondary evidence collection, characterized in that, Includes the following steps: S1: Construct a TEE based on the hardware trusted module built into the mobile terminal. The hardware trusted module is AndroidTrustZone or iOS Secure Enclave. The TEE pre-stores the device's unique hardware identifier, the native camera / microphone driver digital signature public key, the heterogeneous trusted time source list, and the scene identifier extraction algorithm parameters. The pre-stored data is then subjected to SHA-256 hash calculation to generate a hardware base hash value, which is then synchronized to the judicial evidence storage blockchain consortium chain containing notary office and court nodes. S2: When the evidence storage function is started, the TEE runs a trusted state detection program to verify the integrity of the mobile terminal system partition and detect the unauthorized communication link between the TEE and the REE. If the device is determined to be in an untrusted state, the evidence storage function is disabled and an abnormal alarm is sent to the blockchain. S3: Initial Evidence Collection Scenario Identifier Generation and Binding: S31: Call the camera, microphone and / or light sensor of the mobile terminal through TEE to collect scene image features and / or scene audio features and / or scene light and shadow features; S32: In the TEE, the scene image features and / or scene audio features and / or scene light and shadow features are concatenated and then calculated using the SHA-256 algorithm to generate a unique identifier H_scene for the evidence collection scene; S33: Generate a trusted timestamp T_trust, trusted location data P_trust, and evidence data hash H_evidence through TEE. Package H_scene with "device unique hardware identifier + T_trust + P_trust + H_evidence" into the first evidence storage data package D1. After signing with the private key built into TEE, upload it to the judicial evidence storage blockchain consortium chain to obtain the unique evidence storage number ID1. S4: Secondary upload verification and interception: S41: When an upload request is received again, the TEE repeats steps S31-S32 to generate the current scene identifier H_scene_new; S42: TEE retrieves D1 from the blockchain via ID1 and extracts H_scene and the device's unique hardware identifier; S43: Verify whether the current device hardware identifier is consistent with the unique device hardware identifier in D1. If they are inconsistent, reject the request. If they are consistent, calculate the similarity between H_scene and H_scene_new. If the similarity is less than the preset threshold, it is determined to be a secondary evidence attack. Stop uploading and send an alarm. If the similarity is greater than or equal to the preset threshold, continue to store evidence. S5: During judicial verification, ID1 is used to retrieve D1 to verify the integrity of the generation logic of H_scene.

2. The judicial evidence preservation method for preventing loopholes in secondary evidence collection according to claim 1, characterized in that, The unique hardware identifier of the device mentioned in step S1 includes the SoC serial number of the mobile terminal, the camera sensor ID, and the GPS chip number; the scene identifier extraction algorithm parameters include the SIFT feature point extraction threshold, the MFCC sampling rate, and the light and shadow acquisition duration.

3. A judicial evidence preservation method for preventing loopholes in secondary evidence collection according to claim 1, characterized in that, In step S31: The scene image features are generated by extracting key feature points from the scene image containing temporary unique markers using the SIFT algorithm; The scene audio features are generated by extracting the spectral features of the ambient sound from 3-5 seconds of the scene using the MFCC algorithm; The scene lighting features are generated by extracting the peak / valley time points of the ambient light intensity change curve within 10 seconds; The collected features are scene image features, a combination of scene image features and scene audio features, a combination of scene image features and scene light and shadow features, a combination of scene audio features and scene light and shadow features, or a combination of scene image features, scene audio features and scene light and shadow features.

4. A judicial evidence preservation method for preventing loopholes in secondary evidence collection according to claim 1, characterized in that, In step S33: The trusted timestamp T_trust is generated by synchronizing the BeiDou satellite time, the National Time Service Center NTP server time, and the blockchain consortium chain node time, and then taking the average value after removing abnormal time sources with deviations exceeding ±5 seconds. The trusted location data P_trust is generated by verifying the GPS sensor hardware signature and cross-verifying the physical address corresponding to the Wi-Fi hotspot MAC address, as well as the latitude and longitude range corresponding to the base station LAC and CI.

5. A judicial evidence preservation method for preventing loopholes in secondary evidence collection according to claim 1, characterized in that, The preset threshold in step S43 is 85%-95%, which can be adjusted through the TEE configuration interface; the similarity is calculated by SIFT feature point matching rate or hash Hamming distance.

6. A judicial evidence preservation method for preventing loopholes in secondary evidence collection according to claim 1, characterized in that, After determining that a secondary evidence collection attack has been detected in step S43, the following steps are also included: saving "current scene identifier + device identifier + request time" to the tampering log and outputting the prompt message "scene abnormal, upload prohibited" on the evidence storage App.

7. A judicial evidence preservation system to prevent loopholes in secondary evidence collection, characterized in that, include: Hardware Trusted Module: This is either Android TrustZone or iOS Secure Enclave, used to build a TEE, store the device's unique hardware identifier, the native camera / microphone driver's digital signature public key, a list of heterogeneous trusted time sources, and scene identifier extraction algorithm parameters to generate a hardware baseline hash value; Device Trust Detection Module: Runs on TEE, used to verify the integrity of mobile terminal system partitions, detect unauthorized communication links between TEE and REE, and determine the trust status of the device; Scene feature acquisition module: running on TEE, used to call the mobile terminal's camera, microphone and / or light sensor to acquire scene image features and / or scene audio features and / or scene light and shadow features; Scene Unique Identifier Generation Module: Running on TEE, it is used to concatenate the scene image features and / or scene audio features and / or scene light and shadow features and then calculate using the SHA-256 algorithm to generate a unique identifier H_scene for the evidence collection scene; The existing evidence storage execution module runs on a TEE and is used to generate trusted timestamps T_trust, trusted location data P_trust, and evidence data hashes H_evidence. Packet binding and signing module: running on TEE, used to package H_scene and "device unique hardware identifier + T_trust + P_trust + H_evidence" into the first evidence storage data packet D1, and sign it with the TEE's built-in private key; Blockchain interaction module: used to upload D1 to the judicial evidence preservation blockchain consortium chain to obtain the evidence preservation number ID1, retrieve historical data packets, and send abnormal alarms; Secondary upload verification module: running on TEE, used to generate the current scene identifier H_scene_new, compare the similarity between H_scene and H_scene_new, and determine whether it is a secondary evidence attack; The exception log and alarm module is used to record secondary evidence collection attack logs and output prompt information on the evidence storage App.

8. A judicial evidence preservation system for preventing loopholes in secondary evidence collection according to claim 7, characterized in that, The scene feature acquisition module also includes a SIFT feature extraction unit and an MFCC audio processing unit, which are used to process scene image features and scene audio features, respectively; when the acquired features include scene light and shadow features, the light and shadow feature processing unit built into the scene feature acquisition module performs feature extraction.

9. A judicial evidence preservation system for preventing loopholes in secondary evidence collection according to claim 7, characterized in that, The judicial evidence preservation blockchain consortium chain adopts the PBFT consensus algorithm, with a block generation time of ≤10 seconds, and the nodes include at least 2 notary office nodes and at least 1 court node.

10. A judicial evidence preservation system for preventing loopholes in secondary evidence collection according to claim 7, characterized in that, The secondary upload verification module also includes a threshold configuration unit, which is used to adjust the preset similarity threshold through the TEE interface.