A trusted data acquisition method based on a trusted platform module

Abstract

This application discloses a trusted data acquisition method based on a trusted platform module, relating to the field of computer security technology. It includes: a trusted data processing driver opening the trusted platform module device file in exclusive mode to obtain exclusive access; through the trusted platform module's desealing operation, the trusted platform module hardware automatically compares the value of the current platform configuration register with the baseline hash value at the time of sealing; if the comparison matches, the trusted platform module releases the key; the trusted data processing driver directly maps the sensor register space through the physical address to read the raw data; at least one environmental characteristic parameter of the external physical environment where the sensor is located is acquired; the raw data and the environmental characteristic parameter are combined to form a trusted data packet and signed using the key. This application solves the technical problems in the prior art, such as the inability to detect tampering before system startup, the risk of man-in-the-middle attacks in the data acquisition path, the inability to prove the correlation between data and the external environment, and the untrustworthiness of software verification, achieving end-to-end trusted verification from the hardware root of trust to sensor data and then to the external physical environment.

Description

Technical Field

[0001] This application relates to the field of computer security technology, specifically to a trusted data acquisition method based on a Trusted Platform Module (TPM). Background Technology

[0002] Product traceability has always been a top priority in the field of quality management. From national laws and regulations to individual consumers, there is an increasing emphasis on product traceability, especially in food safety and biopharmaceuticals. The purpose of product traceability is to ensure that data from the entire supply chain—from raw material procurement and processing or cultivation to sales—can be traced back to the data itself, making product quality verifiable. There are two key factors in product traceability data: the reliability of the data source and the immutability of the data during its transmission and use. Data sources include sensors, equipment used in production and use, and personnel.

[0003] With the rapid development of the Internet of Things (IoT) and the Industrial Internet, the reliability of sensor data has become increasingly prominent. Existing technologies for integrity checks after operating system startup have inherent flaws: if an attacker tampers with the operating system kernel or critical drivers before system startup, the detection program itself may have been modified, rendering the detection results unreliable.

[0004] Furthermore, even if the system itself is trustworthy, sensor data can still be tampered with or forged by intermediate drivers during acquisition and transmission. In existing solutions, data acquisition must pass through multiple driver layers, each of which can become a target for attack.

[0005] More importantly, existing technologies can only prove that "the data has not been tampered with" and "the system environment is trustworthy," but cannot prove that the data was collected in a specific external physical environment. For example, in cold chain logistics scenarios, temperature data may come from real refrigerated trucks or from simulated laboratory environments; in environmental monitoring scenarios, pollution data may come from designated monitoring points or from data replayed from other locations. Existing technologies cannot distinguish between these situations. Summary of the Invention

[0006] In existing technologies, the reliable acquisition of sensor data faces the following technical problems: (1) Tampering before system startup cannot be detected: If the attacker tampers with the operating system kernel or critical drivers before the system starts, the software detection program itself may have been tampered with after startup, resulting in unreliable detection results; (2) The data acquisition path is at risk of man-in-the-middle attack: Traditional data acquisition requires passing through multiple driver layers, each of which may become a target of attack, and the data is easily intercepted, tampered with or forged. (3) The correlation between the data and the external environment cannot be proven: Existing technology can only prove that the data has not been tampered with, but cannot prove that the data was collected in a specific external physical environment, such as whether the temperature data in cold chain logistics is actually from the transportation route, or whether the environmental monitoring data comes from the designated monitoring point. (4) The verification logic is executed by software, which poses a security risk: In the existing scheme, the integrity comparison is executed by software. Once the verification program itself is tampered with, the verification result is unreliable.

[0007] To address the aforementioned technical problems, this application provides a trusted data acquisition method based on a Trusted Platform Module (TPM), comprising the following core steps: Step 1: The trusted data processing driver opens the trusted platform module device file in exclusive mode to obtain exclusive access to the trusted platform module; Step 2: The trusted data processing driver program, through the unsealing operation of the trusted platform module, automatically compares the value of the current platform configuration register with the base hash value at the time of sealing. Step 3: When the comparison matches, the trusted platform module releases the key required for subsequent operations; Step 4: The trusted data processing driver directly maps the sensor register space through the kernel-mode physical address to read the raw sensor data; Step 5: The trusted data processing driver acquires at least one environmental characteristic parameter of the external physical environment where the sensor is located; Step 6: The trusted data processing driver program constructs a trusted data packet from the raw sensor data and the environmental feature parameters, and signs the trusted data packet using the key.

[0008] Furthermore, this application also includes the following preferred technical features: (1) Multiple implementation methods of exclusive mode: The exclusive mode is implemented through the file lock mechanism provided by the operating system, including setting the O_EXCL flag when calling the open function in Linux system, setting the O_EXLOCK flag when calling the open function in FreeBSD system, setting the FILE_SHARE_NONE parameter when calling the CreateFile function in Windows system, or setting the exclusive lock flag when calling the file lock interface in HarmonyOS system; (2) Establishment of the baseline hash value: The baseline hash value includes the baseline hash value of the operating system kernel and the baseline hash value of the trusted data processing driver itself, which are respectively bound to the platform configuration register of TPM. For example, PCR[8] corresponds to the operating system kernel and PCR

