A trusted execution environment sanitization method for a data center robot at lease return

Abstract

The application discloses a kind of data center robot leasing returns time's trusted execution environment clean method and system, belong to robot safety control and data privacy protection technical field.The method is dynamically created in the trusted execution environment (TEE) chip of robot terminal Encrypted sandbox, the multi-modal data of tenant rental period is strictly isolated in sandbox;Cloud operation platform manages the ownership state of robot and verifies tenant credit;At the end of lease, TEE performs multiple overwriting security erasure to sandbox, destroys temporary key and closes sandbox;TEE generates signed erasure proof using non-exportable private key and writes into consortium chain for storage evidence;Finally, the read-only lock of system area and belonging owner private area is released, and the robot is rolled back to the ownership state.The application solves the technical problems of data residue, insecure ownership switching and post-audit in the shared robot scenario.

Description

Technical Field

[0001] This invention relates to the field of robot safety control and data privacy protection technology, specifically to a method and system for achieving rental data isolation, secure erasure upon return, and generation of auditable proof through a Trusted Execution Environment (TEE) when multiple users share the same data center robot. Background Technology

[0002] As data centers continue to expand, robots are widely used in scenarios such as data center inspection, equipment handling, security monitoring, and environmental monitoring. In the traditional model, each robot is tied to a specific area or specific personnel, resulting in low asset utilization and high maintenance costs. To reduce procurement costs and improve asset utilization, a robot sharing and leasing model has emerged in the industry—the same robot serves multiple users (renters) successively, and is returned to its owner (buyer) or platform after the rental period. This model is similar to car-sharing platforms, where robots become tradable "operating assets." However, existing shared robot solutions face the following pressing technical challenges: (1) High risk of data residue. After the lease expires, photos, voice commands, environmental scanning data, map cache, AI inference results, etc. stored locally by the tenant on the robot may remain in the file system. The next tenant or owner may be able to read the previous tenant's private data through data recovery tools. This problem is particularly serious in data center scenarios, because data center inspection data may contain highly sensitive information such as server serial numbers, network topology, and security policies. (2) Insecure ownership transfer. Ownership transfer in existing systems is mostly implemented at the application layer (Rich OS), relying on software logic to delete data. Attackers can recover "deleted" data by physically disassembling storage chips, exploiting operating system vulnerabilities to escalate privileges, or implanting persistent backdoors. Application-layer deletion essentially only removes the file system index reference; the data in the underlying storage blocks is not truly cleared. (3) Inability to audit and provide evidence afterward. Lack of an immutable erasure proof mechanism. When data breach disputes occur (e.g., a tenant claims "the data was stolen when I returned it"), the platform cannot provide cryptographic evidence that "the data has been completely erased." Existing logs can be tampered with by administrators and are not legally credible. (4) Lack of trust in the sharing economy model. Tenants are hesitant to use robots for sensitive tasks (such as inspection of classified computer rooms and maintenance of critical equipment) during the rental period because they do not trust the platform's verbal "deletion" promise. This directly limits the promotion of the robot sharing model in high-security scenarios such as finance, government affairs, and military industry. (5) Lack of physical privacy protection. Existing robots lack hardware-level privacy switches. The software-level "turn off camera" function can be bypassed by remote hackers, failing to provide users with physically perceptible privacy protection. Analysis of existing technical literature: Chinese patent application CN107483439A discloses a robot sharing method, system, and robot, supporting hierarchical permissions for owners / tenants, and storing the user database on a cloud server. However, this solution does not address TEE hardware isolation, does not implement underlying secure erasure, and ownership switching relies on application-layer logic. Chinese patent application CN107330324A discloses a data redirection and erasure method within a secure sandbox, applied to general-purpose computing devices. However, it does not consider the ownership switching process in robot leasing scenarios, nor does it address data isolation issues when multiple users take turns using the same physical device. International patent application WO2018223638A1 relates to a service robot task scheduling method, matching robots based on size, battery level, and location, and planning avoidance strategies. However, it does not address data privacy protection, secure erasure, or blockchain evidence storage. Chinese patent application CN109189056A discloses an IDC data center operation and maintenance robot management system, including robots and backend management. However, it does not address shared leasing models, TEE isolation, or erasure proof. Korean patent application KR20110024086A discloses a method for transferring operational rights in a multi-operator, multi-robot environment. However, it does not cover encrypted sandbox isolation, secure erasure, or blockchain evidence storage. In summary, there is currently no technical solution that organically combines "TEE encrypted sandbox isolation + multiple overwrite secure erasure + blockchain immutable evidence storage + physical privacy switch" for application in the rental and return scenario of data center robots. This invention addresses the aforementioned technological gap. Summary of the Invention

