Root / jailbreak equipment data tampering prevention method and system for judicial evidence storage

Abstract

The invention discloses a judicial evidence storage protection method and system for preventing data tampering of Root / jailbreak equipment, and relates to the field of judicial evidence storage safety of mobile terminals. A trusted root is constructed based on a built-in TEE of a mobile terminal, the trusted state of the equipment is verified, then a trusted timestamp is generated through multi-source heterogeneous time synchronization, position verification is completed by combining GPS, Wi-Fi and base station data, camera drive and sensor parameters are verified to guarantee credibility of an acquisition source, and finally evidence storage data is signed by the TEE and then uploaded to a judicial block chain alliance chain. Through hardware-level protection and multi-dimensional verification, source-level tampering is thoroughly blocked, evidence is ensured to be true and legal, the evidence can be reproduced on mobile terminals such as mobile phones and tablet computers supporting TEE, and the method is suitable for various judicial evidence obtaining scenes.

Description

Technical Field

[0001] This invention relates to the field of electronic evidence preservation security technology, specifically to a method and system for preventing data tampering on rooted / jailbroken devices used for judicial evidence preservation. Background Technology

[0002] In mobile terminal judicial evidence collection scenarios, rooting Android devices and jailbreaking iOS devices can directly break through the original security boundaries of the operating system. Such operations can tamper with the system kernel permission control logic, causing the system integrity measurement mechanism to fail to properly verify the integrity of system files, and at the same time, the mandatory access control mechanism will fail. Ultimately, electronic evidence will face the risk of "source-level" tampering, and will not meet the core requirements of judicial scenarios for the validity of evidence.

[0003] The aforementioned "source-level" tampering risks manifest themselves in three types of high-level attacks that directly undermine the integrity, authenticity, and legality of electronic evidence: First, time anchor point forgery. Attackers, using root privileges (su), can call the system's underlying `settimeofday()` function or implant kernel clock driver hooks to rewind or advance the device's local clock. This tampering causes the Exif timestamps of evidence such as photos and videos generated during the evidence collection process to deviate from real-time (UTC) by seconds to hours, directly undermining the temporal uniqueness of the evidence—for example, forging the timestamp of evidence collected after the infringement occurred to one collected before the infringement, causing the evidence to lose its temporal relevance in proving the infringement.

[0004] Secondly, spatial anchor point forgery. Attackers install virtual location tools such as FakeGPS on rooted / jailbroken devices, and generate false forensic geographic location information by tampering with the output data stream of GPS sensors, such as forging NMEA protocol data, or directly hijacking the location service interface. This type of attack can obscure the real location of the infringement, for example, making an infringement in location A appear to have occurred in location B, causing the spatial correlation of evidence to fail and making it impossible to accurately pinpoint the infringement scenario.

[0005] Third, source forgery. Attackers replace the device's native camera driver, such as the CameraHAL layer driver in Android and the AVFoundation underlying driver in iOS, causing the camera module to automatically embed fake Exif information during shooting—including but not limited to fake shooting device models, sensor parameters, lens information, etc. Even more egregiously, they generate algorithm-based synthesized images through the tampered driver, such as simulated scene footage generated by GAN networks, completely replacing the content captured at the real scene. This type of attack makes the source of evidence untraceable, making it impossible to verify whether the images originated from a genuine evidence-gathering scenario.

[0006] Existing technologies also include specific optimization schemes to address location data tampering, such as the "separate encrypted evidence storage architecture" proposed in Canadian patent CA2915277A1. Its core logic is a dual-unit design of "receiver-reader." The receiver is only responsible for collecting encrypted GNSS navigation signals, such as Galileo PRS or CNS signals, discretizing them into encrypted data via an A / D converter, and storing them. It does not possess decryption keys or location calculation functions. The reader, as the only unit holding the decryption key, needs to be physically connected to the receiver to obtain the encrypted data and independently complete decryption and location data extraction. This scheme, through the "physical separation of data acquisition and processing," does indeed reduce the risk of tampering at the receiver end and supports simultaneous acquisition of multi-source GNSS signals to increase the difficulty of forgery, making it applicable to scenarios such as ship trajectory tracking and container positioning. However, this scheme still has certain limitations when applied to mobile terminal judicial evidence storage scenarios: First, the device lacks compatibility. Its design is based on a dedicated positioning receiver and does not take into account the risks of rooting / jailbreaking smartphones—making it unable to address the problem of attackers forging encrypted signal acquisition links by tampering with the phone's system kernel or hijacking sensor drivers.

[0007] Secondly, the signal source is singular, relying solely on encrypted GNSS signals and failing to integrate multimodal data from the phone's inherent Wi-Fi, base stations, inertial sensors, etc. Data disconnection may occur in scenarios where GNSS signals are obstructed, such as indoors or tunnels, thus failing to meet the "full-scenario coverage" requirement for judicial evidence collection.

[0008] Third, there is a lack of hardware root of trust support, and the encrypted data collection and storage process is not bound to the trusted modules of the mobile phone hardware, such as TrustZone on Android devices and SecureEnclave on iOS devices. Attackers can inject false data by replacing the receiver storage unit or tampering with the encrypted data transmission link.

