A biometric security storage method, system, robot and medium

Abstract

The application relates to the field of embodied intelligence, and particularly discloses a biological feature security storage method and system, a robot and a medium, wherein the method is executed on an embodied intelligent robot computing platform carrying a TrustZone hardware security extension; after receiving a biological feature embedding vector and user identification information, a rich execution environment side packs the biological feature embedding vector and the user identification information into a continuous memory block, and transmits the continuous memory block to a trusted execution environment security world through shared memory; after performing multi-layer parameter verification, a trusted application in the security world constructs a persistent object identifier in a triple format; before creating a new persistent object, an old object with the same name is opened and deleted, and then a new object is created and encrypted feature data is written into the new object. Compared with the prior art, the application realizes hardware-level security isolation, template-level anti-rollback protection, unified management of multiple users and multiple templates, and linkage life cycle management of configuration and trusted storage.

Description

Technical Field

[0001] This invention relates to the field of embodied intelligence, and in particular to a method, system, robot, and medium for secure storage of biometric data. Background Technology

[0002] With the rapid industrialization of embodied intelligence technology, intelligent devices such as quadruped robots and humanoid robots have been widely applied in diverse scenarios including home services, business interactions, and industrial operations and maintenance. Biometric recognition technology, as a core means of natural human-computer interaction and user identity and access control, has become a key support for personalized services, identity authentication, and data access control on robot-side devices. Biometric templates (such as biometric embedding vectors extracted by algorithms) are highly sensitive personal information. Robot platforms generally utilize short-range wireless communication links and open-source computing frameworks. If the main operating system is compromised, sensitive data is at risk of leakage, tampering, and unauthorized access, directly leading to security issues such as identity theft and privacy breaches. Public security research indicates that regardless of how the link layer is patched, elevating the storage and comparison boundaries of biometric templates to a trusted execution environment isolated by processor hardware security extensions (TrustZone) can fundamentally reduce the risk of plaintext template exposure to the ordinary execution environment. This has become the core technological development direction for secure storage of robot biometrics.

[0003] ARM TrustZone is a hardware security extension technology for embedded computing platforms. It uses hardware isolation mechanisms to divide the chip into mutually isolated Rich Execution Environments (REEs) and Trusted Execution Environments (TEEs), combined with RPMB (Replay Protected Execution Module). MemoryBlock (Replay Protected Memory Block) hardware partitions provide anti-rollback capabilities, and this architecture has become a mature biometric storage solution in the smartphone field. Currently, mobile terminals from manufacturers such as Huawei and Honor implement secure storage of biometric templates based on RPMB in a Trusted Execution Environment (TEE). Qualcomm's official secure file system also stores keys and biometric data in an RPMB partition accessible only to the TEE and authenticated by HMAC on each access. The OP-TEE open-source implementation also provides backend support for RPMB persistent objects. Simultaneously, general-purpose TEE persistent storage technology has also developed. For example, Chinese invention patent application CN122020740A discloses a data persistent storage system composed of a secure virtual block device, an IDE integrity data encryption module, and a secure storage operation module. This system can simultaneously ensure the confidentiality, integrity, crash consistency, and freshness of TEE persistent data, providing underlying block-level secure storage capabilities for general sensitive data.

[0004] Although existing technologies have formed mature solutions for mobile terminals and general storage scenarios, there are still multi-dimensional adaptation defects and capability shortcomings for robot platforms with limited computing power and power consumption budgets: First, the general-purpose TEE persistent storage solution lacks adaptability to various scenarios and is not specifically optimized for biometric storage. Existing general-purpose block-level storage solutions only provide persistent read and write capabilities for general data, without designing a dedicated management mechanism based on the structured characteristics of biometric data. This makes it impossible to support fine-grained storage management of biometric templates under multi-user and multi-biological modalities. Furthermore, its storage entry point lacks multi-layered pre-checks for biometric data, failing to intercept illegal data before writing, which can easily lead to abnormal format data being written to the persistent area and causing storage anomalies. At the same time, existing solutions use general read and write logic and do not design atomic overwrite write processes for biometric template update scenarios, which can easily lead to problems such as old template residues and version conflicts, making it difficult to ensure the consistency of template updates.

[0005] Second, mature biometric storage solutions on smartphones cannot be directly ported to robot computing platforms. Smartphones are personal devices, and their TEE secure storage is designed for single-user exclusivity, lacking support for multi-user namespaces and multi-biometric permission isolation. This makes them unsuitable for home-based, multi-user robot application scenarios. Furthermore, robot-side embedded storage capacity is generally limited, requiring sharing storage space with the operating system, algorithm models, SLAM maps, and operation logs. Existing smartphone solutions lack refined template management design for scenarios with limited storage resources, making them unsuitable for robot hardware resource conditions.

[0006] In summary, there is an urgent need for a secure storage method that is compatible with embodied intelligent robot computing platforms and designed for multi-user, multi-modal biometric management. Based on the TrustZone hardware security architecture, this method should balance security, scenario adaptability, and compliance to meet the secure storage needs of biometrics in robot scenarios. Summary of the Invention

[0007] The purpose of this invention is to provide a secure biometric storage method, system, robot, and medium to achieve hardware-level secure persistent storage of multi-user, multi-modal biometric templates, thereby improving the security and scenario adaptability of biometric data on robot platforms.

[0008] The objective of this invention can be achieved through the following technical solutions: A method for securely storing biometric data is executed on a computing platform of an embodied intelligent robot equipped with TrustZone hardware security extensions. The computing platform includes an enriched execution environment and a trusted execution environment. The method includes the following steps: Step S1: Receive a storage request in an enriched execution environment. The storage request carries a user identifier, a biometric type identifier, a template number, and a biometric feature embedding vector extracted from the original biological data by a biometric feature extraction algorithm. Step S2: Pack the user identifier, biometric type identifier, template number and biometric feature embedding vector into a contiguous memory block, cross the TrustZone hardware boundary through shared memory, and send a storage command to the trusted application running in the secure world of the Trusted Execution Environment; Step S3: In response to the storage command, the trusted application performs multi-level parameter verification on the received data within the secure world of the trusted execution environment, including parameter type pattern matching verification, buffer size verification, data header magic number verification, and embedded vector dimension range verification. Step S4: After the parameter verification is passed, the trusted application constructs an object identifier in triplet format using the user identifier, biometric type identifier, and template sequence number; Step S5: Before creating a new persistent object, the trusted application first calls the persistent object opening interface and attempts to open an existing persistent object with the same name as the object identifier with write metadata permissions. If the existing persistent object exists, the application calls the persistent object deletion interface to permanently delete the existing persistent object; then it calls the persistent object creation interface to create a new persistent object. Step S6: The trusted application writes the packaged contiguous memory blocks into the new persistent object, completing the secure storage of the biometric template.