[0003] Purpose of the invention The purpose of this invention is to overcome the shortcomings of the prior art and provide a trusted execution environment cleanup method and system for returning leased data center robots, achieving the following technical objectives: (1) Hardware-level data isolation: An encrypted sandbox is dynamically created within the robot's TEE to strictly isolate tenant data within the sandbox. The system area and the owner's private area are read-only locked throughout the process, preventing data from crossing boundaries at the hardware level. Even if the Rich OS is compromised, the sandbox data cannot be accessed. (2) Unrecoverable secure erase: When the lease is returned, the TEE performs multiple overwrite secure erases and calls the storage controller secure erase command to clear the FTL mapping layer residue. Even if the storage chip is physically disassembled, the data cannot be recovered. (3) Cryptographically auditable: The TEE uses a non-derivative private key to generate an erasure certificate with a digital signature and writes it into the consortium blockchain for storage, providing an unalterable audit basis and resolving the burden of proof issue in post-event disputes. (4) Hardware privacy protection: Provides a mechanical physical privacy switch to cut off the power supply to the camera and microphone from an electrical level, providing users with perceptible physical privacy protection.

[0004] The core technical solutions include: A. A trusted execution environment cleanup method for returning a leased data center robot, comprising seven steps from S1 to S7 (see claim 1 for details). B. A trusted execution environment cleanup system for the return of a data center robot rental, comprising three subsystems: a robot terminal, a cloud operation platform, and a mobile app (see claim 8 for details). Attached Figure Description

[0005] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Figure 1 This is a schematic diagram of the overall system architecture of the present invention (also serving as an abstract drawing). Figure 2 This is a time-series interaction diagram of the lease establishment phase in the method of the present invention; Figure 3 This is a time-series interaction diagram of the cleansing and return phase in the method of the present invention; Figure 4 This is a schematic diagram of the internal module structure and data flow of the TEE of the present invention; Figure 5 This is a file system hierarchy diagram of the encrypted sandbox of this invention; Figure 6 This is a schematic diagram of the blockchain evidence storage structure for the erasure proof of the present invention; Figure 7 This is an operation flowchart of a specific application scenario of the present invention; Figure 8 This is a schematic diagram of the mechanical structure of the physical privacy switch of the present invention; Figure 9 This is a detailed flowchart of the lease establishment phase in an embodiment of the present invention; Figure 10 This is a detailed flowchart of the cleansing and return stage in an embodiment of the present invention. The reference numerals in the attached figures are explained as follows: 100 - Mobile App; 110 - Rental Interaction Module; 120 - Secure Storage Module; 130 - Encrypted Communication Module; 200-Cloud Operation Platform; 210-Ownership Management Module; 220-Credit Verification Module; 230-Key Distribution Module; 240-Cleanup Scheduling Module; 250-Blockchain Interface Module; 260-Pricing Engine; 400 - Robot Terminal; 410 - TEE Chip; 411 - Secure Boot Module; 412 - Sandbox Management Module; 413 - Key Management Module; 414 - Secure Erasure Module; 415 - Proof Generation Module; 420 - Physical Privacy Switch; 430 - Status Indicator; 440 - UWB / Bluetooth Beacon; 450 - Sensor Array; 460 - Actuator; 470 - Secure Memory Block (RPMB); Detailed Implementation