[0009] Fourth, the lack of judicial traceability means that the evidence is not integrated with judicially recognized evidence preservation technologies such as blockchain. The transmission and decryption process of encrypted data lacks traceable audit logs, which fails to meet the requirement of "verifiable evidence chain throughout" in judicial scenarios. Once the reader key is leaked or the data transmission is intercepted, there is still a risk that the evidence will be tampered with and cannot be traced. Summary of the Invention

[0010] To address the fact that existing technologies, whether conventional software detection, single-signal verification schemes, or specialized separate encryption architectures, cannot provide end-to-end protection against high-level attacks of the "time-space-collection source" type, this invention provides a method for preventing data tampering on rooted / jailbroken devices for judicial evidence preservation. This method overcomes the shortcomings or one of the shortcomings of existing technologies by constructing a basic security barrier through a hardware root of trust, combined with multi-dimensional data cross-verification and blockchain evidence preservation technology. It blocks the "source-level" tampering risk of evidence by rooted / jailbroken devices at the source, ultimately ensuring the integrity, authenticity, and legality of electronic evidence, meeting the stringent requirements for evidence validity in judicial evidence preservation scenarios. The specific technical solution is as follows: A method for protecting judicial evidence from data tampering on rooted / jailbroken devices includes the following steps: S1: Construct a TEE based on the hardware trusted module built into the mobile terminal. The hardware trusted module is either Android TrustZone or iOS Secure Enclave. The TEE pre-stores the device's unique hardware identifier, the native camera driver's digital signature public key, and a list of more than three heterogeneous trusted time sources. The pre-stored data is hashed to generate a hardware baseline hash value, and the hardware baseline hash value is synchronized to the judicial evidence storage blockchain consortium chain that includes notary offices and court nodes. S2: Run a trusted state detection program in the TEE to determine whether the device is in an untrusted state of being rooted / jailbroken by verifying the integrity of the mobile terminal system partition and detecting unauthorized communication links between the TEE and REE; if it is determined to be in an untrusted state, immediately disable the evidence storage function, stop the evidence collection operation, and send a device abnormality alarm to the blockchain consortium chain. S3: Obtain time data from the heterogeneous trusted time source via TEE. The heterogeneous trusted time source includes at least BeiDou satellite time, National Time Service Center NTP server time, and local time of blockchain consortium chain node; calculate the average and standard deviation of the multi-source time data, eliminate abnormal time sources whose deviation from the average exceeds a preset threshold, and use the average of the remaining time data as the trusted timestamp; compare the REE local time with the trusted timestamp in real time. If the deviation exceeds ±2 seconds, it is determined to be time tampering, the evidence collection is stopped, and the tampering log is recorded. S4: Synchronously collect GPS sensor data, Wi-Fi hotspot data, and base station data from the mobile terminal via TEE. Verify the hardware signature of the GPS sensor in the TEE to confirm the authenticity of the data source. Construct a location credibility model. If the GPS latitude and longitude fall within ±50 meters of the physical address of the Wi-Fi hotspot and overlap with the latitude and longitude range of the base station, the location is deemed credible. If the location is deemed untrustworthy, refuse to generate evidence data. S5: Before calling the mobile terminal camera, verify the consistency between the digital signature of the native camera driver and the pre-stored public key in the TEE, and verify whether the deviation between the camera sensor parameters and the pre-stored reference parameters in the TEE is ≤±10%; if both verifications pass, after taking the image, perform hash calculation on the image data containing complete EXIF ​​information in the TEE to generate the image hash value; if either verification fails, the camera call is prohibited. S6: In the TEE, the trusted timestamp, location credibility result, image hash value and unique hardware identifier of the device are packaged into a data storage data package. After signing the data storage data package with the private key built into the TEE, it is uploaded to the judicial evidence storage blockchain consortium chain to complete the evidence storage. During judicial verification, the data storage data package is retrieved through the blockchain and compared with the hardware benchmark hash value to confirm that the data has not been tampered with.

[0011] Furthermore, the unique hardware identifier of the device in step S1 includes the SoC serial number of the mobile terminal, the camera sensor ID, and the GPS chip number, and the hardware base hash value is calculated and generated using the SHA-256 algorithm.

[0012] Furthermore, the system partition integrity verification in step S2 includes: detecting whether the Android terminal's / system partition contains a su binary file, and detecting whether the iOS terminal contains a Cydia.app file and access permissions to the sandbox external directory; the unauthorized communication link detection includes: monitoring whether the REE initiates an unregistered memory read request to the TEE.

[0013] Furthermore, the preset threshold mentioned in step S3 is ±5 seconds; after the trusted timestamp is generated, the TEE adds a timestamp signature to it, and the timestamp signature and the trusted timestamp are synchronized to the blockchain consortium chain.

[0014] Furthermore, the Wi-Fi hotspot data in step S4 includes the MAC address and signal strength of the Wi-Fi hotspot, and the physical address of the Wi-Fi hotspot is obtained by connecting to a third-party map service API; the base station data includes the LAC and CI of the base station, and the latitude and longitude range of the base station is obtained by connecting to the operator's location query API.