[14] corresponds to the trusted data processing driver, but not limited to this; during the production stage or when the system is first installed, the trust baseline is established through the sealing function of TPM. (3) Trust chain establishment and startup measurement: During the system startup process, a trust chain transmission mechanism of "measure first and then execute" is adopted. Starting from the hardware trust root, the BIOS / UEFI firmware, bootloader, operating system kernel and trusted data processing driver are measured level by level, and the measurement value is extended to the corresponding platform configuration register of TPM. (4) Four-layer trusted evidence chain: When the sensor data contains a built-in digital signature, the trusted data processing driver receives and verifies the sensor signature, and uses the sensor signature as the first layer of device-level evidence, which together with the second layer of environmental feature evidence, the third layer of platform configuration register evidence and the fourth layer of TPM signature evidence constitutes a four-layer trusted evidence chain. (5) Types and configurations of environmental feature parameters: The environmental feature parameters include at least one of the following: environmental photos, environmental videos, geographic location coordinates, environmental temperature, environmental humidity, atmospheric pressure, light intensity, altitude, electromagnetic field strength, noise level, acceleration, angular velocity, etc. Users can configure the required environmental feature types and precision according to the application scenario, and the trusted data processing driver will sign the configuration information together with the collected parameter values; (6) AI Intelligent Verification: The trusted data processing driver transmits sensor data to the AI ​​verification model running in the trusted execution environment through the kernel-mode security interface, verifies the physical laws, business logic, and statistical laws of the sensor data, generates a verification certificate, and signs it together with the sensor data by the trusted platform module.

[0009] Compared with the prior art, this application has the following beneficial effects: (1) Environmental credibility verification: By collecting external environmental characteristic parameters (including numerical sensor data such as temperature and humidity, GPS, and multimedia evidence such as environmental photos and environmental videos), the correlation between the data and the specific external environment is proved, which solves the problem that the existing technology cannot distinguish between real environment and simulated environment data, corresponding to claims 1, 7, and 8; (2) Cross-platform feasibility: The exclusive mode supports implementation on multiple operating systems, and has good cross-platform compatibility and industrial applicability, corresponding to claim 2; (3) System trust verification: PCR comparison is performed by TPM hardware to bind the operating system kernel to the third platform configuration register and the trusted data processing driver to the fourth platform configuration register, ensuring that the operating system and driver have not been tampered with before startup, corresponding to claims 1 and 3; (4) Complete trust chain transmission: The step-by-step measurement mechanism from the hardware root of trust to BIOS, bootloader, kernel and trusted data processing driver ensures the integrity and verifiability of the entire system startup process, forming an unforgeable trust chain, corresponding to claim 5; (5) Device trust verification: By receiving and verifying the sensor’s built-in signature, it is ensured that the data comes from a real physical device, corresponding to claim 6; (6) Data integrity verification: By constructing a four-layer chain of evidence, any third party only needs to verify the TPM signature to confirm the integrity and trustworthiness of the data, thus realizing trustless verification, corresponding to claims 1 and 6; (7) Intelligent data trust verification: By using an AI model to perform physical pattern recognition and anomaly detection on data in a trusted execution environment, abnormal data that does not conform to physical laws or forged data in a simulation environment can be identified before signing, which further improves the intelligent level of data trust, corresponding to claim 9. Attached Figure Description

[0010] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 Flowchart of trust chain establishment in this application embodiment Figure 2 This application's embodiment illustrates the trust chain transmission diagram during the startup process. Figure 3 A schematic diagram of the verification stage in an embodiment of this application. Figure 4 This application's embodiment illustrates a trusted data acquisition process. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the application will be described in further detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0012] It should be noted that, for ease of explanation, this embodiment uses the Linux operating system as an example for detailed description. However, those skilled in the art should understand that the technical solutions of this application are also applicable to other operating systems, such as HarmonyOS, UNIX, macOS, Windows, and embedded real-time operating systems (such as RT-Thread and Zephyr), which does not constitute a limitation on the scope of protection of this application.

[0013] Explanation of abbreviations in this embodiment: (1) TPM: Trusted Platform Module (2) PCR: Platform Configuration Register (3) TEE: Trusted Execution Environment (4) BIOS: Basic Input / Output System (5) UEFI: Unified Extensible Firmware Interface The code example in this embodiment is written in C, but this application is not limited to any specific programming language.

[0014] Embodiments of this application provide a trusted data acquisition method based on a trusted platform module. It includes the following stages.

[0015] Phase 1: Trust Chain Establishment Phase (Production Line / Initial Installation) See the example. Figure 1 The specific steps include: Step 101: Hardware trust root establishment; During the chip manufacturing stage, the trusted root of the CPU / chipset (such as Intel Boot Guard, AMD PSP) is embedded in the hardware. The code of the hardware trusted root is stored in ROM and cannot be modified by software.

[0016] Step 102: Calculate the kernel baseline hash; Compile to generate the operating system kernel image file vmlinuz, and calculate its hash value H_kernel using the SHA-256 algorithm: H_kernel = SHA256(vmlinuz).

[0017] Step 103: Calculate the trusted data processing-driven baseline hash; Compile to generate a trusted data processing driver module and calculate its hash value H_driver: H_driver = SHA256(trusted_driver.ko).

[0018] Step 104: Seal the base hash to TPM The kernel baseline hash and the trusted data processing driver baseline hash are sealed as "secret data" into the TPM and bound to the current state of the specified PCR (Platform Configuration Register). Only when the PCR value is completely consistent with the baseline value at the time of sealing when the system starts up later (i.e., the kernel / driver has not been tampered with) can the baseline hash be desealed and obtained to complete the integrity verification.

[0019] Operating steps and commands Sub-step 104-1: Preparatory work (extended PCR baseline) Before sealing the hash, the kernel / driver's baseline hash must be extended to the corresponding PCR so that the PCR records the "untampered trust baseline state": / / Example command content #1. Extend the kernel baseline hash to PCR[8] and establish a trust baseline for PCR[8]. tpm2_pcrextend 8:sha256="$H_kernel" #2. Extend the driving benchmark hash to PCR

[14] and establish a trust benchmark for PCR