[0006] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the following embodiments are only for explaining the present invention and are not intended to limit the scope of protection of the present invention. All equivalent modifications and substitutions based on the technical solutions of the present invention and without departing from the spirit of the present invention are within the scope of protection of the present invention.

[0007] I. System Overall Architecture (corresponding to) Figure 1 ) like Figure 1 As shown, the system of the present invention includes a three-layer architecture: First layer: Mobile Apps (100) Running on the renter's smartphone (iOS or Android operating system), it communicates with the cloud operation platform via HTTPS protocol and pairs with the robot terminal via Bluetooth LE or Wi-Fi. The core components include a rental interaction module (110), a secure storage module (120), and an encrypted communication module (130). The rental interaction module (110) provides a graphical user interface for renters to browse a list of available robots (including location, battery level, model, and unit price), initiate rental requests, view rental time and fees, and send return instructions. The secure storage module (120) uses secure hardware provided by the mobile platform (iOS's Secure Enclave or Android's StrongBox Keymaster) to store temporary private keys, preventing the operating system layer or malicious apps from extracting the keys. The encrypted communication module (130) implements the ECDH key negotiation protocol and AES-256-GCM symmetric encryption, establishing an end-to-end encrypted channel with the robot terminal. Second layer: Cloud operation platform (200) Deployed on public or private cloud infrastructure, it adopts a microservice architecture, with each module deployed and scaled independently. Core components include an ownership management module (210), a credit verification module (220), a key distribution module (230), a cleanup scheduling module (240), a blockchain interface module (250), and a pricing engine (260). The ownership management module (210) maintains a robot asset registration table, with each record containing: a unique robot serial number, owner identity, current ownership status (Private / Platform / Rented), available time period, and historical rental records. Three ownership modes are supported: 1. Private: Permanently bound to a single owner, and does not support leasing. 2. Platform: The platform's own assets, which are leased out. 3. Rented: Temporarily bound to the tenant with limited permissions. The credit verification module (220) connects to the enterprise credit system (such as Tianyancha API) and third-party credit scoring (such as Sesame Credit API) to verify the tenant's creditworthiness. Users with a credit score ≥650 enjoy deposit-free rental; users with a score below the threshold need to pre-authorize a deposit. The key distribution module (230) generates a temporary key pair (K_pub / K_priv) when the rental is established, distributes K_pub to the robot TEE via the MQTT protocol, and pushes K_priv to the secure storage module of the tenant's App via an HTTPS encrypted channel. The cleanup scheduling module (240) constructs a cleanup trigger signal at the end of the rental. The signal contains a cloud ECDSA signature and the current Unix timestamp (to prevent replay attacks), and is sent to the robot TEE via the MQTT protocol. The blockchain interface module (250) encapsulates the Hyperledger Fabric SDK and provides two interfaces: SubmitProof (submit erase proof to the chain) and QueryProof (query the on-chain status). The pricing engine (260) dynamically adjusts rental prices based on real-time supply and demand, using the following formula: Price(t) = BasePrice × DemandFactor(t) × UrgencyFactor Where BasePrice is the base unit price (e.g., 5 yuan / minute), DemandFactor(t) is the time-period demand factor calculated based on historical data and real-time demand forecast (0.5~2.0), and UrgencyFactor is the task urgency coefficient (1.0~3.0). Third layer: Robot terminal (400) The core is a TEE chip (410) on which a trusted operating system (such as OP-TEE, Qualcomm QSEE, or Huawei iTrustee) runs. The non-secure world (Rich OS, such as Linux or Android) runs regular robot control logic (navigation, obstacle avoidance, sensor acquisition) and communicates with the TEE secure world through the TEE Client API. The robot terminal also includes a physical privacy switch (420), status indicator lights (430), a UWB / Bluetooth beacon (440), a sensor array (450), actuators (460), and secure storage (470, i.e., RPMB partition).