[0015] Furthermore, the camera sensor parameters mentioned in step S5 include sensor pixel size, exposure time, and white balance parameters; the image hash value is calculated and generated using the SHA-256 algorithm, and the image hash value is bound to the device's unique hardware identifier for storage.

[0016] Furthermore, the judicial evidence preservation blockchain consortium chain mentioned in step S6 adopts the PBFT consensus algorithm, and the block generation time is ≤10 seconds; before the evidence preservation data packet is uploaded, it is encrypted and transmitted via HTTPS protocol, and the data transmission log is recorded and synchronized to the blockchain consortium chain during the transmission process.

[0017] This invention also discloses a system for judicial evidence preservation protection based on this method for preventing data tampering on rooted / jailbroken devices, comprising: Hardware Trust Module: This is either Android Trust Zone or iOS Secure Enclave, used to build a TEE, store the device's unique hardware identifier, the native camera driver's digital signature public key, and a list of heterogeneous trusted time sources, and generate and store the hardware baseline hash value. Root / Jailbreak Detection Module: Runs on TEE, used to verify the integrity of mobile terminal system partitions, detect unauthorized communication links between TEE and REE, determine device status, and manage evidence storage permissions; Multi-source time synchronization module: running on TEE, used to obtain time data from Beidou satellite time, National Time Service Center NTP server and blockchain consortium chain nodes, filter abnormal time sources and generate trusted timestamps, and verify REE local time in real time; Multimodal location verification module: running on TEE, used to collect GPS sensor data, Wi-Fi hotspot data and base station data, verify GPS sensor hardware signature, build location credibility model and determine the credibility of location data; Camera driver protection module: running on TEE, used to verify the native camera driver digital signature and sensor parameters, perform hash calculation on image data containing EXIF ​​information and generate image hash value; Blockchain Evidence Preservation Module: Used to receive evidence preservation data packets after TEE signature, complete blockchain consortium chain evidence preservation through PBFT consensus algorithm, and provide hash comparison function during judicial verification; Anomaly Alarm Module: When an untrusted device, time tampering, or abnormal location is detected, an alarm is sent to the blockchain consortium chain and the device hardware identifier and tampering log are recorded.

[0018] Furthermore, the standard for the multi-source time synchronization module to eliminate abnormal time sources is: the deviation between the time data and the average time of the multi-source sources exceeds ±5 seconds; the standard for the multi-modal location verification module to determine the reliability of the location is: the GPS latitude and longitude fall within ±50 meters of the physical address of the Wi-Fi hotspot and overlap with the latitude and longitude range of the base station.

[0019] Furthermore, the judicial evidence storage blockchain consortium chain nodes connected to the blockchain evidence storage module include at least two notary office nodes and at least one court node; after the evidence storage data packet is uploaded to the blockchain, a unique evidence storage number is generated, which is associated with the device's unique hardware identifier and is used to quickly retrieve the evidence storage data during judicial verification.

[0020] Compared with the prior art, the present invention has the following outstanding substantive features and significant technical advancements: 1. Hardware-level trusted root protection, completely blocking root / jailbreak system-level tampering. Existing technologies mostly rely on software-level detection of root / jailbreak, which is easily bypassed by hooking tools. This invention builds a TEE based on the Android TrustZone or iOS Secure Enclave built into the mobile terminal. The core logic such as device trust detection, driver verification, and data encryption are all placed in the hardware-isolated TEE. Root / jailbreak tools cannot tamper with the verification rules and data in the TEE, eliminating the risk of "system kernel tampering causing protection failure" from the bottom layer. The protection level is far higher than that of traditional software solutions.

[0021] 2. Multi-source heterogeneous time synchronization ensures the uniqueness of judicial evidence preservation time sequence. Existing technologies generally rely on a single NTP server for time synchronization, which is vulnerable to man-in-the-middle attacks and tampering. This invention accesses heterogeneous trusted time sources such as BeiDou satellite time, National Time Service Center NTP, and blockchain consortium chain node time through a TEE. It uses an average value and standard deviation screening mechanism to eliminate abnormal time sources. The generated trusted timestamp is signed by the TEE and then uploaded to the blockchain. At the same time, it is compared with the local time of the rich execution environment in real time. If there is a significant deviation, the evidence collection is blocked, ensuring the consistency between the timestamp of judicial evidence and the real time, and solving the problem of evidence time sequence failure caused by "time anchor forgery".

[0022] 3. Multimodal location collaborative verification, covering location credibility verification across all scenarios. Existing technologies rely solely on a single GPS signal to verify location, which is prone to disconnection and cannot identify virtual locations in scenarios where GPS is obstructed. This invention uses a TEE to simultaneously collect GPS, Wi-Fi hotspot, and base station data, and combines multi-source data cross-verification to confirm the credibility of the location. This not only avoids the risk of forgery by virtual location tools, but also uses Wi-Fi and base station data to supplement the location information in scenarios where GPS is obstructed, thus meeting the requirement of "full-scenario location traceability" for judicial evidence collection.