[14] . tpm2_pcrextend 14:sha256="$H_driver" / / Command ended Sub-step 104-2: Create the baseline hash data file Write the baseline hash value calculated in steps 102 and 103 into a separate file as the "secret data" input sealed by the TPM: / / Example command content # 1. Write the kernel base hash $H_kernel to kernel_hash.bin (-n ensures no newline characters and guarantees a clean hash) echo -n "$H_kernel" > kernel_hash.bin # 2. Write the driver baseline hash $H_driver to driver_hash.bin echo -n "$H_driver" > driver_hash.bin / / Command ended Sub-step 104-3: Seal the kernel baseline hash to TPM Using the sealing function of the TPM2 tool, the kernel baseline hash is bound to the current state of PCR[8]: / / Example command content # Seal the kernel baseline hash, unsealing condition: the SHA256 value of the current PCR[8] = the PCR[8] value at the time of sealing. tpm2_seal -L "pcr8:sha256" -i kernel_hash.bin -o sealed_kernel.data / / Command ended Sub-step 104-4: Seal-driven benchmark hash to TPM Similarly, the driving baseline hash is bound to the current state of PCR

[14] : / / Example command content # Sealing-driven baseline hash, unsealing condition: the SHA256 value of the current PCR

[14] = the PCR

[14] value at the time of sealing. tpm2_seal -L "pcr14:sha256" -i driver_hash.bin -o sealed_driver.data / / Command ended.

[0020] Phase Two: Initiation Phase (Measure first, then execute) See the example. Figure 2 During system startup, each level of code measures the integrity of the next level before loading it, and then extends the measurement value into the TPM's PCR. This process is automatically completed by the trusted code at the previous level, without any subsequent software intervention.

[0021] For ease of understanding, the correspondence between the platform configuration registers and specific PCR numbers described in the claims of this embodiment is as follows: (1) First platform configuration register: corresponding to PCR[0] of TPM, used to store the integrity metric value of BIOS / UEFI firmware; (2) Second platform configuration register: corresponding to the PCR[4] of TPM, used to store the integrity metric value of the bootloader; (3) Third Platform Configuration Register: Corresponding to the PCR[8] of TPM, used to store the integrity metric value of the operating system kernel; (4) Fourth Platform Configuration Register: Corresponding to the PCR

[14] of TPM, used to store the integrity metric value of the Trusted Data Processing Driver;

[0022] Those skilled in the art will understand that the above correspondence is merely an illustrative example. In practical applications, the measurement values ​​of different components can be stored in other PCR numbers as needed, which does not depart from the protection scope of this application.

[0023] The specific steps include: Step 201: CPU hardware trust root measurement BIOS; After the system powers on, the CPU executes the trusted measurement root code embedded in the hardware. This code: (1) Load the authentication code module into CPU secure memory; (2) Verify the digital signature of the authentication code module; (3) The authentication code module measures the integrity of the BIOS / UEFI firmware; (4) Extend the measurement results to TPM PCR[0].

[0024] Step 202: BIOS measures the bootloader; Before the BIOS / UEFI firmware loads the bootloader (such as GRUB): (1) Calculate the hash value H_bootloader of the bootloader code; (2) Extend H_bootloader to TPM's PCR[4]; (3) The new value of PCR[4] = SHA256(original PCR[4] || H_bootloader); Only after the measurement is completed will the BIOS hand over control to the bootloader.

[0025] Step 203: The bootloader measures the kernel; The bootloader loads the operating system kernel before: (1) Read the kernel image file / boot / vmlinuz; (2) Calculate the kernel hash value H_kernel_current; (3) Extend H_kernel_current to the PCR of TPM[8]; (4) The new value of PCR[8] = SHA256(original PCR[8] || H_kernel_current); At this point, the kernel has not yet been executed. Even if the kernel has been tampered with, the tampered hash value will be recorded in PCR[8].

[0026] Step 204: Kernel metric trusted data processing driver; After the kernel boots up, before loading the trusted data processing driver: (1) Read the trusted data processing driver file trusted_driver.ko; (2) Calculate the driver hash value H_driver_current; (3) Extend H_driver_current to TPM PCR

[14] ; (4) The new value of PCR

[14] = SHA256(original PCR

[14] || H_driver_current); Only after the measurement is completed will the kernel load and execute the trusted data processing driver.

[0027] Through steps 201-204, each level of code in the startup process is measured by the previous level, and the measurement value is unidirectionally extended into the TPM's PCR. Due to the unidirectional extension characteristic of the PCR, once written, it cannot be modified or rolled back, ensuring the unforgeability of the measurement value.

[0028] Phase 3: Verification Phase (Comparison performed by TPM hardware) See the example. Figure 3 The Trusted Data Processing (TPM) driver does not perform integrity checks itself. Instead, it uses the TPM's sealing / unsealing mechanism to allow the TPM hardware to perform the check. This avoids the risk of software checks being tampered with.

[0029] The specific steps include: Step 301: Trusted data processing driver acquires exclusive access to TPM; The trusted data processing driver opens the TPM device file in exclusive mode during initialization: / / Example code content #include<linux / module.h> #include<linux / kernel.h> #include<linux / fs.h> #include<linux / io.h> #include<linux / tpm.h> #define TPM_DEVICE " / dev / tpm0" #define PCR_KERNEL 8 #define PCR_DRIVER 14 #define SEALED_KERNEL_INDEX 0x81000000 #define SEALED_DRIVER_INDEX 0x81000001 static int tpm_fd = -1; static int __init trusted_driver_init(void) { / / Turn on the TPM device in exclusive mode tpm_fd = open(TPM_DEVICE, O_RDWR | O_EXCL); if (tpm_fd < 0) { if (errno == EBUSY) { / / Failure to open indicates that TPM is already in use by another program. This in itself is a signal that the system may have been tampered with. pr_crit("TPM exclusive access failed, device may be occupied by other programs\n"); return -EBUSY; } pr_err("Unable to open TPM device: %d\n", errno); return -ENODEV; } pr_info("Successfully obtained exclusive access to TPM\n"); return 0; } / / End of code Afterward, the trusted data processing driver holds the file descriptor, ensuring that the TPM is not accessed by any other program during this period. The latest Linux kernel TPM driver implements a unified read-write locking mechanism, which, when opened in exclusive mode, prevents access from all other user-space programs and kernel internal modules.