[0008] II. Detailed Design of TEE Internal Modules (Corresponding) Figure 4 ) 2.1 After the secure boot module (411) is powered on, the Boot ROM reads the first-level bootloader (BL1) and verifies its digital signature (RSA-2048 or ECDSA-P256). If the verification is successful, BL1 is loaded. BL1 verifies the BL2 signature, BL2 verifies the TEE operating system kernel signature, and the verification is chained step by step until the Trust Application is loaded. If any level of signature verification fails, the system enters a locked state, refuses to boot, and records the failure metric. The metric (the concatenation of hash values ​​at each stage) is written to the TEE's Attestation Report for remote authentication. The remote authentication process is as follows: the cloud sends a random challenge value (Nonce), the TEE returns an authenticable report containing the metric, Nonce, and signature, and the cloud verifies whether the signature chain and metric are in the whitelist. 2.2 The sandbox management module (412) implements lightweight containerized isolation within the TEE: It uses LXC (LinuxContainers) to create independent file system namespaces (MountNamespace), process namespaces (PID Namespace), and network namespaces on the TEE's secure filesystem. The sandbox lifecycle is strictly bound to the lease period: it is created at the start of the lease and destroyed at the end. There are no sandboxes with "cross-lease persistence". The sandbox capacity is configurable (default 16GB). If the limit is exceeded, the TEE refuses to write and returns an error code to the Rich OS, which then notifies the cloud that the sandbox is full. The sandbox filesystem uses dm-crypt (LUKS2 format) encryption, with the encryption key provided by the key management module. 2.3 Key Management Module (413) Device Master Key (DMK): Generated by a True Random Number Generator (TRNG) during chip manufacturing or initial configuration, and burned into the secure storage area (RPMB partition) of the TEE. It cannot be exported or read in plaintext. The Sandbox Key (SK) is generated from the DMK and the tenant's unique identifier (such as the first 16 bytes of a phone number's SHA-256 hash) using the HKDF (RFC 5869) key derivation function. Different tenants derive different SKs, achieving key isolation. Session Key: Generated through ECDH (Curve25519 or P-256) negotiation for each rental session, used to encrypt communication between the App and the robot. The key material is cleared from memory after the session ends. Attestation Key: A non-exportable ECDSA or SM2 key pair generated within the TEE, used to sign the erasure certificate. The public key is uploaded to the cloud during device registration, and the signature can be verified on the cloud. All key operations are completed within the TEE. Rich OS can only initiate key operation requests through the TEE Client API and cannot directly read the plaintext of the key. 2.4 Secure Erasure Module (414) The cryptographically verified multiple overwrite algorithm is implemented as follows: Step 1: Freeze sandbox I / O. Reject all new data write requests and wait for ongoing I / O operations to complete (timeout threshold 30 seconds). Step 2: Overwrite Pass 1. Write all 0x00 bytes to all physical storage blocks occupied by the sandbox, call fsync() to force a flush to disk, and read back to verify that the write was successful. Step 3: Pass 2 Overwrite. Write all 0xFF bytes to the same storage block, call fsync() to force a flush to disk, and read back the verification code to confirm successful write. Step 4: Pass 3 Overwrite. Use the TEE's TRNG to generate cryptographically secure pseudo-random numbers (entropy ≥ 7.9 bits per byte), fill all storage blocks, call fsync() to force a disk flush, and read back the verification. Step 5: Storage controller erase. Invoke the underlying storage controller's secure erase command: a) eMMC device: Sends the BKOPS_START enhanced background operation command to trigger garbage collection and block erasure within the controller. b) UFS device: Sends a Purge command to forcibly remove unmapped storage blocks. c) SATA SSD: Sends an ATA Secure Erase command to trigger the destruction of the full disk encryption key (if SED is enabled). Waits for the controller to return an erase complete status. Step 6: Release resources. Unmap dm-crypt, shut down the LUKS container, and release all memory pages and storage blocks occupied by the sandbox. Step 7: Zero the keys. The sandbox encryption key SK and the temporary public key K_pub are zeroed out of the TEE memory and RPMB, and cannot be recovered. 2.5 The proof generation module (415) collects the following fields: * robot_id: The robot's unique serial number (e.g., SN-2024-001234) * tee_measurement: Complete metric (hash chain) for secure TEE startup * sandbox_hash_before: Merkle root hash of the sandbox root directory before erasure. * erase_timestamp: Unix timestamp indicating the erasure was complete. * erase_method: "3-pass-overwrite+BKOPS" * nonce: A random challenge value carried in the cleansing trigger signal from the cloud. Use a non-exportable signing private key from the TEE to perform an ECDSA (or SM2) digital signature on the above fields. Assemble it into JSONWeb Signature (JWS) format: { "header": {"alg": "ES256", "typ": "JWS", "kid": "key-001"}, "payload": "eyJyb2JvdF9pZCI6IlNOLTIwMjQtMDAxMjM0...", "signature": "MEUCIQDf3...8B" } JWS is passed to Rich OS via the TEE Client API, and Rich OS sends it to the cloud blockchain interface module via MQTT / HTTPS.