[0009] In step S5, the input parameters of the persistent object creation interface include storage type, access flag, and initial data. The storage type includes private persistent storage type, and the access flag represents permissions including read permission, write permission, metadata operation permission, and overwrite permission. The initial data is the contiguous memory block packaged in step S2. The persistent object creation interface creates a new persistent object with private persistent storage type and overwrite permission.

[0010] In step S5, the secure operating system of the trusted execution environment writes the created persistent object into the RPMB security partition of the eMMC memory in encrypted form. The RPMB security partition is equipped with a counter. When the trusted application calls the persistent object deletion interface to permanently delete an existing persistent object, the corresponding counter is incremented by 1. The new counter value is used as the internal version number of the persistent object to be created to create the persistent object, thereby realizing the rollback protection of the persistent object.

[0011] The multi-layer parameter verification in step S3 is performed in the following progressive order: The first layer is parameter type pattern matching verification, which verifies whether the command parameter type pattern matches the preset pattern of the storage command. If they do not match, a parameter type error is returned and the processing is terminated. The second layer is buffer size verification, which verifies whether the actual size of the shared memory buffer can at least accommodate the length of the data header structure plus the total data length of the biometric embedding vector. If it does not meet the requirement, a buffer too small error is returned. The third layer is data header magic number verification, which parses the magic number field from the data header structure and compares it with the preset magic number constant. If they do not match, a parameter error is returned. The fourth layer is embedding vector dimension range verification, which verifies whether the dimension of the biometric embedding vector is within the preset valid range. If it is not within the range, a parameter error is returned.

[0012] The trusted application also supports the following operation commands: Existence query command: After receiving an existence query request, the trusted application attempts to open the persistent object corresponding to the specified object identifier with read-only permissions. If the opening is successful, it returns an existence flag of true and closes the object. If it returns an error that the object does not exist, it returns an existence flag of false. Delete command: After receiving a delete request, the trusted application opens the persistent object corresponding to the specified object identifier with write metadata permissions and deletes it permanently. If the object does not exist, the deletion is considered successful to achieve idempotency of the operation.

[0013] The biometric identifier includes a face template identifier, an application-side synchronous voiceprint template identifier, and a terminal-side enhanced voiceprint template identifier; each user has a maximum of three template slots, which store the face template, the application-side synchronous voiceprint template, and the terminal-side enhanced voiceprint template, respectively; the terminal-side enhanced voiceprint template is written after the candidate voiceprint features pass the assisted judgment by face matching and lip movement detection, and is isolated from the application-side synchronous voiceprint template; when the application-side synchronous voiceprint template is deleted, the terminal-side enhanced voiceprint template is also deleted.

[0014] The method further includes a biometric template comparison step: receiving an identification request carrying a query embedding vector, and passing the query embedding vector to the trusted application through shared memory; the trusted application opens a persistent object corresponding to the object identifier in the secure world of the trusted execution environment, calculates the similarity between the biometric embedding vector and the query embedding vector without the template plaintext leaving the secure world, and determines that the match is successful when the similarity exceeds a preset threshold, otherwise the match fails, and only returns the matching result to the rich execution environment, or only returns the matching result and the user identifier.

[0015] A biometric secure storage system is applied to a computing platform for an embodied intelligent robot equipped with TrustZone hardware security extensions. The computing platform includes a rich execution environment and a trusted execution environment, comprising: The client program in the rich execution environment is used to receive storage requests and package them into contiguous memory blocks. The storage command is sent to the secure world of the TrustZone hardware boundary through shared memory. The storage request carries a user identifier, a biometric identifier, a template number, and a biometric feature embedding vector extracted from the original biological data by a biometric feature extraction algorithm. Trusted applications in a secure world of trusted execution environments are used to perform multi-layer parameter verification, construct object identifiers in triplet format consisting of the user identifier, biometric identifier, and template sequence number, execute anti-rollback storage strategies, and complete encrypted storage. The multi-layer parameter verification includes parameter type pattern matching verification, buffer size verification, data header magic number verification, and embedded vector dimension range verification. The execution of anti-rollback storage strategies and completion of encrypted storage specifically involves: before creating a new persistent object, calling the persistent object opening interface and attempting to open an existing persistent object with the same name as the object identifier with write metadata permissions; if the existing persistent object exists, calling the persistent object deletion interface to permanently delete the existing persistent object; then calling the persistent object creation interface to create a new persistent object. A secure operating system storage subsystem in a trusted execution environment is used to write persistent objects created by the trusted application into the RPMB secure partition of the eMMC memory in encrypted form.

[0016] A robot includes a memory and a processor, wherein the memory stores executable code, and the processor supports TrustZone hardware security extensions and, when executing the executable code, implements the biometric secure storage method.

[0017] A computer-readable storage medium having a program stored thereon that, when executed by a processor supporting TrustZone hardware security extensions, implements the biometric secure storage method.

[0018] Compared with the prior art, the present invention has the following beneficial effects: (1) The present invention adopts an atomic template overwrite writing strategy of “open verification - delete old object - create new object”, and performs the creation operation by combining the interface parameter configuration of private persistent storage type and overwrite permission. This overcomes the defects of the existing general storage scheme template update mechanism being imperfect, prone to old template residue and version conflict, and realizes data consistency in the biometric template update process, ensuring the accuracy and uniformity of template versions.