[0030] Step 302: TPM hardware verification of kernel integrity; The trusted data processing driver first unseales the kernel baseline hash sealed in step 104 via TPM, then compares it with the actual hash of the current kernel image to complete kernel integrity verification. / / Example code begins #include<linux / crypto.h> #include<linux / fs.h> #include<linux / uaccess.h> #include<linux / utsname.h> #include<crypto / hash.h> #define SEALED_KERNEL_DATA_PATH " / path / to / sealed_kernel.data" #define KERNEL_IMAGE_PATH " / boot / vmlinuz" / ** * tpm2_unseal_file - Data from unsealing a TPM seal * @path: Path to the sealed data file * @out_data: Output buffer * @out_len: Buffer size This function invokes the TPM2_Unseal command using the already held TPM exclusive lock. The unsealing process is performed by TPM hardware, which automatically checks whether the current PCR value meets the sealing strategy. * Return value: 0 indicates success, negative numbers indicate an error code. / extern int tpm2_unseal_file(const char *path, uint8_t *out_data,size_t out_len); / ** * calculate_file_sha256 - Calculates the SHA256 hash of a file (kernel mode) * @path: file path * @out_hash: Output hash value buffer (length must be SHA256_DIGEST_SIZE) * Return value: 0 indicates success, negative numbers indicate an error code. / static int calculate_file_sha256(const char *path, uint8_t *out_hash) { struct file *file; struct crypto_shash *tfm; struct shash_desc *desc; char buf

[4096] ; ssize_t len; int ret = 0; file = filp_open(path, O_RDONLY, 0); if (IS_ERR(file)) return PTR_ERR(file); tfm = crypto_alloc_shash("sha256", 0, 0); if (IS_ERR(tfm)) { ret = PTR_ERR(tfm); goto out_close_file; } desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(tfm), GFP_KERNEL); if (!desc) { ret = -ENOMEM; goto out_free_tfm; } desc->tfm = tfm; desc->flags = 0; ret = crypto_shash_init(desc); if (ret < 0) goto out_free_desc; while ((len = kernel_read(file, buf, sizeof(buf), &file->f_pos))> 0) { ret = crypto_shash_update(desc, buf, len); if (ret < 0) goto out_free_desc; } if (len < 0) { ret = len; goto out_free_desc; } ret = crypto_shash_final(desc, out_hash); out_free_desc: kfree(desc); out_free_tfm: crypto_free_shash(tfm); out_close_file: filp_close(file, NULL); return ret; } static int verify_kernel_integrity(void) { uint8_t sealed_kernel_hash[SHA256_DIGEST_SIZE]; uint8_t current_kernel_hash[SHA256_DIGEST_SIZE]; int ret; / * Step 1: Unseal the kernel base hash sealed in Step 104 * / ret = tpm2_unseal_file(SEALED_KERNEL_DATA_PATH, sealed_kernel_hash, sizeof(sealed_kernel_hash)); if (ret < 0) { pr_crit("Kernel integrity verification failed: PCR[8] value mismatch, unable to unpack kernel baseline hash\n"); return -EACCES; } / * Step 2: Calculate the SHA256 hash of the current kernel image * / ret = calculate_file_sha256(KERNEL_IMAGE_PATH, current_kernel_hash); if (ret < 0) { pr_crit("Kernel integrity verification failed: Unable to calculate current kernel image hash\n"); return -EIO; } / * Step 3: Compare the baseline hash with the current hash * / if (memcmp(sealed_kernel_hash, current_kernel_hash, SHA256_DIGEST_SIZE) != 0) { pr_crit("Kernel integrity verification failed: The current kernel hash does not match the baseline hash\n"); return -EINVAL; } pr_info("Kernel integrity verification passed (PCR[8] match + hash consistency)\n"); return 0; } / / End of code The key feature of this operation is: (1) The unsealing operation is performed by TPM hardware, and the core verification logic is "current PCR[8] value = PCR[8] value when sealing in step 104"; (2) Successful unblocking only means that the PCR status is valid. It is necessary to compare the "baseline hash with the current kernel hash" to complete the full integrity verification. (3) If the kernel is tampered with, either the PCR[8] value will not match, causing the unsealing to fail, or the hash comparison will fail. Double verification ensures that the kernel has not been tampered with.

[0031] Step 303: TPM hardware verifies the integrity of the trusted data processing driver itself; The trusted data processing driver first deseals the driver baseline hash sealed in step 104 via TPM, and then compares it with the actual hash of the current driver module to complete its own integrity verification. / / Example code begins #include<linux / limits.h> #include<linux / utsname.h> #define SEALED_DRIVER_DATA_PATH " / path / to / sealed_driver.data" #define DRIVER_MODULE_PATH " / lib / modules / %s / kernel / trusted_driver.ko" / * Reuse the function defined in step 302 * / static int calculate_file_sha256(const char *path, uint8_t *out_hash); static int tpm2_unseal_file(const char *path, uint8_t *out_data,size_t out_len); static int verify_trusted_driver_self(void) { uint8_t sealed_driver_hash[SHA256_DIGEST_SIZE]; uint8_t current_driver_hash[SHA256_DIGEST_SIZE]; char module_path[PATH_MAX]; int ret; / * Full path to the driver module (including kernel version) * / snprintf(module_path, sizeof(module_path), DRIVER_MODULE_PATH, utsname()->release); / * Step 1: Unseal the driver base hash sealed in Step 104 * / ret = tpm2_unseal_file(SEALED_DRIVER_DATA_PATH, sealed_driver_hash, sizeof(sealed_driver_hash)); if (ret < 0) { pr_crit("Driver integrity verification failed: PCR