[0009] III. Detailed Process of Lease Establishment Phase (Corresponding) Figure 2 and Figure 9 ) T0: The owner (buyer) completes the initial robot configuration. They enter their personal biometric template (voiceprint + facial recognition) into the TEE, initialize the system area and the owner's private area, and set the robot's ownership status to "idle and available for rent." The DMK has been burned into the TEE, and the signature key pair has been generated. T1: The tenant opens the mobile app, which retrieves a list of nearby available robots (including location, battery level, model, unit price, and available time slots) from the cloud via HTTPS. T2: The renter selects the target robot (e.g., R-07), clicks "Rent Now", enters the rental duration or usage mode (instant rental / reservation rental), and the App sends the rental request to the cloud (including renter ID, credit token, target robot ID, and rental duration). T3: The cloud-based credit verification module checks the tenant's credit score. If it is ≥650, the deposit waiver is approved, and the user proceeds to T4. If it is <650, a "deposit required" response is returned, the app pops up a deposit payment interface, and the user completes pre-authorization before proceeding to T4. T4: The cloud-based key distribution module generates a temporary key pair (K_pub / K_priv): K_pub is sent to the key management module of the robot TEE via the MQTT protocol and stored in the RPMB temporary area. K_priv is pushed to the secure storage module of the tenant app via an HTTPS encrypted channel and stored in iOS Secure Enclave or Android StrongBox. T5: TEE's sandbox management module dynamically creates encrypted sandboxes. a) The key management module derives the sandbox encryption key SK = HKDF(DMK, Hash(tenant ID)). b) Create a LUKS2 encryption container on the secure filesystem, using SK as the encryption key. c) Create an ext4 file system inside the container. d) Use LXC to create an isolated Mount Namespace and mount the encrypted container as the sandbox root directory. e) Set the sandbox capacity quota (default 16GB). f) Set the inode permissions of the system area and the owner's private area to read-only and lock them. T6: The tenant app uses K_priv to perform ECDH key negotiation with the bot: a) The App generates a temporary public key Q_app and sends it to the robot. b) The robot TEE generates a temporary public key Q_tee and sends it to the App. c) Both parties calculate the shared secret: S = Q_app × K_tee = Q_tee × K_app d) Derive the session key from S: SK_session = HKDF(S, "session-key") e) All subsequent communications will be encrypted using SK_session + AES-256-GCM. T7: Rental start time begins. The tenant issues task instructions via the App, and all data (voice recordings, photos taken, environmental sensor logs, map cache, AI inference results) is written to the TEE sandbox file system via Rich OS. Rich OS cannot directly read the sandbox content (dm-crypt encryption + namespace isolation).