[0019] (2) The present invention adopts a hardware and software collaborative anti-rollback mechanism that combines RPMB security partitioning with counter incrementing. When an existing persistent object is deleted, the corresponding counter increments, and the new counter value is used as the internal version number of the new object. Relying on the hardware characteristics of RPMB partitioning that can only be accessed by TEE and requires HMAC authentication, it overcomes the shortcomings of pure logical isolation TEE schemes in terms of insufficient anti-rollback capability and susceptibility to historical version rollback attacks, realizes the freshness protection of persistent objects, and further strengthens the security boundary of stored data.

[0020] (3) The present invention uses a triplet of user identifier, biometric type identifier and template number as object identifier. Combined with the hierarchical management and control mechanism of multimodal template and the slot quantity limit mechanism, it supports the isolated storage and linkage deletion management of three types of templates: face, application-side synchronous voiceprint and terminal-side enhanced voiceprint. It overcomes the defects of the existing single-user exclusive design that cannot adapt to the multi-user shared scenario of the robot, the coarse granularity of the object identifier, and the lack of optimization for the limited eMMC storage capacity. It realizes the accurate positioning and refined management of multi-user multimodal biometric templates and adapts to the hardware conditions of the robot platform with limited storage resources.

[0021] (4) The present invention adopts a four-layer progressive parameter verification mechanism in a trusted execution environment, and verifies the parameters step by step in the order of parameter type pattern matching, buffer size, data header magic number, and embedded vector dimension range. Illegal requests are intercepted and terminated layer by layer. This overcomes the defects of existing general TEE persistent storage solutions, such as lack of biometric-specific entry verification and abnormal format data being easily written to the persistent area, which can cause storage anomalies. It realizes multi-layer security filtering of the storage entry and effectively ensures the format compliance of written data and system stability.

[0022] (7) The present invention adopts a closed-loop biometric comparison mechanism within a trusted execution environment. The plaintext template does not leave the secure world throughout the entire process and only returns the matching result or the matching result and user identifier to the rich execution environment. This overcomes the defects of existing schemes where the comparison boundary does not converge to the trusted environment and the plaintext template is easily exposed after the main operating system is compromised. It realizes a trusted closed loop for the entire process of biometric access and identification, thereby reducing the security risk of plaintext template leakage from a mechanism perspective.

[0023] (8) This invention adopts a standardized set of object operation commands including existence query and idempotent deletion. It completes the object existence verification through read-only permission. The deletion operation is considered successful when the object does not exist to achieve idempotency. It overcomes the shortcomings of the existing solution in terms of insufficient persistent object lifecycle management capability and poor robustness of upper-layer business calls. It realizes the standardized management of the entire lifecycle of biometric templates and improves the compatibility and operation stability of system interfaces.

[0024] (9) The present invention adopts a hardware-level isolated biometric security storage architecture, which matches the industry standard requirements for robot full life cycle identity management and information security protection. It overcomes the defects of existing storage solutions that are not adapted to the standardization and compliance requirements of the robot field, realizes the alignment of biometric security capabilities with industry standards, and supports the compliant implementation of robot products. Attached Figure Description

[0025] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a system architecture diagram of the present invention; Figure 3 This is a schematic diagram of the anti-rollback mechanism of the present invention. Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] It should be noted that, unless otherwise specified, the features in the following embodiments and implementation methods can be combined with each other.

[0028] Example 1

[0029] Figure 1 This is a flowchart illustrating a method for secure storage of biometric features according to an embodiment of the present invention. The corresponding system architecture is as follows. Figure 2 As shown. Figure 1 and Figure 2 As shown, the biometric secure storage method in this embodiment of the invention is executed on a computing platform of an embodied intelligent robot equipped with TrustZone hardware security extension. The computing platform includes an enriched execution environment and a trusted execution environment. The method includes the following steps: Step S1: Receive storage request.

[0030] The client program in the rich execution environment receives a storage request, which carries a user identifier, a biometric type identifier, a template number, and a biometric feature embedding vector extracted from the original biological data by a biometric feature extraction algorithm.

[0031] Specifically, the storage request includes: The user_id string (e.g., "account_master") used to uniquely identify a user can be up to 128 characters long. The biometric type is represented by the character type="face", which indicates a human face; type="voice" indicates application-side synchronous voiceprint; and type="voice_enhanced" indicates end-side enhanced voiceprint. The end-side enhanced voiceprint is not a regular voiceprint template formed by adding a new recording entry. Instead, it is the enhanced voiceprint slot of the same user that is replaced after the candidate voiceprint features have been judged by face matching and lip movement detection in daily recognition. The sequence number string seq that identifies the template slot; And a biometric embedding vector, a float array, with dimensions dim between 1 and 512, extracted from the original image / audio by a face recognition algorithm or a voiceprint recognition algorithm.

[0032] Step S2: Data packaging and transmission.

[0033] The user identifier, biometric type identifier, template sequence number, and biometric feature embedding vector are packaged into a contiguous memory block. This block is then transmitted across the TrustZone hardware boundary via shared memory, sending a storage command to a trusted application running in a secure world within a trusted execution environment. In this embodiment, the packaging order is as follows: a header structure (containing a magic number constant for data integrity verification, embedding vector dimension dim, biometric type type, user identifier user_id, and template sequence number seq), followed by a feature embedding vector consisting of dim 32-bit floating-point numbers. The total length of the packaged data block is sizeof(TBioStoreHdr) + dim × 4 bytes.

[0034] Step S3: Multi-level parameter verification.

[0035] In response to a storage command, the processor switches to the secure world, where trusted applications perform multi-layered parameter verification on the received data within the trusted execution environment. This includes parameter type pattern matching verification, buffer size verification, data header magic number verification, and embedded vector dimension range verification.

[0036] The multi-level parameter verification is performed in the following progressive order: The first layer is parameter type pattern matching and validation, which checks whether the command parameter type pattern matches the preset pattern of the stored command. If they do not match, a parameter type error is returned and the processing is terminated. The second layer is the buffer size check, which checks whether the actual size of the shared memory buffer can at least accommodate the length of the data header structure (sizeof(TBioStoreHdr)) plus the total data length of the biometric embedding vector dim×sizeof(float). If it does not meet the requirement, it returns a buffer too small error. The third layer is the data header magic number verification, which parses the magic number field from the data header structure and compares it with the preset magic number constant. If they are inconsistent, it means that the data has been damaged or tampered with during transmission, and returns an error parameter. The fourth layer is the embedding vector dimension range verification, which verifies whether the biometric feature embedding vector dimension dim is within the preset valid range [1, 512]. If it is not within the range, the parameter error is returned.