[0023] 4. Hardware-level binding of camera drivers prevents forgery of acquisition sources and image tampering. Existing technologies do not associate camera drivers with trusted hardware modules, making it impossible to identify illegal driver replacements. This invention verifies the digital signature and sensor parameters of the native camera driver in the TEE (Trusted Equipment Environment). Only after verification is shooting allowed. Furthermore, image data is directly hashed in the TEE and bound to the device hardware identifier. This not only prevents the implantation of false EXIF ​​data due to driver tampering, but also proves that the image comes from a genuine evidence collection device by binding the hardware identifier to the image hash, thus solving the pain point of "untraceable source of data collection" in judicial evidence preservation.

[0024] 5. A closed-loop evidence storage system via a judicial consortium blockchain ensures that evidence is verifiable throughout the entire process. Existing blockchain-based evidence storage technologies often lack a traceability mechanism for judicial recognition. This invention's blockchain consortium chain includes notary offices and court nodes, employs a consensus algorithm to upload data to the chain, and uploads evidence data packets after TEE signature, simultaneously generating a full-process audit log of "collection-transmission-on-chain" and a unique evidence storage number. During judicial verification, the integrity of the evidence can be confirmed through multi-node hash comparison and TEE signature verification, fully complying with the requirement of "full traceability of the evidence chain" in relevant regulations on electronic data evidence, significantly improving the judicial recognition of the stored evidence data. Attached Figure Description

[0025] Figure 1 This is a logic block diagram of the evidence preservation and protection method of the present invention.

[0026] Figure 2 This is a logic block diagram of the evidence preservation and protection system of the present invention. Detailed Implementation