[14] value mismatch, unable to unpack driver baseline hash\n"); return -EACCES; } / * Step 2: Calculate the SHA256 hash of the current driver module * / ret = calculate_file_sha256(module_path, current_driver_hash); if (ret < 0) { pr_crit("Driver integrity verification failed: Unable to calculate current driver module hash\n"); return -EIO; } / * Step 3: Compare the baseline hash with the current hash * / if (memcmp(sealed_driver_hash, current_driver_hash, SHA256_DIGEST_SIZE) != 0) { pr_crit("Driver integrity verification failed: The current driver hash does not match the baseline hash\n"); return -EINVAL; } pr_info("Trusted data processing driver self-integrity verification passed (PCR

[14] matching + hash consistency)\n"); return 0; } / / End of code.

[0032] Step 304: Key acquisition based on verification results; When steps 302 and 303 are both successful, the trusted data processing driver obtains two important secret data: 1) kernel_secret: A key that can be used to prove the trustworthiness of the kernel; 2) driver_secret: The key required for subsequent operations of the trusted data processing driver;

[0033] If any unsealing fails, the trusted data processing driver determines that the system has been tampered with, refuses to continue execution, and logs the security event.

[0034] Phase Four: Trusted Data Acquisition Phase See the example. Figure 4 Once the verification is successful, the trusted data processing driver uses the obtained key to collect trusted data.

[0035] The specific steps include: Step 401: Direct reading of sensor data; Trusted data processing drivers directly map sensor register space via physical addresses: / / Example code begins #define SENSOR_PHYS_BASE 0xFC800000 / / Sensor physical address #define SENSOR_REG_SIZE 0x1000 / / Register space size #define DATA_REG_OFFSET 0x00 / / Data register offset static void __iomem *sensor_base; static struct resource *sensor_res; static int init_sensor_access(void) { / / Request sensor physical memory area sensor_res = request_mem_region(SENSOR_PHYS_BASE, SENSOR_REG_SIZE, "secure_sensor"); if (!sensor_res) { pr_err("Sensor memory area is already in use\n"); return -EBUSY; } / / Mapped to kernel virtual address space sensor_base = ioremap(SENSOR_PHYS_BASE, SENSOR_REG_SIZE); if (!sensor_base) { release_mem_region(SENSOR_PHYS_BASE, SENSOR_REG_SIZE); return -ENOMEM; } return 0; } static uint32_t read_sensor_data(void) { / / Directly read raw sensor data return ioread32(sensor_base + DATA_REG_OFFSET); } / / End of code This direct reading method bypasses any intermediate drivers, ensuring the reliability of the data source.

[0036] Step 402: External environment feature acquisition; The trusted data processing driver acquires environmental characteristic parameters of the external physical environment where the sensor is located. These parameters, together with the sensor data, constitute an indivisible trusted data unit, which is used to prove the correlation between the sensor data and specific external environmental conditions. / / Example code begins / / External environment feature data structure struct environment_features { / / Multimedia evidence uint8_t photo_hash

[32] ; / / Hash value of the environmental photo uint8_t video_metadata_hash

[32] ; / / Hash value of environmental video metadata / / Geographical location int64_t latitude; / / Latitude (1e7 degrees) int64_t longitude; / / Longitude (1e7 degrees) int32_t altitude; / / Altitude (cm) / / Environmental physical quantities int16_t temperature; / / Ambient temperature (0.1°C) int16_t humidity; / / Relative humidity (0.1%) uint16_t pressure; / / Atmospheric pressure (Pa) uint16_t light_intensity; / / Light intensity (lux) / / Motion state int16_t acceleration[3]; / / Triaxial acceleration (mg) int16_t angular_velocity[3]; / / Three-axis angular velocity (mdps) / / Time information uint64_t timestamp; / / Timestamp (ns) for data collection / / Configuration identifier uint32_t feature_mask; / / Enabled feature bitmap } __attribute__((packed)); / / Environmental sensor configuration (user configurable) struct environment_config { uint32_t enabled_features; / / Enabled environment features uint16_t sampling_rate; / / Sampling rate (Hz) uint8_t accuracy_level; / / Accuracy level uint8_t reserved; }; static struct environment_config env_config; static struct environment_features env_data; / / Initialize environmental sensors static int init_environment_sensors(struct environment_config *cfg) { / / Initialize the corresponding environmental sensors according to the configuration. if (cfg->enabled_features & FEATURE_GPS) { init_gps_sensor(cfg->sampling_rate); } if (cfg->enabled_features & FEATURE_TEMPERATURE) { init_temperature_sensor(cfg->sampling_rate); } / / ... Initialize other sensors return 0; } / / Collect external environmental features static void collect_environment_features(void) { / / Clear data structure memset(&env_data, 0, sizeof(env_data)); / / Collect corresponding environmental characteristics based on configuration. if (env_config.enabled_features & FEATURE_GPS) { read_gps_data(&env_data.latitude, &env_data.longitude, &env_data.altitude); } if (env_config.enabled_features & FEATURE_TEMPERATURE) { env_data.temperature = read_temperature(); } if (env_config.enabled_features & FEATURE_HUMIDITY) { env_data.humidity = read_humidity(); } if (env_config.enabled_features & FEATURE_PRESSURE) { env_data.pressure = read_pressure(); } if (env_config.enabled_features & FEATURE_ACCELERATION) { read_acceleration(env_data.acceleration); } / / Record timestamp env_data.timestamp = ktime_get_real_ns(); / / Record enabled features env_data.feature_mask = env_config.enabled_features; } / / End of code.

[0037] Step 403: Process the sensor's built-in signature; When the sensor supports its own signature, the trusted data processing driver receives and verifies the sensor signature: / / Example code begins struct signed_sensor_data { uint32_t value; uint8_t signature

[64] ; / / Sensor private key signature }; static int verify_sensor_signature(struct signed_sensor_data *ssd) { / / Verify signature using sensor public key if (sensor_verify(ssd->value, ssd->signature) == 0) { pr_info("Sensor signature verification passed\n"); return 0; } pr_warn("Sensor signature verification failed\n"); return -EINVAL; } / / End of code.