[0037] If any verification fails, the trusted application immediately terminates the process and returns the corresponding failure reason, without proceeding to the subsequent storage process.

[0038] Step S4: Object identifier construction.

[0039] After the parameters pass the verification, the trusted application constructs an object identifier in the form of a triplet using the user identifier, biometric identifier, and template sequence number.

[0040] In this embodiment, the object identifier format is "{user_id} / {type} / {seq}". Persistent objects from different users, different biometric types, and different template numbers achieve storage space isolation through this three-level namespace: Level 1 isolation by user (templates from different users are not visible to each other), Level 2 isolation by template type (the face, application-side synchronized voiceprint, and end-side enhanced voiceprint of the same user are stored separately), and Level 3 isolation by slot (currently, the same type uses a fixed slot; subsequent re-encoding or enhancement is replaced on the same-named object). For example, "account_master / face / 0" represents the face template of the main account, and "account_master / voice_enhanced / 0" represents the end-side enhanced voiceprint template of the main account.

[0041] Step S5: Implement the anti-rollback storage strategy.

[0042] Before creating a new persistent object, a trusted application first calls the persistent object open interface and attempts to open an existing persistent object with the same name as the object identifier with write metadata permissions. If an existing persistent object exists, it calls the persistent object delete interface to permanently delete the existing persistent object; then it calls the persistent object create interface to create a new persistent object.

[0043] In this embodiment, the input parameters of the persistent object creation interface include storage type, access flag, and initial data. The storage type includes a private persistent storage type (accessible only by this trusted application). The access flag represents permissions including read permission, write permission, metadata operation permission, and overwrite permission. The initial data is the contiguous memory block packaged in step S2. The persistent object creation interface creates a new persistent object with the private persistent storage type and overwrite permission.

[0044] Step S6: Data writing and storage.

[0045] The trusted application writes the packaged contiguous memory blocks into a new persistent object, completing the secure storage of the biometric template.

[0046] In this embodiment, the secure operating system storage subsystem in the trusted execution environment writes the created persistent objects into the RPMB security partition of the eMMC memory in encrypted form. The RPMB security partition contains a counter. When a trusted application calls the persistent object deletion interface to permanently delete an existing persistent object, the corresponding counter increments by 1. The new counter value is used as the internal version number of the persistent object to be created, thus achieving anti-rollback protection for persistent objects. Using this scheme, even if an attacker physically disassembles the eMMC storage chip and rewrites the old version data snapshot to the storage medium after an old version object is marked as deleted, the secure operating system can detect that the internal version number of the old version object is less than the current RPMB counter value and refuse to read it.

[0047] Example 2

[0048] This embodiment describes in detail the implementation method of storing a face feature template for the first time by a single user, based on the method described in Embodiment 1.

[0049] Specifically, this embodiment is implemented on a quadruped robot dog computing platform equipped with an NVIDIA Jetson AGX Orin processor. This processor is based on the ARMv8.2-A architecture and has a built-in ARM TrustZone hardware security extension. The TEE side runs OP-TEE OS version 4.2. During platform startup, the boot component verification is completed by the secure boot chain. TrustZone divides the processor's operating environment into an enriched execution environment and a trusted execution environment. Client programs on the enriched execution environment side enter the OP-TEE OS through the standard TEE client interface, kernel TEE driver, and security monitoring calls, where subsequent storage operations are performed by trusted applications within the secure world.

[0050] S1: The quadruped robot dog's built-in RGB camera (1920×1080 resolution, 30fps) captures the user's facial image. The facial feature extraction algorithm running on the REE side outputs a 512-dimensional float32 biometric embedding vector (total data size 512×4=2048 bytes). The upper-layer application initiates a storage request, carrying the parameters: user_id="user_main", type="face", seq="0", embedding=512-dimensional vector.

[0051] S2: The client program on the enriched execution environment side packages the storage command parameters into a contiguous memory block. In this embodiment, the packaging format is: 4-byte magic number (0x5242494F) + 4-byte dimension (512) + biometric type string + user identifier string + template sequence number string + 2048-byte biometric feature embedding vector data, with a total length of 2216 bytes. The client program allocates a shared memory buffer, copies the packaged data to the buffer, and transmits the storage command to the trusted execution environment through a security monitoring call. Specifically, the client program initializes the trusted execution environment communication context, establishes a session channel with the trusted application, and transmits the packaged data block to the trusted application along with the storage command via shared memory input. In this step, the data crosses the ARM TrustZone hardware isolation boundary, entering the secure world of the trusted execution environment from the enriched execution environment.

[0052] S3: The processor switches to the secure world. After receiving the command, the trusted application performs a four-layer progressive verification: the results are as follows: parameter type pattern matching, buffer size not less than 2216 bytes, magic number consistent with the preset constant, and embedded vector dimension 512 within the valid range of 1 to 512. All four layers of verification pass, proceed to the next step.

[0053] S4: Trusted Application Building Object Identifier "user_main / face / 0" S5: A trusted application attempts to open a persistent object with the same name with write metadata permissions, but skips the deletion step because the object does not exist when it is first stored, and creates a new encrypted persistent object with a private storage type and an overwrite flag.

[0054] S6: The Trusted Execution Environment (TEX) operating system derives an encryption key using the trusted application's dedicated device key, encrypts a 2216-byte data block, and writes it to the RPMB partition of the eMMC storage, using the partition's current counter value as the object's internal version number. The trusted application then returns a storage success indication, and the client program notifies the upper-layer application that storage is complete.

[0055] Example 3

[0056] This embodiment, based on embodiment 2, provides a specific implementation process for updating the face template for the same user to perform anti-rollback verification. The implementation process of steps S1~S4 and S6 is the same as in embodiment 2, and will not be repeated here.