[0010] IV. Detailed Procedures for the Stage of Returning to Normal (Corresponding) Figure 3 and Figure 10 ) T8: Trigger condition met. The trigger condition is one of the following: a) Lease expiration: The cloud timer expires and triggers automatically. b) Renter returns the car voluntarily: The renter clicks the "Return Car" button in the App. c) Emergency Recall: The owner remotely triggers the "recall" command via the App. T9: The renter's app sends a car return instruction to the cloud. The cloud-based vehicle clearance scheduling module constructs a clearance trigger signal: { "robot_id": "SN-2024-001234", "timestamp": 1721040725, "nonce": "a8f3...e2", "reason": "lease_expired", "cloud_signature": "MEYCIQ...Dw==" } The signal is signed with a private key in the cloud (to prevent forgery) and sent to the robot TEE via MQTT QoS=2 (exactly once). T10: TEE verification cleansing trigger signal: a) Verify the cloud signature (using a pre-built cloud public key certificate chain) b) Verify timestamp deviation ≤ ±30 seconds (to prevent replay) c) Verify that the nonce has not been reused (maintain a set of used nonces). d) Verify that the robot_id matches the local serial number. Once all verifications pass, the erasure process begins; if any verification fails, the TEE ignores the signal and returns an error code to the cloud. T11: Perform a secure erase (see Section 2.4 for the seven-step process): a) Freeze sandbox I / O b) Pass 1: Write all 0x00 + fsync + verification c) Pass 2: Write all 0xFF + fsync + checksum d) Pass 3: TRNG random number filling + fsync + validation e) Invoke the storage controller's secure erase command (BKOPS / Purge / Secure Erase). f) Release sandbox resources g) Clear SK and K_pub T12: The proof generation module generates the erasure proof JWS (see Section 2.5), which includes robot_id, tee_measurement, sandbox_hash_before, erase_timestamp, erase_method, nonce, and a cloud-signed copy. T13: The erase proof is written to the consortium blockchain via the cloud blockchain interface module: a) Cloud-based call to the Fabric SDK's SubmitProof chaincode interface b) Transactions are sent to the Orderer node for sorting. c) Each of the three peer nodes (cloud, owner, and auditor) executes chaincode verification of the signature and hash and writes it to its own ledger copy. d) Once consensus is reached, the block is uploaded to the blockchain, and the transaction ID and block height are returned. e) The cloud will send the transaction ID back to the robot's TEE storage for later retrieval. T14: TEE releases the read-only lock on the system area and the owner's private area: a) Restore the robot's pre-configured behavior parameters (movement speed, volume, language preference, etc.) to the owner. b) Reload the owner's biometric template (voiceprint model, facial feature vector) for subsequent voiceprint and face recognition. c) Reset network identifier: The Wi-Fi MAC address is restored to the homeowner's set value (or re-randomized), and the Bluetooth device name is restored to the homeowner's set value. d) Set the robot's ownership status to "Idle and Available for Rent" or "Owner's Exclusive". T15: The TEE sends a "return" command to the Rich OS, which then drives the robot to automatically navigate to the charging station or the owner's preset location. The status indicator light returns to the owner's preferred color. T16: Settle rental fees via cloud platform: a) Calculate the cost = Unit price × Actual usage time (rounded to the nearest minute) b) Deduct from the tenant's pre-authorization (or deduct directly from the account balance) c) In the case of subletting, the payments shall be transferred according to the revenue sharing rules (e.g., 20% to the platform and 80% to the owner). d) Send bills and confirmation notices (including a link to erase the transaction ID) to both the tenant and the homeowner.

Claims