[0027] The following detailed explanation of the present invention's method and system for preventing data tampering on rooted / jailbroken devices in judicial evidence collection scenarios using two typical mobile terminal scenarios: Android phones and iOS phones. The following embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0028] Explanation of key terms and abbreviations 1. TEE (Trusted Execution Environment): An isolated execution environment built into mobile terminal hardware (such as SoC chip), with independent computing and storage resources and secure access control. It can resist system-level tampering after rooting / jailbreaking and only runs trusted and verified code and data. 2. REE (Rich Execution Environment): The conventional operating system environment of a mobile terminal (such as Android OS for Android and iOS system for iOS), which includes user applications, system services, etc. Rooting / jailbreaking operations mainly compromise the security boundaries of the REE. 3. TrustZone: A hardware trusted module integrated into the SoC chip of Android devices (such as Qualcomm Snapdragon and Huawei Kirin). It is the core carrier for building TEE and can achieve physical isolation between REE and TEE. 4. Secure Enclave: The hardware trusted module built into the A-series chips (such as A16 and A17) of iOS devices is dedicated to storing encryption keys and performing sensitive verification logic. It is a core component of the TEE of iOS devices. 5. PBFT (Practical Byzantine Fault Tolerance): A consensus algorithm commonly used in blockchain consortium blockchains, which can ensure the consistency and immutability of on-chain data when some nodes are abnormal (such as failure or malicious tampering). 6. SHA-256: A hash algorithm that converts data of any length into a fixed-length 256-bit hash value for verifying data integrity (if the data is tampered with, the hash value will change significantly). 7. LAC (Location Area Code): A code used in mobile communication networks to identify the coverage area of ​​a base station. It works in conjunction with CI (Cell Identity) to locate the physical location range of the base station. Implementation Prerequisites 1. Hardware environment: Mobile terminals must support TEE (Android devices must integrate TrustZone, and iOS devices must include SecureEnclave), and have a GPS module, Wi-Fi module, cellular communication module (supporting base station data collection), and a rear camera (supporting native driver verification). The judicial evidence preservation blockchain consortium chain has been deployed, with nodes including at least two notary offices (such as Beijing Fangyuan Notary Office and Yantai Lanhai Notary Office) and one court (such as an intermediate people's court). It adopts the PBFT consensus algorithm, and the block generation time is ≤10 seconds. 2. Software Environment: Android devices: System version ≥ Android 11 (ensure TrustZone functions properly and supports secure communication between TEE and REE). iOS devices: System version ≥ iOS 14 (ensure that Secure Enclave can be called normally and support strict sandbox permission control). The mobile terminal comes pre-installed with a certificate storage APP similar to "EasyStore" (hereinafter referred to as "APP"). The APP has been certified by the mobile terminal manufacturer and has the permission to call TEE, sensors and system interfaces. Third-party service interfaces have been integrated: including BeiDou satellite timing interface, National Time Service Center NTP server interface, third-party map service API (such as Gaode Map Open Platform API, used to obtain Wi-Fi hotspot physical addresses), and operator base station location query API (such as China Mobile base station positioning API). Example 1: Judicial Evidence Preservation Based on an Android Phone (Huawei Mate 60 Pro, with integrated TrustZone) This embodiment takes an Android phone (Huawei Mate 60 Pro, equipped with Kirin 9000S chip, built-in TrustZone) as an example, and the specific operation corresponding to steps S1-S6 of claim 1 is as follows: Step S1: TEE Construction and Hardware Baseline Data Initialization 1. Activate TrustZone and build the TEE: When the evidence storage APP is launched for the first time, it sends an activation request to TrustZone of the Kirin 9000S chip through the "Trusted Basic Service API" provided by Huawei HarmonyOS. After TrustZone verifies the APP's manufacturer signature (which needs to be filed in advance 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 for filing). 2. Pre-store hardware benchmark data: The TEE reads the device's unique hardware identifier through the hardware interface, including: SoC serial number (SN code of Kirin 9000S chip: K9000S12345678); Camera sensor ID (ID of the rear main camera Sony IMX800: IMX800-7890); GPS chip serial number (Huawei self-developed GPS chip serial number: HWGPS-202401); Simultaneous pre-storage: Native camera driver digital signature public key (Huawei's official Camera HAL layer driver signature public key: PublicKey_HW_Camera_2024); List of 3 heterogeneous trusted time sources (BeiDou satellite time service interface address, National Time Service Center NTP server address: ntp.ntsc.ac.cn, blockchain consortium chain court node IP: 10.100.50.20). 3. Generate and synchronize hardware baseline hashes: The TEE uses the SHA-256 algorithm to hash the combined data of "hardware identifier + camera driver public key + time source list" to generate a hardware baseline hash value (example: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2). This hash value is then synchronized to the judicial evidence preservation blockchain consortium chain via HTTPS protocol (with TEE private key signature). After the consortium chain node verifies the signature, it associates the hash value with the device SoC serial number and stores it, completing the initialization.

[0029] Step S2: Device Trust Status Detection (Anti-Root Verification) 1. System partition integrity verification: TEE reads the / system partition of the Android system through the "TrustZone file access interface" to detect the presence of root characteristic files: Check if the su binary file (the core executable file with root privileges) exists in the paths " / system / xbin / su" and " / system / bin / su". Check if the installation directory for Magisk (a mainstream rooting tool) exists in the path " / data / app / com.topjohnwu.magisk"; If any of the above files / directories exist, mark the device as "root risk state". 2. Monitoring of TEE and REE communication links: TEE monitors memory access requests initiated by REE (Android system) to TEE in real time, and only allows "trusted interfaces pre-built by the evidence-keeping APP" (such as time synchronization interface, sensor data reading interface) to access TEE memory; if an unregistered access request is detected (such as an unknown application attempting to read hardware reference data in TEE), it is judged as "unauthorized communication" and the device is marked as "untrusted state". 3. Risk Management: If a device is marked as "Root risk state" or "untrusted state", the evidence storage APP will immediately pop up a prompt that "the device is at risk of tampering and judicial evidence storage is prohibited", disable evidence collection functions such as taking pictures, recording videos, and positioning, and send an abnormal alarm (including device SoC serial number, risk type, and detection time) to the blockchain consortium chain through TEE. The consortium chain records the alarm log for subsequent traceability.

[0030] Step S3: Generate a trusted timestamp (to prevent time anchor forgery) 1. Acquisition of multi-source time data: TEE synchronizes time through three types of heterogeneous trusted time sources: BeiDou satellite time: Receive the BeiDou satellite time signal through the BeiDou positioning module of your mobile phone and parse it to obtain the UTC time (example: 2024-05-20 14:30:00.000). National Time Service Center NTP Time: Access “ntp.ntsc.ac.cn” through the encrypted network module built into the TEE (to avoid REE tampering), and use the TLS 1.3 protocol to transmit and obtain the UTC time returned by the NTP server (example: 2024-05-20 14:30:00.002). Blockchain consortium chain node time: Send a time request to the consortium chain court node (IP: 10.100.50.20) to obtain the node's local UTC time (example: 2024-05-20 14:30:00.001). 2. Screening for abnormal time sources: TEE calculates the average (2024-05-20 14:30:00.001) and standard deviation (0.001 seconds) of the three types of time data, and removes abnormal sources whose deviation exceeds a preset threshold (±5 seconds; in this embodiment, the deviation of all time sources is less than the threshold and no removal is required); the average value is used as a "trusted timestamp", and the timestamp is signed with the TEE private key (signature value: Sig_Time_20240520143000). 3. Real-time time verification: TEE reads the REE local time (time in Android system settings) every 10 seconds and compares it with a trusted timestamp. If a deviation of more than ±2 seconds is found (e.g., the REE time is tampered with to 2024-05-20 14:29:58), the current evidence collection operation is immediately stopped, the "time tampering log" (including the time before and after the tampering and the deviation value) is saved, and a time anomaly alarm is sent to the blockchain consortium chain.

[0031] Step S4: Multimodal position verification (to prevent spatial anchor point forgery) 1. Multi-source location data acquisition: TEE collects three types of data synchronously through the mobile phone hardware interface: GPS sensor data: Read the latitude and longitude (example: 31.2304°N, 121.4737°E) and number of satellites (12) output by the GPS chip, and verify the hardware signature of the GPS chip (to ensure that the data comes from the native GPS module and is not forged by a virtual positioning tool). Wi-Fi hotspot data: Collect the MAC address (example: AA:BB:CC:DD:EE:FF) and signal strength (-65dBm) of nearby Wi-Fi hotspots; Base station data: Read the LAC (Location Area Code: 1234) and CI (Cell Identifier: 5678) of the currently connected base station. 2. Location data cross-validation: TEE connects to the Gaode Map Open Platform API, inputs the MAC address of the Wi-Fi hotspot, and obtains the physical address latitude and longitude of the hotspot (example: 31.2305°N, 121.4738°E). TEE connects to China Mobile's base station positioning API, inputting LAC=1234 and CI=5678 to obtain the latitude and longitude range covered by the base station (example: 31.2300°N-31.2310°N, 121.4730°E-121.4740°E). Construct a location credibility model: Determine whether the GPS latitude and longitude (31.2304°N, 121.4737°E) falls within ±50 meters of the Wi-Fi physical address (yes), and whether it overlaps with the latitude and longitude range of the base station (yes), and determine that the "location is credible". 3. Exception handling: If the GPS latitude and longitude deviates too much from the Wi-Fi / base station address (e.g., GPS displays "31.2500°N, 121.5000°E", exceeding the Wi-Fi ±50 meter range), the location is determined to be "unreliable". The evidence storage app refuses to generate location-related evidence storage data and prompts "Location data is abnormal, please check the environment or device status".

[0032] Step S5: Camera source protection (preventing source spoofing) 1. Camera driver integrity verification: Before the evidence-keeping app calls the camera, the TEE reads the Android system's Camera HAL layer driver (path: / vendor / lib64 / hw / camera.qcom.so) through the "TrustZone driver verification interface", extracts the driver's digital signature, and compares it with the "native camera driver public key (PublicKey_HW_Camera_2024)" pre-stored by the TEE; if the signatures match, it is determined that the driver has not been tampered with. 2. Camera sensor parameter verification: The TEE reads real-time parameters from the camera sensor via a hardware interface, including: Pixel size (1 / 1.49 inches, consistent with pre-stored baseline parameters); Exposure time (1 / 100 second, with a deviation from the pre-stored reference parameter ≤ ±10%). White balance parameters (4500K, deviation from preset reference parameters ≤ ±10%). If all parameters meet the requirements, the camera is allowed to start; if any parameter deviates beyond the limit (such as the pixel size being tampered with and displayed as "1 / 2.0 inch"), the camera is prohibited from being called and a "driver parameter abnormality" log is recorded. 3. Image hash generation: After the camera finishes capturing the image, the raw image data (including complete EXIF ​​information such as shooting time, device model, and GPS location) is directly transmitted to the TEE. The TEE uses the SHA-256 algorithm to calculate the hash value of the image data (example: c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2) and binds the hash value with the device SoC serial number (K9000S12345678) for storage.

[0033] Step S6: Blockchain Evidence Storage and Judicial Verification 1. Packaging and signing of evidence storage data packets: TEE packages the following data into a "proof data package": Trusted timestamp (2024-05-20 14:30:00.001) and timestamp signature (Sig_Time_20240520143000); Location reliability results (“reliable”) and raw GPS / Wi-Fi / base station data; Image hash value (c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2); Unique hardware identifier for the device (SoC serial number + camera sensor ID + GPS chip number). TEE uses its built-in private key to sign the evidence storage data packet, generating a signature value (Sig_Evidence_202405201430). 2. Data packet upload to the blockchain: The evidence storage app uploads the "evidence storage data packet + TEE signature value" to the judicial evidence storage blockchain consortium chain via the HTTPS protocol; the consortium chain nodes use the PBFT algorithm to perform consensus verification (node ​​confirmation is completed within 3 seconds). After successful verification, a unique evidence storage number is generated (example: EZ202405201430001), and the data packet is associated with the evidence storage number for storage. 3. Judicial verification procedure: When conducting judicial verification, the court or notary office retrieves the evidence storage data package from the blockchain using the evidence storage number (EZ202405201430001) and performs the following verification: Verify the data packet signature (Sig_Evidence_202405201430) using the TEE filing public key to confirm that the data packet has not been tampered with; The "hardware base hash value" stored in the blockchain is retrieved and compared with the hash value recalculated from the device hardware identifier in the data packet to confirm that the device identity is consistent. Verify the spatiotemporal consistency of "timestamp-location-image" (e.g., the image EXIF ​​time matches the trusted timestamp, and the GPS location matches the Wi-Fi / base station address). After all verifications are passed, the evidence data is confirmed to have legal validity.

[0034] Example 2: Judicial Evidence Preservation Based on iOS Phone (iPhone 15, with Secure Enclave Integration) This embodiment uses an iOS phone (iPhone 15, equipped with A17 Pro chip, built-in Secure Enclave) as an example. The core process is the same as in Embodiment 1, with only some operations adjusted for iOS system characteristics. The specific differences are as follows: Step S1: TEE Construction (based on Secure Enclave) 1. The evidence storage app activates the SecureEnclave on the A17 Pro via Apple's "Secure Enclave Access API" to generate an asymmetric key pair (the private key cannot be exported, and the public key is uploaded to the blockchain for filing). 2. The pre-stored unique hardware identifiers for the device include: A17 Pro chip serial number (A17Pro12345678), rear camera sensor ID (Sony IMX920-9012), and GPS chip number (Apple GPS-2024). 3. The native camera driver is signed with the iOS AVFoundation underlying driver corresponding to the public key (PublicKey_AVFoundation_2024 provided by Apple).

[0035] Step S2: Device Trust Status Detection (Anti-Jailbreak Verification) 1. Jailbreak Signature Detection: TEE uses the Secure Enclave's "sandbox permission interface" to detect the presence of jailbreak tool signature files (such as / Applications / Cydia.app, / Library / MobileSubstrate / MobileSubstrate.dylib); it also attempts to access directories outside the sandbox (such as / private / var / root). If the directory contents can be read, it is determined to be in "jailbroken state". 2. Communication Link Monitoring: Monitors access requests from REE (iOS system) to Secure Enclave, allowing only Apple-certified "Judicial Evidence Preservation App Interface" access, and directly blocking unregistered requests.

[0036] Step S5: Camera driver verification (for iOS system) 1. The verification object is the iOS AVFoundation underlying driver (path: / System / Library / Frameworks / AVFoundation.framework / AVFoundation), extract the driver signature and compare it with the pre-stored public key (PublicKey_AVFoundation_2024); 2. Camera sensor parameter verification includes: sensor pixel size (1 / 1.28 inch), exposure time (1 / 120 second), white balance parameter (4800K), and the deviation threshold remains ≤±10%.

[0037] Additional notes on handling other abnormal scenarios: 1. Time source anomaly handling: If the deviation of the multi-source time data in step S3 exceeds ±5 seconds (such as when the Beidou satellite signal is interrupted, only the NTP and blockchain node time are available, and the deviation reaches ±8 seconds), the TEE will immediately activate the "judicial trusted server backup time source" (encrypted time data issued in real time by the court node) to ensure the generation of trusted timestamps; 2. Hardware Trusted Module Failure Handling: If the TEE (TrustZone / Secure Enclave) cannot be activated, the evidence storage APP will directly prompt "Device hardware trusted module is abnormal, unable to perform judicial evidence storage", and record the fault log (including device model and system version) to facilitate subsequent device troubleshooting; 3. Blockchain Disconnection Handling: If the data packet for evidence storage fails to be uploaded to the blockchain in step S6 (e.g., due to network interruption), the TEE will encrypt and store the data packet locally on the mobile phone (the encryption key is generated by the TEE). Once the network is restored, the data packet will be automatically re-uploaded to avoid data loss.

[0038] Those skilled in the art can reproduce this invention on other TEE-supporting mobile terminals such as Android tablets and iOS tablets based on the above embodiments. Only the "hardware identifier reading interface", "driver path" and "third-party API interface parameters" need to be adjusted according to the terminal hardware model and system version, without changing the core logic of this invention.

Claims

1. A judicial evidence protection method for preventing Root / jailbreak device data tampering, characterized in that, The method comprises the following steps: S1: Constructing a TEE based on a hardware trusted module built in a mobile terminal, the hardware trusted module being an Android Trust Zone or an iOS Secure Enclave; pre-storing, in the TEE, a device unique hardware identifier, a native camera driver digital signature public key and a list of three or more heterogeneous trusted time sources, performing 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 comprising notary offices and court nodes; S2: Running a trusted state detection program in the TEE, determining whether the device is in an untrusted state of being rooted or jailbroken by checking the integrity of a mobile terminal system partition and detecting unauthorized communication links between the TEE and the REE; If it is determined that the device is in an untrusted state, immediately disabling the evidence storage function, stopping the evidence collection operation and sending an abnormal device alarm to the blockchain consortium chain; S3: Obtaining time data from the heterogeneous trusted time sources through the TEE, the heterogeneous trusted time sources at least including a Beidou satellite time, a national time service center NTP server time and a blockchain consortium chain node local time; performing average value and standard deviation calculation on the multi-source time data, eliminating abnormal time sources deviating from the average value by more than a preset threshold, and taking the average value of the remaining time data as a trusted timestamp; real-time comparing the REE local time with the trusted timestamp, and if the deviation is more than ±2 seconds, determining that the time is tampered with, stopping the evidence collection and recording the tampering log; S4: Synchronously collecting GPS sensor data, Wi-Fi hotspot data and base station data of the mobile terminal through the TEE, checking the hardware signature of the GPS sensor in the TEE to confirm the authenticity of the data source; constructing a location trustworthiness model, and if the GPS longitude and latitude fall within a range of ±50 meters corresponding to the physical address of the Wi-Fi hotspot and overlap with the base station longitude and latitude range, determining that the location is trustworthy; if it is determined that the location is untrustworthy, refusing to generate evidence storage data; S5: Before calling the camera of the mobile terminal, checking the consistency of the digital signature of the native camera driver with the pre-stored public key in the TEE, and checking whether the deviation of the camera sensor parameters from the pre-stored reference parameters in the TEE is ≤±10%; If both checks pass, after taking an image, performing hash calculation on the image data containing complete EXIF information in the TEE to generate an image hash value; If any check fails, the camera is prohibited from being called; S6: Packing the trusted timestamp, the location trustworthiness result, the image hash value and the device unique hardware identifier into an evidence storage data packet in the TEE, signing the evidence storage data packet through a private key built in the TEE, and uploading the evidence storage data packet to the judicial evidence blockchain consortium chain to complete the evidence storage; during judicial verification, the evidence storage data packet is called through the blockchain to be compared with the hardware reference hash value, and it is confirmed that the data has not been tampered with.

2. The method of claim 1, wherein the method further comprises: The device unique hardware identifier in step S1 comprises a SoC serial number of the mobile terminal, a camera sensor ID and a GPS chip number, and the hardware reference hash value is generated by using an SHA-256 algorithm.

3. The method of claim 1, wherein the method further comprises: The system partition integrity verification in step S2 includes detecting whether the su binary file exists in the Android terminal / system partition, detecting whether the Cydia.app file and the out-of-sandbox directory access permission exist in the iOS terminal; and the unauthorized communication link detection includes monitoring whether the REE initiates an unrecorded memory reading request to the TEE.

4. The method of claim 1, wherein the method further comprises: The preset threshold in step S3 is ±5 seconds; and after the trusted timestamp is generated, the timestamp signature is added to the trusted timestamp by the TEE, and the timestamp signature and the trusted timestamp are synchronized to the blockchain consortium chain.

5. The method of claim 1, wherein the method further comprises: The Wi-Fi hotspot data in step S4 includes the MAC address and signal strength of the Wi-Fi hotspot, and the Wi-Fi hotspot physical address is obtained by connecting to a third-party map service API; and the base station data includes the LAC and CI of the base station, and the base station latitude and longitude range is obtained by connecting to an operator location query API.

6. The method of claim 1, wherein the method further comprises: The camera sensor parameters in step S5 include the sensor pixel size, exposure time and white balance parameters; the image hash value is calculated and generated by using the SHA-256 algorithm, and the image hash value is bound and stored with the unique hardware identifier of the device.

7. The method of claim 1, wherein the method further comprises: The judicial evidence blockchain consortium chain in step S6 adopts the PBFT consensus algorithm, and the block generation time is less than or equal to 10 seconds; before the evidence data packet is uploaded, the transmission is encrypted by using the HTTPS protocol, and the data transmission log is recorded and synchronized to the blockchain consortium chain during the transmission process.

8. A Root / Jailbreak device data tamper-resistant judicial evidence system, which implements the Root / Jailbreak device data tamper-resistant judicial evidence protection method of any one of claims 1-7, characterized in that, It includes: A hardware trusted module: an Android Trust Zone or an iOS Secure Enclave, used for building a TEE, storing a unique hardware identifier of a device, a native camera driver digital signature public key and a heterogeneous trusted time source list, generating and storing a hardware benchmark hash value; A root / jailbreak detection module: running in the TEE, used for verifying the system partition integrity of a mobile terminal, detecting an unauthorized communication link between the TEE and the REE, determining the device state and controlling the evidence permission; A multi-source time synchronization module: running in the TEE, used for obtaining time data from a Beidou satellite time, a national time service center NTP server and a blockchain consortium chain node, screening abnormal time sources and generating a trusted timestamp, and verifying the REE local time in real time; A multi-modal location verification module: running in the TEE, used for collecting GPS sensor data, Wi-Fi hotspot data and base station data, verifying the GPS sensor hardware signature, building a location credibility model and determining the location data credibility; A camera driver protection module: running in the TEE, used for verifying the native camera driver digital signature and the sensor parameters, performing hash calculation on the image data containing EXIF information and generating an image hash value; A blockchain evidence module: used for receiving the evidence data packet signed by the TEE, completing the blockchain consortium chain evidence by using the PBFT consensus algorithm, and providing a hash comparison function for judicial verification; An abnormal alarm module: used for sending an alarm to the blockchain consortium chain and recording the device hardware identifier and the tampering log when detecting that the device is untrusted, the time is tampered with or the location is abnormal.

9. The Root / Jailbreak device data tamper-resistant forensics protection system of claim 8, wherein, The standard for rejecting abnormal time sources by the multi-source time synchronization module is that the time data deviates from the multi-source time average value by more than ± 5 seconds; and the standard for determining that the position is reliable by the multi-modal position verification module is that the GPS longitude and latitude falls within the range of ± 50 meters of the physical address of the Wi-Fi hotspot, and overlaps with the longitude and latitude range of the base station.

10. The Root / Jailbreak device data tamper-resistant forensics protection system of claim 8, wherein, The judicial evidence blockchain alliance chain node connected by the blockchain evidence storage module includes at least two notary office nodes and at least one court node; after the evidence data packet is uploaded to the blockchain, a unique evidence number is generated, which is associated with the unique hardware identifier of the device, and is used for quickly retrieving the evidence data during judicial verification.

Images