[0057] S5: The user re-enters a face template, and the embedded vector is updated to version 2. Assuming that before this, the old persistent object version was v1, and the counter value was 1, the trusted application constructs an object with the same identifier "user_main / face / 0". At this point, it attempts to open the existing old persistent object (version v1) with the same identifier and permanently delete it. The RPMB write counter increments to 2, and then updates the version number to v2, creating a new persistent object.

[0058] The attacker physically disassembled the eMMC chip and cloned the partition data, obtaining a first-version data snapshot with version number v1, which was then rewritten. When the trusted execution environment operating system loaded the object, it detected that the value of object version number v1 (1) was less than the current counter value (2) and that this version had been marked for deletion, thus identifying it as a rollback attack and refusing to read it.

[0059] Example 4

[0060] Based on Example 2, this embodiment further defines the biometric type identifier as including a face template identifier, an application-side synchronous voiceprint template identifier, and an end-side enhanced voiceprint template identifier; each user corresponds to a maximum of three template slots, which respectively store the face template, the application-side synchronous voiceprint template, and the end-side enhanced voiceprint template; the end-side enhanced voiceprint template is written after the candidate voiceprint features pass the assisted judgment by face matching and lip movement detection, and is isolated from the application-side synchronous voiceprint template; when the application-side synchronous voiceprint template is deleted, the end-side enhanced voiceprint template is also deleted.

[0061] This embodiment takes a home scenario as an example to provide a specific implementation process for multi-user, multi-template storage verification.

[0062] For example, three users register their biometrics, with each user having three preset template slots (face, application-side synchronized voiceprint, and device-side enhanced voiceprint). Specific information is as follows:

[0063] Each template has a unique persistent object identifier: user_main / face / 0, user_main / voice / 0, user_main / enhanced_voice / 0; user_family_1 / face / 0, user_family_1 / voice / 0; user_family_2 / face / 0; a total of 6 persistent objects. Each object is independently encrypted by the OP-TEE OS using a TA-specific key. Objects from different users and different biometric types are completely isolated at both the logical namespace and physical encryption levels—even if an attacker obtains the storage block corresponding to user_main / face / 0, they cannot decrypt the data of user_family_1 / face / 0 using the same key (the object keys are different, although they are both derived from the TA-specific key).

[0064] When the authorization of a family member's account expires, the computing platform iterates through all face and voiceprint template number combinations under the user's identifier, opens them one by one in the trusted execution environment, and permanently deletes the corresponding persistent objects; the enhanced voiceprint on the client side must be cleared along with the voiceprint on the application side; the non-existent template is considered to have achieved the deletion target, realizing the batch clearing of all biometric features of the user.

[0065] Example 5

[0066] This embodiment, based on embodiment 4, provides a specific implementation process for the mandatory enforcement mechanism of the upper limit of template slots. First, this embodiment clearly stipulates that each user can correspond to a maximum of three biometric template slots, namely face, application-side synchronous voiceprint, and terminal-side enhanced voiceprint; the system must check the number of users and the type of template slots before storage operations.

[0067] A1: After receiving a storage request, the trusted application verifies whether the target user belongs to a maximum of 10 valid users before constructing the object identifier, and confirms that the requested template type belongs to one of face, application-side synchronous voiceprint, or end-side enhanced voiceprint.

[0068] A2: If a request attempts to write to a slot other than the default template, the trusted application will refuse to add the new slot; if a request attempts to write to an existing slot of the same user, the process of deleting and then creating the new slot will be initiated, replacing the old object with the same name with the new template.

[0069] A3: For end-side enhanced voiceprint slots, trusted applications only receive the enhanced voiceprint embedding vector after upstream judgment; this embedding vector is formed by voiceprint candidate features after being confirmed by face matching and lip movement detection, and is used to replace the end-side enhanced voiceprint object of the same user.

[0070] Template slot limits are enforced on the trusted execution environment side: even if the limit judgment on the rich execution environment side is tampered with, the independent check on the trusted application side still takes effect.

[0071] Example 6

[0072] This embodiment provides a complete testing process for the storage command security mechanism, based on embodiments 1 and 3.

[0073] The following test scenarios verify the system's security boundaries: Test Scenario A: Attack involving forged command parameter types.

[0074] The attacker constructs a store command but sets the parameter type flag to output mode instead of input mode. The trusted application's first-level validation detects that the parameter type does not match the default store command mode, returns a parameter error, and terminates the process.

[0075] Test Scenario B: Insufficient Buffer Attack.

[0076] The attacker declared the embedding vector dimension to be 512, but the actual shared memory was only 64 bytes. The trusted application's second-layer verification found that the buffer was smaller than the required length of the data header plus the embedding vector, 2216 bytes, and returned a buffer too small error.

[0077] Test Scenario C: Magic Number Tampering Attack.

[0078] The attacker tampered with the data header magic number, changing it from the default constant 0x5242494F to another value. The trusted application's third-layer verification detected the inconsistency in the magic number and returned an error.

[0079] Test Scenario D: Feature Dimension Out-of-Bounds Attack.

[0080] The attacker declared the embedded vector dimension to be 65535. The trusted application's fourth-layer validation detected that the dimension exceeded the valid range of 1 to 512 and returned a parameter error.

[0081] Test Scenario E: Snapshot Rollback Attack.

[0082] The system correctly detects and rejects the complete attack chain as described in Example 3.

[0083] Example 7

[0084] This embodiment provides idempotency verification for the query and delete interfaces based on embodiment 1.

[0085] In this embodiment, the trusted application also supports the following operation commands: Existence query command: After receiving an existence query request, the trusted application attempts to open the persistent object corresponding to the specified object identifier with read-only permissions. If the opening is successful, it returns an existence flag of true and closes the object. If it returns an error that the object does not exist, it returns an existence flag of false. Delete command: After receiving a delete request, the trusted application opens the persistent object corresponding to the specified object identifier with write metadata permissions and deletes it permanently. If the object does not exist, the deletion is considered successful to achieve idempotency of the operation.

[0086] First, perform an existence test on the query: If the object exists, the trusted application opens it successfully with read-only permissions and returns an existence flag; If the object does not exist, the open operation returns an object non-existent indication and a non-existent flag.