1. Claim 1 (Independent Claim – Method): A method for cleaning up a trusted execution environment upon returning a leased data center robot, characterized in that, Includes the following steps: Step S1: After the robot terminal is powered on, its Trusted Execution Environment (TEE) chip completes the secure startup verification. An encrypted sandbox is dynamically created in the TEE as a temporary data area for the tenant. At the same time, the system area and the owner's private area are set to read-only locked state, prohibiting any process from performing write operations on the system area and the owner's private area. Step S2: The cloud operation platform receives a rental request sent by the tenant's mobile app. The rental request includes the tenant's identity identifier and credit token. After verifying the credit token, the cloud operation platform generates a pair of temporary keys. The temporary public key is sent to the TEE security chip of the robot terminal, and the temporary private key is encrypted and pushed to the secure area of ​​the tenant's mobile app. Step S3: The tenant establishes an end-to-end encrypted channel with the robot terminal based on the temporary key through the mobile app. The rental time starts, and all multimodal data during the rental period is only written to the encrypted sandbox and not to the system area or the owner's private area. Step S4: When the rental period expires or the renter sends a return instruction via the mobile app, the cloud operation platform sends a cleanup trigger signal to the robot terminal. The cleanup trigger signal includes a cloud digital signature and a current timestamp. Step S5: After the TEE of the robot terminal verifies the signature and timestamp of the cleanup trigger signal, it performs a one-time secure erase on the encrypted sandbox, including: performing at least three overwrites on the physical storage block occupied by the sandbox, writing all 0x00s the first time, all 0xFFs the second time, and cryptographically secure pseudo-random numbers the third time, and performing a forced disk flush operation after each overwrite; then destroying the temporary public key and the sandbox encryption key, and closing and destroying the encrypted sandbox; Step S6: The TEE collects the robot's unique serial number, secure startup metric, erasure completion timestamp, and sandbox final state hash value. It uses the TEE's internal, non-exportable signing private key to digitally sign the above information, generate an erasure certificate, and upload the erasure certificate to the consortium blockchain network for storage. The consortium blockchain includes at least a cloud operation platform node, a home master verification node, and a third-party audit node. Step S7: The TEE releases the read-only lock between the system area and the owner's private area, loads the owner's personalized configuration parameters and biometric template, resets the robot's network identifier, and rolls the robot back to its owner state; the cloud operation platform updates the robot's ownership status to available and settles the rental fee.

2. Claim 2 (dependent claim): The method according to claim 1, characterized in that, In step S1, the encrypted sandbox is implemented using Linux container (LXC) or micro-virtual machine (Micro-VM) technology. The file system in the sandbox is encrypted using the AES-256 algorithm. The encryption key is generated by the device master key (DMK) in the TEE chip and the tenant's unique identifier through the HKDF key derivation function. The device master key is burned into the secure storage area (RPMB) of the TEE and cannot be exported.

3. Claim 3 (dependent claim): The method according to claim 1, characterized in that, In step S5, after the three overwrites are completed, the storage controller's secure erase command is further invoked to clear the residual data items in the flash translation layer (FTL) mapping table; the storage controller is an eMMC, UFS, or SATA SSD controller, and the secure erase command is an eMMC BKOPS command, a UFSPurge command, or an ATA Secure Erase command.

4. Claim 4 (dependent claim): The method according to claim 1, characterized in that, In step S6, the digital signature of the erasure proof adopts ECDSA or the national cryptographic SM2 algorithm, and the output format is JSON WebSignature (JWS) structure; the consortium chain is a permissioned chain built with the Hyperledger Fabric framework, and the consensus mechanism is Raft or Kafka; the owner can perform Merkle Proof verification through the light node client to confirm that the erasure proof has been uploaded to the chain and has not been tampered with.

5. Claim 5 (dependent claim): The method according to claim 1, characterized in that, In step S7, the rollback to the home state further includes: restoring the robot behavior parameters pre-configured by the home owner, reloading the home owner's biometric template for subsequent voiceprint recognition and face recognition, and restoring the Wi-Fi, MAC address, and Bluetooth device name to the home owner's set values.

6. Claim 6 (dependent claim): The method according to claim 1, characterized in that, It also includes the step of incorporating the physical privacy switch status into remote authentication: the robot terminal is equipped with a mechanical physical privacy switch. When the switch is turned to the privacy position, the power supply circuits for the camera, microphone, and wireless communication module are physically cut off. The status signal of the physical privacy switch is connected to the TEE chip, and the TEE includes the status in the remote authentication report for the cloud operation platform to verify the privacy status of the robot hardware.