[0038] Step 404: AI verification step; The trusted data processing driver transmits the collected sensor data to the AI ​​verification model running in the Trusted Execution Environment (TEE); the AI ​​verification model performs physical law verification and statistical law verification (at least one) on the sensor data: wherein the physical law verification detects whether the sensor data conforms to physical laws such as the sensor's physical range and the rate of data change, and the statistical law verification detects whether the data conforms to historical statistical distribution through anomaly scores; The AI ​​verification model generates a verification certificate and calls the Trusted Platform Module (TPM) interface to jointly sign the verification certificate with the sensor data, ultimately outputting complete verification data containing the verification result, the verification certificate, and the TPM signature. / / Example code begins #define FEATURE_GPS 0x0001 #define FEATURE_TEMPERATURE 0x0002 #define FEATURE_HUMIDITY 0x0004 #define FEATURE_PRESSURE 0x0008 #define FEATURE_ACCELERATION 0x0010 / / Helper function declaration (must be implemented elsewhere) static int check_physical_law(const uint8_t* data, size_t len); static int tpm_sign_data(const uint8_t* data, size_t len, uint8_t*signature); static void tee_invoke_ai_service(const uint8_t* data, size_t len, struct ai_validation_result*result); / / Core structure of trusted data processing driver struct trusted_data_driver { uint8_t driver_id

[16] ; / / Unique driver identifier uint32_t sensor_data_len; / / Sensor data length uint8_t* sensor_data; / / Sensor data pointer }; / / AI verification result structure corresponding to claim 10 struct ai_validation_result { uint8_t physics_verify; / / Verify physical laws: 1 = conforms, 0 = does not conform uint8_t business_verify; / / Business logic verification: 1 = compliant, 0 = non-compliant (optional) uint8_t statistic_verify; / / Statistical pattern verification: 1 = conforms, 0 = does not conform float anomaly_score; / / Abnormal score (0-1, lower is more normal) uint8_t validation_proof

[32] ; / / AI validation proof (corresponding to the "validation proof" in claim 10) uint8_t tpm_signature

[64] ; / / TPM signature (joint signature of proof and data) }; / / 1. Example of calling an AI model via TEE (based on OP-TEE, with supplementary implementation) #include<tee_client_api.h> #define TEE_AI_UUID {0x12345678, 0x1234, 0x1234, {0x12, 0x34, 0x56,0x78, 0x90, 0xab, 0xcd, 0xef}} static int tee_invoke_ai_service(const uint8_t* data, size_t len,struct ai_validation_result* result) { TEEC_Context ctx; TEEC_Session sess; TEEC_Operation op; TEEC_UUID uuid = TEE_AI_UUID; uint32_t err_origin; int ret; / / Initialize TEE context ret = TEEC_InitializeContext(NULL, &ctx); if (ret != TEEC_SUCCESS) return -1; / / Open TEE session ret = TEEC_OpenSession(&ctx, &sess, &uuid, TEEC_LOGIN_PUBLIC,NULL, NULL, &err_origin); if (ret != TEEC_SUCCESS) { TEEC_FinalizeContext(&ctx); return -1; } / / Prepare parameters: transmit sensor data and receive AI verification results memset(&op, 0, sizeof(op)); op.paramTypes = TEEC_PARAM_TYPES(TEEC_MEMREF_INPUT, TEEC_MEMREF_OUTPUT, TEEC_NONE, TEEC_NONE); op.params[0].memref.buffer = (void*)data; op.params[0].memref.size = len; op.params[1].memref.buffer = result; op.params[1].memref.size = sizeof(struct ai_validation_result); / / Call the AI ​​verification function in the TEE (function ID=0) ret = TEEC_InvokeCommand(&sess, 0, &op, &err_origin); / / Clean up resources TEEC_CloseSession(&sess); TEEC_FinalizeContext(&ctx); return (ret == TEEC_SUCCESS) ? 0 : -1; } / / 2. Business logic verification example (industrial temperature threshold, supplementary implementation) static int check_business_rule(const uint8_t* data, size_t len) { / / Assume that the data contains a temperature value (uint16_t, 0.1°C) if (len < 2) return 0; uint16_t temp = *(uint16_t*)data; / / Cold chain logistics business rules: Temperature must be between -2°C and 8°C if (temp >= 20 && temp <= 80) { / / 20=2°C*10, 80=8°C*10 return 1; / / Conforms to business rules } return 0; / / Does not meet the requirements } / ** * @brief Trusted Data Processing Driver for AI Validation Model that Transmits Sensor Data to TEE * @param driver Trusted Data Processing Driver Instance * @return AI verification result (including TPM signature) / static struct ai_validation_result ai_validate_sensor_data(structtrusted_data_driver* driver) { struct ai_validation_result result = {0}; if (driver == NULL || driver->sensor_data == NULL) { return result; / / Exception handling } / / 1. Trusted data processing driver transmits sensor data to the AI ​​verification model in TEE. tee_invoke_ai_service(driver->sensor_data, driver->sensor_data_len, &result); / / 2. The AI ​​verification model performs at least one verification (example: physical laws + statistical laws + business logic). / / According to claim 10, at least one of physical law verification and statistical law verification shall be performed, and business logic verification is optional. / / This example executes three methods simultaneously, as a preferred implementation. / / Verification of physical laws: Whether the detection data conforms to physical laws (such as sensor range, rate of change). result.physics_verify = check_physical_law(driver->sensor_data,driver->sensor_data_len); / / Statistical pattern verification: Compare with historical statistical distributions (if the outlier score is less than the threshold, it conforms). result.statistic_verify = (result.anomaly_score < 0.8) ? 1 : 0; / / Business logic verification: Supplementary implementation (such as temperature threshold rules in industrial scenarios) result.business_verify = check_business_rule(driver->sensor_data); / / 3. Generate verification proof, and have TPM jointly sign the proof and sensor data. uint8_t data_to_sign