[0087] Secondly, perform the deletion idempotency test: If the object exists, the trusted application opens it, permanently deletes it, and returns a success message. If an object has already been deleted, performing the deletion again will result in the object not existing being returned, but the operation will still return success, thus achieving idempotency.

[0088] This idempotent property simplifies the exception recovery logic of upper-layer applications: even if the delete command is sent repeatedly due to network jitter or process restart, the system can respond correctly without generating errors.

[0089] Example 8

[0090] This embodiment, based on Embodiment 1, provides a specific implementation process for the full data clearing mechanism during device unbinding. After the main account initiates unbinding via mobile terminal and receives secondary confirmation, the cloud sends the unbinding command to the computing platform.

[0091] B1: After receiving the unbinding request, the rich execution environment constructs a full clear command, packages the list of all user identifiers in the local account configuration, and passes it to the trusted application through shared memory.

[0092] B2: The trusted application iterates through each user identifier, enumerates all persistent objects in its namespace and permanently deletes them one by one, directly erasing the encrypted data in the RPMB partition.

[0093] B3: Trusted applications clear the internal object identity mapping cache and set a full clear completion flag.

[0094] B4: Enrich the execution environment by simultaneously deleting local account configurations, authorization relationships, and personalized settings, among other user data. After unbinding, the computing platform will revert to its factory-set, unactivated state.

[0095] This dual-end erasure mechanism ensures that restoring factory settings not only erases data at the file system layer (REE side), but also irreversibly erases all biometric templates at the hardware security layer (TEE RPMB side), meeting the requirement of completely destroying all stored data (unrecoverable) when the user logs out or the device is scrapped.

[0096] Example 9

[0097] This embodiment, based on Embodiment 1, provides a specific implementation process for the biometric template comparison step, specifically including: receiving an identification request carrying a query embedding vector; transmitting the query embedding vector to the trusted application via shared memory; the trusted application opening a persistent object corresponding to the object identifier within the secure world of the trusted execution environment; calculating the similarity between the biometric embedding vector and the query embedding vector without the template plaintext leaving the secure world; determining a successful match when the similarity exceeds a preset threshold; otherwise, a failed match, returning only the matching result to the rich execution environment, or only the matching result and the user identifier. The similarity calculation uses cosine similarity or Euclidean distance, and a successful match is determined when the similarity exceeds the preset threshold.

[0098] In one embodiment, after a user issues a voice command requiring identity verification, the computing platform obtains a 512-dimensional real-time embedding vector from the voiceprint processing side. The trusted storage client packages the query vector with the user identifier and biometric type, and passes it to the trusted application via shared memory. The trusted application opens the persistent object "user_main / voice / 0" in the secure world, calculates the cosine similarity between the query embedding vector and the stored template; if the similarity exceeds the threshold of 0.70, it only returns a successful match and the user identifier, without returning the template plaintext to the rich execution environment.

[0099] Example 10

[0100] This embodiment verifies the schemes described in Embodiments 1 to 9 through bench testing.

[0101] This embodiment verifies secure storage and comparison on a Jetson AGX Orin + OP-TEE 4.2 rack, with each operation repeated 50 times. The results are as follows.

[0102]

[0103] The above experimental results verify that the various settings of the present invention are highly effective.

[0104] Example 11

[0105] This embodiment, based on embodiment 1, demonstrates the consistency guarantee mechanism between the writing of account configuration metadata and the writing of trusted execution environment objects after successful biometric data entry.

[0106] Background: The quadruped robot dog's account information (including user ID, authorization scope, following distance, etc.) is persistently stored in the local configuration service (based on the file system) on the rich execution environment side; while the biometric embedding vector template is stored in the RPMB partition persistent object of the trusted execution environment. The two are managed by different processes—the account configuration is maintained by the account service process, and the TEE object is managed by the trusted application within the secure world. Upon successful data entry, both sides' data must be updated simultaneously, and in the event of failure on either side, inconsistencies must be avoided.

[0107] C1 (Phase 1 - Configuration Metadata Writing): After the feature processing unit reports the completion of data entry and the 512-dimensional face embedding vector, the data entry and arrangement unit executes the following sequence of atomic operations: C1.1: Locate the target user in the list of currently valid accounts based on the user identifier field in the message header; C1.2: Call the cryptographically secure random number generator to generate a globally unique feature identifier, and write the identifier into the target user's face feature record field; C1.3: Serialize the updated complete account list and submit it to the write interface of the configuration service; C1.4: If the configuration service is successfully written, proceed to the second stage; if it fails, start a retry timer (default interval 5 seconds), and re-execute step C1.3 after the timer is triggered, until the writing is successful or the maximum number of retries is reached.

[0108] C2 (Phase Two - Trusted Storage Object Write): After configuration write confirmation, the orchestration unit uses the triple "{user_id} / {type} / {seq}" as the object identifier and passes the biometric embedding vector to the trusted application via shared memory. The trusted application then creates or updates the RPMB encrypted persistent object within the secure world.

[0109] C3 (Consistency Status Broadcast): After both sides have completed the write, the orchestration unit increments the version broadcast identifier of the face dimension and publishes an account status change notification; downstream modules can refresh the cache by dimension after subscribing to the notification without having to re-parse all account data.

[0110] C4 (Abnormal Scenario—TEE Write Failure Rollback): If the trusted application returns a write failure in step C2 (e.g., RPMB partition is unavailable or the object count reaches the limit), the orchestration unit removes the feature identifiers written in step C1 from the target user's feature record field and resubmits the configuration write, rolling back the account configuration to its pre-entry state. This rollback mechanism ensures that there will be no dangling references on the account side showing entries but no corresponding template objects in the trusted execution environment.

[0111] The two-phase commit mechanism described above ensures that the biometric template is stored in the database with transactional semantics: either the configuration and TEE simultaneously contain references to and data of the new template, or neither contains them, eliminating any intermediate inconsistencies. For scenarios involving unexpected device power outages or process crashes, the alignment check during system startup (see Example 12) further eliminates any remaining inconsistencies.

[0112] Example 12