7. Claim 7 (dependent claim): The method according to claim 1, characterized in that, In step S3, the end-to-end encrypted channel is established using the ECDH key negotiation protocol. Each lease session uses a brand new temporary key pair, and the session key is automatically destroyed after the session ends, thus achieving forward confidentiality. The symmetric encryption algorithm for the encrypted communication is AES-256-GCM or the national standard SM4-GCM.

8. Claim 8 (Independent Claim – System): A trusted execution environment cleanup system for the return of a leased data center robot, used to implement the method of any one of claims 1 to 7, characterized in that, include: The robot terminal (400) has a built-in Trusted Execution Environment (TEE) chip (441), which conforms to the GlobalPlatform TEE specification or the national cryptographic standard GM / T. The 0028 standard, with a security level of EAL4+ or higher, includes the following TEE chip: a secure boot module (411) for verifying firmware signatures and measuring runtime integrity at each level, with the system locked if any level of verification fails; a sandbox management module (412) for dynamically creating and destroying encrypted sandboxes within the TEE, with the sandbox lifecycle strictly bound to the rental period; a key management module (413) for storing the device master key, derived sandbox encryption keys, and performing encryption and decryption operations, with all key operations completed within the TEE; a secure erasure module (414) for executing a multiple overwrite algorithm with at least three overwrites to clear the specified storage area and calling the storage controller's secure erasure command; a proof generation module (415) for collecting measurement values ​​and hash values, and generating a digitally signed erasure proof using a non-derivative private key; and a cloud operation platform (200) for communicating with several robot terminals and several mobile apps, including: an ownership management module (231) for registering the robot's owner information, rental status, and available time periods, supporting buyout and leasing. The system includes three ownership modes: rental, subletting, and transfer; a credit verification module (241) for verifying the tenant's creditworthiness and deciding whether to release the vehicle without a deposit, and connecting to the enterprise credit system or third-party credit scoring interface; a key distribution module (232) for generating temporary key pairs and distributing them to the robot terminal and the tenant's mobile terminal respectively; a cleanup scheduling module (233) for sending a cleanup trigger signal containing a signature and timestamp to the robot at the end of the rental period; a blockchain interface module (251) for writing the erase proof into the consortium blockchain for storage and providing a query interface for the owner and auditor to verify; and a mobile app (100) running on the tenant's smartphone, including: a rental interaction module (151) for browsing available robots, initiating rental requests, sending return instructions, and displaying rental time and fees; a secure storage module (131) for storing the temporary private key in the phone's secure element (SE) or trusted execution environment to prevent extraction at the operating system layer; and an encrypted communication module (132) for establishing an end-to-end encrypted channel for ECDH key negotiation with the robot terminal using the temporary private key.

9. Claim 9 (dependent claim): The system according to claim 8, characterized in that, The robot terminal (400) also includes: a physical privacy switch (450), which is a mechanical sliding structure that is linked with a micro-motion sensor. When switched to the privacy position, it physically cuts off the power supply circuits for the camera, microphone, and wireless communication module, retaining only the infrared obstacle avoidance function; a status indicator light (460), which uses RGB LED strips to encode the robot's working status through different colors: blue indicates normal operation, green indicates charging, yellow indicates low battery, red indicates malfunction, and off indicates stealth mode; and a UWB / Bluetooth beacon (470), which is used for short-range high-precision positioning with the mobile app and supports following and indoor navigation.

10. Claim 10 (dependent claim): The system according to claim 8, characterized in that, The cloud-based operation platform (200) also includes a pricing engine (221) for dynamically adjusting rental prices based on time period, regional demand, and robot type, using the following formula: Price(t) = BasePrice × DemandFactor(t) × UrgencyFactor; BasePrice is the base unit price, DemandFactor(t) is the time-period demand factor calculated based on historical data and real-time demand forecasts, and UrgencyFactor is the task urgency coefficient; discounts are applied automatically during off-peak hours, and premiums are applied automatically during peak hours.

Images