[1024] ; memcpy(data_to_sign, result.validation_proof, 32); memcpy(data_to_sign + 32, driver->sensor_data, driver->sensor_data_len); / / Call the TPM signature interface (Trusted Platform Module Signature) tpm_sign_data(data_to_sign, 32 + driver->sensor_data_len,result.tpm_signature); return result; } / / End of code.

[0039] Step 405: Data Signing; The trusted data processing driver uses the driver_secret obtained in step 304 to sign the sensor data and environmental features: / / Example code begins struct trusted_data_packet { / / First layer: Device-level evidence uint32_t sensor_value; uint8_t sensor_signature

[64] ; / / Sensor signature (if any) / / Second layer: Environmental feature evidence struct environment_features env; / / Third layer: Platform configuration register evidence uint64_t timestamp; uint32_t sequence; uint8_t pcr_kernel

[32] ; / / Current value of PCR[8] uint8_t pcr_driver

[32] ; / / Current value of PCR

[14] / / AI-verified evidence (optional, as additional information, still overridden by TPM signature) uint8_t ai_attestation

[32] ; / / Fourth layer: TPM signature evidence uint8_t tpm_signature

[256] ; } __attribute__((packed)); static atomic_t seq_counter = ATOMIC_INIT(0); static int sign_trusted_data(struct trusted_data_packet *packet) { size_t data_len; int ret; / / Fill data packet->sensor_value = read_sensor_data(); / / Collect external environmental features collect_environment_features(); memcpy(&packet->env, &env_data, sizeof(env_data)); packet->timestamp = ktime_get_real_ns(); packet->sequence = atomic_inc_return(&seq_counter); / / Read the current PCR value ret = tpm2_pcr_read(tpm_fd, PCR_KERNEL, packet->pcr_kernel); if (ret < 0) return ret; ret = tpm2_pcr_read(tpm_fd, PCR_DRIVER, packet->pcr_driver); if (ret < 0) return ret; / / Calculate the length of the data to be signed (including all fields, but excluding tpm_signature itself). data_len = offsetof(struct trusted_data_packet, tpm_signature); / / Use TPM for signing to generate fourth-level evidence return tpm2_sign(tpm_fd, packet, data_len, driver_secret, packet->tpm_signature); } / / End of code; In this embodiment, the trusted data packet contains four layers of evidence: the first layer is device-level evidence (sensor signature), the second layer is environmental feature evidence (environmental feature parameters), the third layer is platform configuration register evidence (PCR value and timestamp sequence number), and the fourth layer is TPM signature evidence (hardware endorsement). AI verification evidence is optional additional information, also included in the TPM signature scope, but not as an independent layer of evidence.

[0040] Step 406: Output trusted data; The signed data packet can be output to upper-layer applications or remote verification parties. Any third party can use the corresponding public key to verify the signature, thereby confirming that the data originates from a trusted environment and has not been tampered with.

[0041] / / Example code begins bool verify_trusted_packet(struct trusted_data_packet *packet) { / / Step 1: Verify TPM signature (hardware endorsement) if (!tpm_verify_signature(packet->tpm_signature)) return false; / / Step 2: Verify sensor signature (if applicable) if (packet->sensor_signature) { if (!sensor_verify_signature(packet->sensor_value, packet->sensor_signature)) return false; } / / Step 3: Verify the rationality of the external environmental characteristics / / For example, check if the GPS coordinates are within a reasonable range. if (!is_gps_coordinate_valid(packet->env.latitude, packet->env.longitude)) return false; / / Step 4: Verify PCR value (optional, expected value required) / / This requires the verifier to have the expected kernel hash. return true; } / / End of code; In this example, users can flexibly configure the external environmental features to be collected according to the application scenario: / / Example code begins / / Example of User Space Configuration Tool int configure_environment_features(void) { struct environment_config cfg; int fd; / / Open the control interface of the trusted data processing driver fd = open(" / dev / trusted_driver_ctl", O_RDWR); if (fd < 0) return -1; / / Set configuration parameters memset(&cfg, 0, sizeof(cfg)); / / Cold chain logistics scenario: requires GPS, temperature, and humidity monitoring cfg.enabled_features = FEATURE_GPS | FEATURE_TEMPERATURE |FEATURE_HUMIDITY; cfg.sampling_rate = 1; / / 1Hz cfg.accuracy_level = 2; / / High accuracy / / Send configuration to driver ioctl(fd, SET_ENVIRONMENT_CONFIG, &cfg); close(fd); return 0; } / / End of code; The trusted data processing driver signs the collected values ​​along with a user-configured environmental feature mask to ensure the traceability and non-repudiation of environmental features.

[0042] This application provides a four-layered trusted chain of evidence.

[0043] This application, combined with sensor-embedded signature technology and incorporating external environmental features, constructs a complete four-layer trusted evidence chain. See Table 1 for an example: Table 1

[0044] The four layers of evidence corroborate each other, meaning the attacker must breach them all simultaneously: 1) Sensor hardware security (extracting private key) 2) External physical environment (simultaneously faking multiple environmental parameters) 3) System integrity protection (PCR value tampering) 4) TPM hardware protection (forged signature) This is almost impossible to achieve in engineering practice.