[0113] This embodiment, based on embodiment 11, demonstrates the configuration-trusted storage consistency self-healing mechanism that is automatically executed after the computing platform starts.

[0114] D1: After the account service process starts, it first reads the locally persisted account list from the configuration service to obtain all valid users and their characteristic identifiers (face_id / voice_id).

[0115] D2: The account service sends an enumeration request to the trusted execution environment to obtain a list of all persistent object identifiers that actually exist in the current RPMB partition.

[0116] D3: Perform a two-way comparison: D3.1: Forward cleanup: Iterate through each feature identifier of each user in the configuration account list. If the corresponding triplet persistent object does not exist in the TEE enumeration result, then clear the feature identifier (mark it as "template lost and needs to be re-entered"). D3.2: Reverse Cleanup: Iterate through each object identifier in the TEE enumeration result. If its {user_id} part is not in the current list of valid accounts (e.g., it has been removed by cloud synchronization but TEE cleanup was not completed before the last shutdown), then the trusted application permanently deletes the orphan object.

[0117] D4: Rewrite the aligned account list into the configuration service and publish the initial state notification.

[0118] This startup alignment mechanism covers the following abnormal residual scenarios: (a) the device lost power during the last data entry process, resulting in the configuration being written but the TEE not being written; (b) a user was deleted from the cloud account synchronously, but the TEE cleanup command was not executed before the power was lost; (c) the RPMB partition has an orphaned object due to hardware reasons. Through bidirectional scanning and repair during startup, the system ensures that the configuration and trusted storage are in a consistent state after each cold start.

[0119] Example 13

[0120] This embodiment, based on embodiments 11 and 12, demonstrates the linkage deletion mechanism between the application-side configuration and the trusted execution environment template storage when an account expires or is actively deleted, covering the following three typical scenarios.

[0121] Scenario A: Scheduled cleanup of expired accounts.

[0122] E1: The account service process calls the accountExpireCheck() function at a preset period (every 60 seconds by default) to obtain the current system timestamp.

[0123] E2: Iterate through the local account list and compare the expiration time (expire_time) of each non-primary account with the current timestamp (nowMs). If expire_time > nowMs, the account is still valid and will be retained; if expire_time ≤ nowMs and the account is a non-primary account, mark it as pending deletion.

[0124] E3: For each account to be deleted, the account service checks whether its face_id and voice_id are not empty. If they are not empty, the biometric status is marked as changed (faceChanged / voiceChanged is true).

[0125] E4: The account service physically removes the account record from the local account list, serializes the updated account list, calls the configuration service to write the interface, and submits the updated account list.

[0126] E5: For each tagged face_id, the account service invokes the trusted application's delete command using the triple rule {user_id} / face / 0. The trusted application opens and permanently deletes the persistent object with write metadata permissions. The voiceprint template object corresponding to the voice_id is processed synchronously.

[0127] E6: After deletion on both sides is complete, the account service publishes an account deletion status notification, incrementing the version broadcast identifier for both face and voiceprint dimensions. Downstream subscription modules refresh their local cache upon receiving the notification.

[0128] This mechanism ensures that when an account expires, its configuration references in the rich execution environment and its encrypted template data in the trusted execution environment are cleared simultaneously, leaving no dangling feature identifier references.

[0129] Scenario B: The user actively deletes biometric data.

[0130] F1: When the main account user initiates the "Delete specified user face template" command on the mobile terminal side, the account service will construct a deletion command containing the target user's identifier and biometric type after receiving the deletion request.

[0131] F2: The account service clears the target user's face_id field and calls the configuration service to write the updated account list (atomic operation). If the configuration service writes successfully, continue with subsequent steps.

[0132] F3: The account service calls the trusted application's delete interface using the triple user_id / face / 0. The trusted application performs idempotent deletion—the object is permanently deleted if it exists, and returns success if the object does not exist.

[0133] F4: After both configuration writing and TEE deletion are completed, increment the face dimension version identifier and issue a change notification.

[0134] Scenario C: Inconsistent recovery after unexpected power outage of equipment.

[0135] G1: Assume that during the data entry process, the device unexpectedly loses power after the configuration is written but before the TEE is written (in Example 11, S1 is successful but S2 is not executed).

[0136] G2: After the device restarts, perform the startup alignment check of Example 12—enumerate the actual objects in the TEE and compare them with the feature identifier list in the configuration.

[0137] G3: Forward scan found that face_id has a value in the configuration but the corresponding user_id / face / 0 object does not exist in the TEE, which is determined to be a "dangling reference".

[0138] G4: The account service removes the dangling face_id, rolls back the configuration to a state consistent with the TEE, and publishes a change notification.

[0139] G5: Optionally, push a notification to the user that "the face template was not saved due to an interruption in the recording process. Please re-enter the data" to guide the user to complete the recording.

[0140] This three-tiered scenario covers the complete deletion chain of the account lifecycle: active deletion is triggered by the user, expired cleanup is automatically executed by a timer, and power failure recovery is handled by startup alignment—these three mechanisms jointly ensure the consistency of configuration and TEE data. Together with the two-phase commit positive guarantee in Implementation Example 11 and the startup alignment fallback guarantee in Implementation Example 12, they together constitute a complete account-TEE linkage security system.

[0141] This embodiment also provides a robot, including a memory and a processor. The memory stores executable code, and the processor supports TrustZone hardware security extensions. When executing the executable code, it is used to implement the biometric secure storage method.

[0142] This disclosure can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of this disclosure.

[0143] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, (but not limited to) electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0144] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0145] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0146] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0147] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0148] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0149] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0150] The computer program product can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0151] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0152] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

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

[0154] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A method for securely storing biometric data, executed on a computing platform of an embodied intelligent robot equipped with TrustZone hardware security extensions, the computing platform comprising a rich execution environment and a trusted execution environment, characterized in that, The method includes the following steps: Step S1: Receive a storage request in an enriched execution environment. The storage request carries a user identifier, a biometric type identifier, a template number, and a biometric feature embedding vector extracted from the original biological data by a biometric feature extraction algorithm. Step S2: Pack the user identifier, biometric type identifier, template number and biometric feature embedding vector into a contiguous memory block, cross the TrustZone hardware boundary through shared memory, and send a storage command to the trusted application running in the secure world of the Trusted Execution Environment; Step S3: In response to the storage command, the trusted application performs multi-level parameter verification on the received data within the secure world of the trusted execution environment, including parameter type pattern matching verification, buffer size verification, data header magic number verification, and embedded vector dimension range verification. Step S4: After the parameter verification is passed, the trusted application constructs an object identifier in triplet format using the user identifier, biometric type identifier, and template sequence number; Step S5: Before creating a new persistent object, the trusted application first calls the persistent object opening interface and attempts to open an existing persistent object with the same name as the object identifier with write metadata permissions. If the existing persistent object exists, the application calls the persistent object deletion interface to permanently delete the existing persistent object; then it calls the persistent object creation interface to create a new persistent object. Step S6: The trusted application writes the packaged contiguous memory block into the new persistent object, completing the secure storage of the biometric template.

2. The method for securely storing biometric data according to claim 1, characterized in that, In step S5, the input parameters of the persistent object creation interface include storage type, access flag and initial data. The storage type includes private persistent storage type. The access flag represents permissions including read permission, write permission, metadata operation permission and overwrite permission. The initial data is the contiguous memory block packaged in step S2. The persistent object creation interface creates new persistent objects with private persistent storage type and overriding permissions.

3. The method for securely storing biometric data according to claim 1, characterized in that, In step S5, the secure operating system of the trusted execution environment writes the created persistent object into the RPMB security partition of the eMMC memory in encrypted form. The RPMB security partition is equipped with a counter. When the trusted application calls the persistent object deletion interface to permanently delete an existing persistent object, the corresponding counter is incremented by 1. The new counter value is used as the internal version number of the persistent object to be created to create the persistent object, thereby realizing the rollback protection of the persistent object.

4. The method for securely storing biometric data according to claim 1, characterized in that, The multi-level parameter verification in step S3 is performed in the following order: the first level is parameter type pattern matching verification, which verifies whether the command parameter type pattern matches the preset pattern of the stored command. If they do not match, a parameter type error is returned and the processing is terminated. The second layer is buffer size verification, which verifies whether the actual size of the shared memory buffer can at least accommodate the length of the data header structure plus the total data length of the biometric embedding vector. If it does not meet the requirement, it returns a buffer too small error. The third layer is data header magic number verification, which parses the magic number field from the data header structure and compares it with the preset magic number constant. If they do not match, it returns a parameter error. The fourth layer is the embedding vector dimension range verification, which verifies whether the biometric feature embedding vector dimension is within the preset valid range. If it is not within the range, it returns a parameter error.

5. The method for securely storing biometric data according to claim 1, characterized in that, The trusted application also supports the following operation commands: Existence query command: After receiving an existence query request, the trusted application attempts to open the persistent object corresponding to the specified object identifier with read-only permissions. If the opening is successful, it returns an existence flag of true and closes the object. If it returns an error that the object does not exist, it returns an existence flag of false. Delete command: After receiving a delete request, the trusted application opens the persistent object corresponding to the specified object identifier with write metadata permissions and deletes it permanently. If the object does not exist, the deletion is considered successful to achieve idempotency of the operation.

6. A method for securely storing biometric data according to claim 1, characterized in that, The biometric identifier includes a face template identifier, an application-side synchronous voiceprint template identifier, and a terminal-side enhanced voiceprint template identifier; each user has a maximum of three template slots, which store the face template, the application-side synchronous voiceprint template, and the terminal-side enhanced voiceprint template, respectively; the terminal-side enhanced voiceprint template is written after the candidate voiceprint features pass the assisted judgment by face matching and lip movement detection, and is isolated from the application-side synchronous voiceprint template; when the application-side synchronous voiceprint template is deleted, the terminal-side enhanced voiceprint template is also deleted.

7. A method for securely storing biometric data according to claim 1, characterized in that, The method further includes a biometric template comparison step: receiving an identification request carrying a query embedding vector, and passing the query embedding vector to the trusted application through shared memory; the trusted application opens a persistent object corresponding to the object identifier in the secure world of the trusted execution environment, calculates the similarity between the biometric embedding vector and the query embedding vector without the template plaintext leaving the secure world, and determines that the match is successful when the similarity exceeds a preset threshold, otherwise the match fails, and only returns the matching result to the rich execution environment, or only returns the matching result and the user identifier.

8. A biometric secure storage system applied to a computing platform of an embodied intelligent robot equipped with TrustZone hardware security extension, the computing platform comprising a rich execution environment and a trusted execution environment, characterized in that, include: The client program in the rich execution environment is used to receive storage requests and package them into contiguous memory blocks. The storage command is sent to the secure world of the TrustZone hardware boundary through shared memory. The storage request carries a user identifier, a biometric identifier, a template number, and a biometric feature embedding vector extracted from the original biological data by a biometric feature extraction algorithm. Trusted applications in a secure world of trusted execution environments are used to perform multi-layer parameter verification, construct object identifiers in triplet format consisting of the user identifier, biometric identifier, and template sequence number, execute anti-rollback storage strategies, and complete encrypted storage. The multi-layer parameter verification includes parameter type pattern matching verification, buffer size verification, data header magic number verification, and embedded vector dimension range verification. The execution of anti-rollback storage strategies and completion of encrypted storage specifically involves: before creating a new persistent object, calling the persistent object opening interface and attempting to open an existing persistent object with the same name as the object identifier with write metadata permissions; if the existing persistent object exists, calling the persistent object deletion interface to permanently delete the existing persistent object; then calling the persistent object creation interface to create a new persistent object. A secure operating system storage subsystem in a trusted execution environment is used to write persistent objects created by the trusted application into the RPMB secure partition of the eMMC memory in encrypted form.

9. A robot, characterized in that, The device includes a memory and a processor, wherein the memory stores executable code, and the processor supports TrustZone hardware security extensions and, when executing the executable code, implements the biometric secure storage method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a program that, when executed by a processor that supports TrustZone hardware security extensions, implements the biometric secure storage method according to any one of claims 1-7.

Images