[0045] In summary, this application organically combines a trusted data processing driver with a TPM exclusive access mechanism, complementing and synergizing with sensor-integrated signature technology, and introduces external environmental feature acquisition to construct a four-layer trusted evidence chain from the physical device to the external environment and then to the system environment, achieving the technical goal of ultimate data verification. Any third-party verifier only needs to verify the TPM signature to confirm the integrity and authenticity of all four layers of evidence, achieving true trustless verification. Specifically, through the organic combination of the trusted data processing driver and the TPM exclusive access mechanism, this application has the following beneficial effects and advantages: (1) Environmental credibility verification: By collecting external environmental characteristic parameters (including numerical sensor data such as temperature and humidity, GPS, and multimedia evidence such as environmental photos and environmental videos), the correlation between the data and the specific external environment is proved, which solves the problem that the existing technology cannot distinguish between real environment and simulated environment data, corresponding to claims 1, 8 and 9; (2) Cross-platform feasibility: The exclusive mode supports implementation on multiple operating systems, and has good cross-platform compatibility and industrial applicability, corresponding to claim 2; (3) System Trust Verification: By performing PCR comparison through TPM hardware, the operating system kernel is bound to the third platform configuration register and the trusted data processing driver is bound to the fourth platform configuration register, ensuring that the operating system and driver have not been tampered with before startup, corresponding to claims 1, 3 and 4; (4) Complete trust chain transmission: The step-by-step measurement mechanism from the hardware root of trust to BIOS, bootloader, kernel and trusted data processing driver ensures the integrity and verifiability of the entire system startup process, forming an unforgeable trust chain, corresponding to claim 6; (5) Device trust verification: By receiving and verifying the sensor’s built-in signature, it is ensured that the data comes from a real physical device, corresponding to claim 7; (6) Data integrity verification: By constructing a four-layer chain of evidence, any third party only needs to verify the TPM signature to confirm the integrity and trustworthiness of the data, thus realizing trustless verification, corresponding to claims 1 and 7; (7) Intelligent data trust verification: By using an AI model to perform physical pattern recognition and anomaly detection on data in a trusted execution environment, abnormal data that does not conform to physical laws or forged data in a simulation environment can be identified before signing, which further improves the intelligent level of data trust, corresponding to claim 10.

[0046] The above-described specific embodiments are preferred embodiments of this application and are not intended to limit this application. Any other changes or equivalent substitutions made without departing from the technical solution of this application are included within the protection scope of this application.

Claims

1. A data trust acquisition method based on a Trusted Platform Module (TPM), characterized in that, Includes the following steps: S1: Pre-establish trust chain: During the production phase or the first system installation, calculate the baseline hash value of the operating system kernel and trusted data processing driver, and bind it to the corresponding platform configuration register (PCR) through the sealing function of TPM. S2: The trusted data processing driver opens the TPM device file in exclusive mode, acquiring exclusive access to the TPM. S3: The trusted data processing driver program automatically compares the current PCR value with the baseline hash value at the time of sealing through the TPM unsealing operation. S4: When the comparison matches, the TPM releases the key required for subsequent operations; S5: The trusted data processing driver directly maps the sensor register space through the kernel-mode physical address to read the raw sensor data; S6: The trusted data processing driver acquires at least one environmental characteristic parameter of the external physical environment where the sensor is located; S7: The trusted data processing driver program constructs a trusted data packet from the sensor's raw data and environmental feature parameters, and signs it using the key.

2. The method according to claim 1, characterized in that, The exclusive mode is implemented through a file locking mechanism provided by the operating system, including at least one of the following: (1) In Linux systems, the O_EXCL flag is set when calling the open function; (2) In the FreeBSD system, the O_EXLOCK flag is set when calling the open function; (3) Set the FILE_SHARE_NONE parameter when calling the CreateFile function in Windows system; (4) Set an exclusive lock flag when calling the file lock interface in the HarmonyOS system.

3. The method according to claim 1, characterized in that, In the unsealing operation of the trusted platform module, the base hash value includes: (1) The base hash value of the operating system kernel is bound to the third platform configuration register of the TPM; (2) The baseline hash value of the Trusted Data Processing Driver itself is bound to the fourth platform configuration register of the TPM.

4. The method according to claim 1, characterized in that, It also includes the initiation metric step: During system startup, each level of code measures the integrity of the next level of code before loading the next level of code, and extends the measurement value to the corresponding platform configuration register of the trusted platform module to achieve "measure before execution", which is coordinated with the trust chain established in step S1.

5. The method according to claim 4, characterized in that, The startup measurement step specifically includes: (1) Hardware root of trust measures BIOS / UEFI firmware, extended to the first platform configuration register; (2) BIOS / UEFI measurement bootloader, extended to the second platform configuration register; (3) The bootloader measures the operating system kernel and extends it to the third-platform configuration register; (4) Operating system kernel measurement trusted data processing driver, extended to the fourth platform configuration register; The first to fourth platform configuration registers can correspond to the platform configuration registers of TPM, for example PCR[0], PCR[4], PCR[8], PCR[14], but are not limited thereto.

6. The method according to claim 1, characterized in that, The sensor data includes sensor data with a built-in signature, and the method further includes: The trusted data processing driver receives and verifies the digital signature that comes with the sensor. It uses the sensor signature as the first layer of device-level evidence, which together with the second layer of environmental feature evidence, the third layer of platform configuration register evidence, and the fourth layer of TPM signature evidence, constitutes a four-layer trusted evidence chain.

7. The method according to claim 1, characterized in that, The environmental characteristic parameters include at least one of the following: environmental photographs, environmental videos, geographic location coordinates, environmental temperature, environmental humidity, atmospheric pressure, light intensity, altitude, electromagnetic field strength, noise level, acceleration, angular velocity, and other measurable parameters that can characterize the external physical environment.

8. The method according to claim 1, characterized in that, The type and precision of the environmental feature parameters can be configured by the user according to the application scenario. The trusted data processing driver will sign the configuration information together with the collected parameter values ​​to ensure the traceability of environmental features.

9. The method according to claim 1, characterized in that, It also includes an AI verification step: The trusted data processing driver transmits sensor data to the AI ​​verification model running in a Trusted Execution Environment (TEE) through a kernel-mode security interface. The AI ​​verification model performs at least one of the following verifications on the sensor data: (1) Verification of physical laws: Check whether the data conforms to physical laws or natural laws; (2) Business logic verification: Detect whether the data conforms to business rules or industry standards; (3) Statistical regularity verification: Check whether the data conforms to the historical statistical distribution; The AI ​​verification model generates a verification certificate, which is then signed by the trusted platform module along with the sensor data.

Images