A method and system for hosting a mobile terminal for a minor

Abstract

The application discloses a kind of juvenile mobile terminal hosting method and system, solve the defect that existing hosting scheme high authority exit operation only relies on software verification, ordinary hardware label is easily copied and replayed.Solution with built-in security chip, private key non-derivable entity root certificate key as hardware trust root, ordinary NFC fixed UID only for auxiliary identification, not constitute trust root;Parent end submits public key to cloud and creates family hosting root bound with key, cloud only stores public key, key identification and association relationship.After child end obtains hosting root identification, it is verified into group by entity key challenge response, and high authority exit operation is blocked according to permission level, generates one-time challenge bound with context, and issues multi-dimensional bound cloud signature execution permission after entity key signature and cloud signature verification, and can be executed after child end verification passes.The application establishes hardware level security threshold, can resist replay, key cloning attack, and improves hosting security.

Description

Technical Field

[0001] This invention relates to the fields of mobile terminal security management, prevention of addiction among minors, and security authentication of physical credentials. Specifically, it relates to a method and system for managing mobile terminals for minors. Background Technology

[0002] With the rapid development of the mobile internet, smartphones, tablets, and other mobile devices have become important tools for minors' learning, entertainment, and social interaction. To guide minors in the reasonable use of mobile devices and prevent excessive internet addiction and exposure to inappropriate content, various mobile device management technologies have emerged. Existing mobile device management methods mainly fall into two categories: one is the local control function provided by the operating system itself, which uses system permissions to implement basic controls such as application usage time limits, content filtering, and screen locking; the other is a cloud-based third-party management system, typically employing an architecture where parent and child applications work together. This allows parents to remotely set control policies, view their child's device usage records, approve temporary usage requests, and update policies through cloud synchronization, achieving unified management across devices and scenarios. Some existing technologies also incorporate auxiliary verification methods such as NFC tags and QR codes for quickly switching control modes or unlocking specific applications.

[0003] However, existing mobile device management systems for minors have a fundamental security flaw: high-privilege exit operations (uninstalling the child's app, unbinding the parent's account, canceling the management status, and disabling device management permissions, etc.) rely solely on software-level account passwords or remote parental approval. Children can easily bypass these controls by obtaining their parents' phones and clicking "agree," cracking their parents' account passwords, tampering with local system configurations, or restoring factory settings, failing to create a truly unassailable hardware-level security barrier. Even when some solutions employ hardware-assisted verification such as NFC cards, these are often based on simple comparisons of fixed UIDs or pre-stored code values, making them susceptible to copying, replaying, or tampering. Furthermore, they are typically only used to enable or disable basic management functions and do not consider hardware as the sole necessary verification condition for high-privilege exit operations, thus failing to fundamentally solve the problem of children bypassing the management system. Summary of the Invention

[0004] This invention proposes a method and system for managing mobile terminals for minors, aiming to solve the defect in the prior art where high-privilege exit operations are easily bypassed by software. It establishes a hardware-level verification threshold through an entity root credential key, which blocks access in controlled device mode and detects, alarms, and recovers in normal device mode.

[0005] The technical solution of the present invention is as follows: A method for managing a minor's mobile device includes the following steps: Parents read the physical root credential key and submit the public key information corresponding to the physical root credential key to the cloud hosting service to create a family hosting root. The cloud only stores the public key, key identifier, and family root association, and does not store the private key. The physical root credential key has a built-in security chip, and the private key is stored inside the security chip and cannot be exported. The hardware form of the physical root credential key includes an NFC key with a security chip, a dynamic NFC security key, a FIDO security key, or customized security hardware. Ordinary NFC fixed UID is only used for auxiliary identification and does not constitute a secure trust root. The child obtains the family care root identifier through a preset method, reads the same entity root credential key, and joins the family care group corresponding to the family care root after passing the challenge response verification, and enters the care status. The preset method includes QR code, invitation code, family code or near field transmission. When the child is under supervision, the system monitors preset high-privilege exit operations in real time. When a high-privilege exit operation is detected, the system will perform corresponding blocking actions according to the terminal system permission level. Under high-privilege, the operation will be blocked directly. Under normal-privilege, the system will intercept the in-app operation entry, pop up a verification prompt, record the operation behavior, and send an alarm to the guardian. For blocked high-privilege exit operations, generate a one-time challenge uniquely bound to the context of this operation; The one-time challenge is transmitted to the entity root credential key via a communication channel, and the entity root credential key uses a non-exportable private key to sign the one-time challenge, generating an operation signature. The operation signature is verified. Once the verification is successful, an execution license is generated that is only applicable to this high-privilege exit operation. The execution license is signed by the cloud hosting service using a cloud private key. The license content is bound to at least the operation unique identifier, child device identifier, family hosting root identifier, operation type, effective time, expiration time, and allowed number of executions. The child client verifies the legality of the cloud signature of the execution license and verifies that the license content matches the current operation context. After all verifications pass, the corresponding high-privilege exit operation is executed.

[0006] In one possible implementation, the child joins the family care group via challenge-response verification, specifically as follows: The child device obtains the family care root identifier through a preset method, generates a binding challenge containing the child's device identifier, the family care root identifier, and a random number, and sends it to the entity root credential key. The entity root credential key uses its internal private key to sign the binding challenge, generates a binding signature, and returns it to the child device. The child device submits the family care root identifier, the binding signature, the device identifier, and the child's account information to the cloud care service. After verifying the validity of the family care root identifier, the cloud care service uses the public key corresponding to the family care root to verify the binding signature. Once the verification is successful, the child's device is added to the family care group.

[0007] In one possible implementation, generating a one-time challenge for the blocked high-privilege exit operation specifically involves: After the child device detects and blocks a high-privilege exit operation, it generates a unique operation identifier, operation type, child device identifier, local random number, current hosting policy version number, and operation trigger source. It then submits the above information and the family hosting root identifier to the cloud hosting service to request the generation of a one-time challenge. The cloud hosting service verifies the hosting status of the child device and the validity of the physical root credential key. If the verification is successful, it generates a cloud random number and an expiration time. After standardizing and encoding the fields of family hosting root identifier, child device identifier, unique operation identifier, operation type, hosting policy version number, local random number, cloud random number, expiration time, and operation trigger source, it calculates a digest to generate the one-time challenge.

[0008] In one possible implementation, verifying the operation signature specifically involves: The cloud-based hosting service queries the corresponding public key and the previously stored signature counter value locally based on the family hosting root identifier. It does not accept the challenge plaintext data returned by the child's end, independently reconstructs the one-time challenge based on the original challenge fields stored locally, checks that the one-time challenge has not expired and that the operation unique identifier has not been used, verifies the operation signature using the public key, and verifies that the current signature counter value is greater than the previous signature counter value to resist key cloning and replay attacks. After all verifications pass, the execution license is generated. When replacing the physical root certificate key, the original physical root certificate key must be present and complete the signature verification. After the verification is successful, the new key will be bound and the old key will be invalidated. If the original physical root certificate key is lost, the identity of the parent will be confirmed through a multi-factor secondary verification process that includes account real-name authentication verification, guardian's bound mobile phone number verification, and facial recognition verification, or customer service manual verification of identity materials and offline valid identity certificate review. Only after the identity is confirmed can the new key be bound and the original key be invalidated. After the old key is invalidated, the cloud hosting service will reject all signature verification requests.

[0009] In one possible implementation, the generation of the execution permit is only applicable to this high-privilege exit operation. The number of times the execution permit can be executed is fixed to 1, and the validity period is matched with a different validity period according to the risk level of the high-privilege exit operation. After the child terminal verifies the legality of the cloud signature of the execution permit, it further verifies that the operation unique identifier, child device identifier, family care root identifier, and operation type all correspond one-to-one with the current operation, and that the current time is within the effective time and expiration time range. The corresponding high-privilege exit operation is executed only after all verifications pass.

[0010] In one possible implementation, the preset high-privilege exit operation includes at least one of the following: uninstalling the child application, unbinding the parent account, removing the childcare status, disabling device management permissions, disabling core restriction policies, resetting the family childcare group, invalidating the family root credential, switching the child's identity to the parent's identity, clearing the child application data, forcibly stopping the child application, disabling accessibility service permissions, disabling usage access permissions, disabling network filtering, disabling notification permissions and background running permissions, modifying the system time, and triggering a factory reset attempt.

[0011] In one possible implementation, after the step of signing the one-time challenge using a non-derivative private key within the entity root credential key, a replay protection verification step is further included: The cloud-hosted service manages the lifecycle of one-time challenges through database transactions or atomic state update mechanisms. It checks whether the same unique identifier or one-time challenge has been used. If it has been used, it refuses to verify the signature. It also refuses expired challenges, duplicate signatures, cross-device signatures, cross-family signatures, and signatures of different operation types. During the signature verification process, the challenge status is atomically changed from pending verification to verification. After the signature verification is completed, it is updated to verified or invalid. This avoids the vulnerability of duplicate verification caused by concurrent requests reusing the same challenge.

[0012] A mobile terminal hosting system for minors, comprising: The family care root creation module allows parents to read the physical root credential key and submit the public key information corresponding to the physical root credential key to the cloud care service to create a family care root. The cloud only stores the public key, key identifier, and family root association, and does not store the private key. The physical root credential key has a built-in security chip, and the private key is stored inside the security chip and cannot be exported. The hardware form of the physical root credential key includes an NFC key with a security chip, a dynamic NFC security key, a FIDO security key, or customized security hardware. Ordinary NFC fixed UID is only used for auxiliary identification and does not constitute a secure trust root. The child-side childcare binding module allows the child to obtain the family childcare root identifier through a preset method, read the same entity root credential key, and join the family childcare group corresponding to the family childcare root after passing the challenge response verification, thus entering the childcare state. The preset method includes QR code, invitation code, family code, or near-field transmission. The high-privilege exit operation monitoring and blocking module monitors preset high-privilege exit operations in real time when the child is under supervision. When a high-privilege exit operation is detected, the corresponding blocking process is executed according to the terminal system permission level. Under high-privilege, the execution of the operation is directly blocked. Under normal permissions, the in-app operation entry is intercepted, a verification prompt is popped up, the operation behavior is recorded, and an alarm is sent to the guardian. The blocked operation one-time challenge generation module generates a one-time challenge that is uniquely bound to the context of the blocked high-privilege exit operation. The entity root credential private key signing module transmits the one-time challenge to the entity root credential key through a communication channel. The entity root credential key then uses a non-exportable private key to sign the one-time challenge, generating an operation signature. The signature verification and execution license issuance module verifies the operation signature. After the verification is successful, an execution license is generated that is only applicable to this high-privilege exit operation. The execution license is signed by the cloud hosting service using a cloud private key. The license content is bound to at least the operation unique identifier, child device identifier, family hosting root identifier, operation type, effective time, expiration time, and allowed number of executions. The execution license verification and operation execution module verifies the legality of the cloud signature of the execution license on the child end, and verifies that the license content matches the current operation context. After all verifications pass, the corresponding high-privilege exit operation is executed.

[0013] A computer device, including A memory that stores computer-readable instructions; A processor, which, when executing the computer-readable instructions, implements the steps of a method for hosting a mobile terminal for minors as described above.

[0014] A computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of the above-described method for hosting a mobile terminal for minors.

[0015] Compared with the prior art, the present invention has the following main advantages: 1. The method of this invention uses a physical root credential key with a built-in security chip as the sole hardware trust root for the family care relationship, creating a family care root uniquely bound to the physical key. The cloud only stores the public key and association relationship, without retaining the private key. The private key is completely sealed inside the security chip and cannot be exported. It also clarifies that ordinary NFC fixed UIDs are only used for auxiliary identification and do not constitute a secure trust root, thus eliminating the security vulnerabilities of pure software verification and ordinary hardware tags from the root. At the same time, it requires the child to first obtain the family care root identifier and then join the family care group after the challenge response verification of the physical root credential key. This achieves a strong binding between the care relationship and the physical hardware, ensuring that only the legal guardian holding the physical key can include the device in the care.

[0016] 2. The method of the present invention monitors the preset high-privilege exit operation in real time on the child's end while under the care system, and performs hierarchical blocking processing according to the terminal system permission level. In the high-privilege mode, the operation is directly blocked. In the normal permission mode, the operation entry in the application is intercepted, a verification prompt is popped up, and an alarm is sent to the guardian's end, so as to realize the pre-interception and risk warning of all bypassing the care system.

[0017] 3. The method of the present invention generates a one-time challenge that is uniquely bound to the context of each blocked high-privilege exit operation, and signs the one-time challenge with a non-exportable private key inside the entity root credential key, thereby achieving the uniqueness and non-replayability of the operation. This completely solves the problem that fixed code values ​​and fixed UIDs are easily copied and replay attacks, while ensuring that the private key will never leave the security chip and cannot be cracked or extracted.

[0018] 4. The method of this invention completes the verification of operation signature through the cloud and issues an execution license signed by the cloud private key. The license content is strongly bound to multiple dimensions such as operation, device, family, time limit, and number of executions. Only after the child terminal verifies the legality of the cloud signature of the execution license and the context matching can the corresponding high-privilege exit operation be executed. This achieves strict authorization control of high-privilege exit operation. Only the person who physically holds the physical key can obtain legitimate execution authority, effectively preventing the execution license from being forged, tampered with, or abused across scenarios. Attached Figure Description

[0019] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 This is a flowchart of the method in Example 1; Figure 2This is a system structure block diagram of Example 2. Figure 3 This is a basic structural block diagram of the computer device in Example 3. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0022] Example 1 like Figure 1 As shown in the figure, this embodiment proposes a method for managing a minor's mobile terminal, including the following steps: S100: The parent reads the physical root credential key and submits the public key information corresponding to the physical root credential key to the cloud hosting service to create a family hosting root. The cloud only stores the public key, key identifier, and family root association, and does not store the private key. The physical root credential key has a built-in security chip, and the private key is stored inside the security chip and cannot be exported. The hardware form of the physical root credential key includes an NFC key with a security chip, a dynamic NFC security key, a FIDO security key, or customized security hardware. Ordinary NFC fixed UID is only used for auxiliary identification and does not constitute a secure trust root.

[0023] Step S100 involves the parent end reading the physical root credential key and submitting the corresponding public key to the cloud, creating a family care root uniquely bound to the physical key. This migrates the root credential of the family care relationship from the software level to physical hardware, establishing a hardware-level trust anchor for the entire care system. The cloud only retains the association between the public key, key identifier, and family care root, without storing any private key information, thus eliminating the risk of cloud key leakage from an architectural perspective. The physical root credential key uses a security chip as its core carrier, with the private key stored in a closed and non-exportable manner. It supports various forms such as NFC keys with security chips, dynamic NFC security keys, FIDO security keys, and customized security hardware. It clarifies that ordinary NFC fixed UIDs are only used for auxiliary identification and do not constitute a secure trust root, fundamentally eliminating the security deficiencies of pure software account systems and ordinary hardware tags, forming an irreplaceable hardware trust foundation. This ensures that each family care group has a unique corresponding physical entity as its identity root, avoiding the risk of account theft and password cracking leading to tampering of the care relationship in pure software systems.

[0024] S200: The child terminal obtains the family care root identifier through a preset method, reads the same entity root credential key, and joins the family care group corresponding to the family care root after passing the challenge response verification, and enters the care status. The preset method includes QR code, invitation code, family code or near field transmission.

[0025] Step S200 requires the child to first obtain the target family care root identifier through preset methods such as QR code, invitation code, family code, or near-field transmission. Then, after reading the same physical root credential key and passing the challenge response verification, the child can join the family care group. This establishes a dual verification process of "target location + hardware authorization" during the care relationship establishment stage. This design introduces hardware-level identity verification during the care binding process, completing the legal binding of the child's device to the family care root. This ensures that only a legal guardian holding a physical key can include the device in the care system, preventing children from registering, binding, or joining other family groups to bypass control. Furthermore, it uses a challenge response mechanism instead of fixed code value comparison, avoiding the problem of illegal device binding after the traditional NFC card UID or pre-stored code value is copied. It should be noted that QR codes, invitation codes, family codes, or near-field transmission are only used for the family care root and cannot replace the physical key challenge response.

[0026] When the child is under supervision, the S300 monitors preset high-privilege exit operations in real time. When a high-privilege exit operation is detected, the corresponding blocking process is executed according to the terminal system permission level. Under high-privilege, the execution of the operation is directly blocked. Under normal permissions, the in-application operation entry is intercepted, a verification prompt is displayed, the operation behavior is recorded, and an alarm is sent to the guardian.

[0027] Step S300 monitors preset high-privilege exit operations in real time on the child's device while in a supervised state, and performs tiered blocking based on the terminal system permission level. This proactively intercepts all high-risk behaviors that might bypass the supervised system, establishing the first line of defense. In advanced permission modes such as device management, the execution process of high-privilege operations can be directly terminated; in normal system permission modes, effective interception and risk warning are achieved by blocking in-application operation entry points, displaying mandatory verification prompts, recording operation behavior, and alerting the guardian. This design ensures that core bypass behaviors are controlled at the initiation stage, avoiding the passive situation of tracing back after the operation is completed, and creating the necessary prerequisites for the subsequent physical key verification process.

[0028] S400: For blocked high-privilege exit operations, generate a one-time challenge uniquely bound to the context of this operation.

[0029] Step S400 generates a one-time challenge uniquely bound to the context of each blocked high-privilege exit operation. This generates a unique verification input for each high-privilege operation, deeply binding the verification process with contextual information such as the time, device, and type of the specific operation. This completely solves the core flaw in existing technologies where fixed identifiers are easily copied and replay attacks, ensuring that each verification is only valid for the specific operation. Even if the signature is intercepted, it cannot be used for other operations or reused at other times, significantly improving the security of the verification mechanism.

[0030] S500: The one-time challenge is transmitted to the entity root credential key through the communication channel, and the entity root credential key uses a non-exportable private key to sign the one-time challenge to generate an operation signature.

[0031] In step S500, the one-time challenge is transmitted to the physical root credential key via a communication channel. The internal security chip uses a non-exportable private key to complete the signature generation operation. The core identity authentication operation is completed using a hardware security module. The storage and use of the private key are completely isolated inside the security chip. The private key will never leave the physical key's security chip in plaintext form and cannot be cracked, extracted, or copied. This ensures the authenticity and non-forgeability of the signature at the hardware level. At the same time, communication methods such as NFC, USB, and BLE are only used as data transmission channels and do not participate in the core logic of identity verification, thus avoiding security vulnerabilities in the transmission process.

[0032] S600. Verify the operation signature. After successful verification, generate an execution license that is only applicable to this high-privilege exit operation. The execution license is signed by the cloud hosting service using a cloud private key. The license content is bound to at least the operation unique identifier, child device identifier, family hosting root identifier, operation type, effective time, expiration time, and allowed execution times.

[0033] Step S600 verifies the operation signature. Upon successful verification, an execution license is generated that applies only to this high-privilege exit operation. This completes the final identity verification and issues a limited authorization credential, enabling precise authorization of high-privilege operations. The execution license is signed using a cloud-based private key, ensuring from the source that the license itself is unforgeable and tamper-proof. The license content is bound to seven core dimensions: a unique operation identifier, a child device identifier, a family care root identifier, an operation type, an effective date, an expiration date, and the allowed number of executions. This establishes a strict authorization control mechanism, ensuring that only operations with a valid physical key and a valid signature can obtain execution permissions. This prevents the abuse, expansion, or cross-scenario reuse of authorization. Furthermore, unified cloud-based signature verification and license issuance ensure the traceability and manageability of all high-privilege operations.

[0034] S700: The child terminal verifies the legality of the cloud signature of the execution license and verifies that the license content matches the current operation context. After all verifications pass, the corresponding high-privilege exit operation is executed.

[0035] Step S700 first verifies the legality of the cloud signature of the execution license on the child client, then verifies that the license content completely matches the current operation context. Only after all verifications pass will the corresponding high-privilege exit operation be executed, serving as the final checkpoint in the entire verification process. This step ensures that only legal, valid, and tamper-proof authorizations can trigger actual operation execution, forming a complete closed-loop verification system. Even if the execution license is tampered with or forged during cloud transmission, the signature verification and context verification on the child client can both identify and refuse execution, further enhancing the overall security of the system. At the same time, it ensures that the execution of high-privilege operations fully complies with the authorized scope, preventing unauthorized operations from occurring.

[0036] In this embodiment, the child's device joining the family care group via challenge response verification in step S200 is specifically as follows: The child device obtains the family care root identifier through a preset method, generates a binding challenge containing the child's device identifier, the family care root identifier, and a random number, and sends it to the entity root credential key. The entity root credential key uses its internal private key to sign the binding challenge, generates a binding signature, and returns it to the child device. The child device submits the family care root identifier, the binding signature, the device identifier, and the child's account information to the cloud care service. After verifying the validity of the family care root identifier, the cloud care service uses the public key corresponding to the family care root to verify the binding signature. Once the verification is successful, the child's device is added to the family care group.

[0037] The specific process by which the child joins the family care group through challenge response verification is as follows: After the child application is installed and launched, it first obtains the target family care root identifier through preset methods such as QR code scanning, entering an invitation code or family code or near-field transmission. Then, it enters the family care guidance interface, prompting the user to bring the physical root certificate key close to the corresponding communication area of ​​the device (taking the NFC sensing area as an example, depending on the physical key hardware form, it can be adapted to BLE, USB and other communication methods).

[0038] The child device generates unique binding challenge data for this binding operation. The data includes: the child device's unique hardware identifier, the current system timestamp, a 128-bit true random number, and the binding operation type code.

[0039] The child sends the binding challenge data to the physical root credential key through the corresponding communication channel, and at the same time, the interface prompts the user to press the physical key confirmation button to complete the binding.

[0040] After receiving the binding challenge data, the entity root credential key enters a pending confirmation state, waiting for the user to perform a physical press operation; if no user confirmation is received within 15 seconds, the challenge data is automatically discarded and a timeout error is returned.

[0041] After the user presses the physical confirmation button on the physical key, the security chip inside the physical key uses a pre-stored, non-exportable private key to perform an ECDSA-SHA256 signature on the binding challenge data, generating a binding signature.

[0042] The entity root credential key returns the bound signature, its own unique identifier, and the monotonically increasing signature counter value to the child node.

[0043] The child's device will package the binding signature, the child's unique device identifier, the child's account ID, the physical key identifier, the signature counter value, and the original binding challenge into a binding request and send it to the cloud hosting service.

[0044] After receiving the binding request, the cloud hosting service first verifies the legality and validity of the home hosting root identifier, and then queries the corresponding home hosting root record and public key information based on the physical key identifier to check whether the home hosting root is in a normal and valid state.

[0045] The cloud-based hosting service uses the queried public key to verify the binding signature, and also verifies: whether the timestamp in the binding challenge is within the 5-minute validity period, whether the signature counter value is greater than the counter value of the last time the key was used, and whether the child's device has been bound to another family hosting group.

[0046] Once all verification items pass, the cloud-based hosting service will add the child's device to the family hosting group, generate a unique device hosting certificate, and simultaneously distribute the initial hosting policy pre-set by the parents.

[0047] The cloud-based hosting service sends a notification to the parents' app that the child's device has been successfully bound, including information such as the device model and the binding time.

[0048] After receiving the device hosting credentials and initial policy, the child device automatically applies for and activates device management permissions, enables application anti-uninstall protection and core restriction functions, and officially enters the hosted state.

[0049] If any verification item fails, the cloud hosting service will reject the binding request and return the corresponding error message to the child device; after three consecutive binding failures, the device will be restricted from initiating a binding request again for one hour.

[0050] Existing technologies typically use fixed UIDs or pre-stored code values ​​on NFC cards for authentication, achieving only simple identity comparison and failing to establish a reliable secure root of trust, making them vulnerable to copying and replay. In this embodiment, each binding operation generates a unique dynamic challenge containing a device identifier, timestamp, and random number. Even if communication data is intercepted, it cannot be used for binding operations on other devices or at other times, fundamentally solving the problem of fixed identifiers being easily cracked. All signature calculations are performed within the secure chip of the physical key; the private key never leaves the chip in any form and cannot be read, extracted, or copied by external devices. Even if the physical key is lost, attackers cannot obtain the private key information, nor can they forge a legitimate binding signature, achieving true hardware-level identity security. The binding process requires the user to manually press the confirmation button on the physical key to continue, ensuring that only the person actually holding the physical key can complete the binding operation. This design eliminates the possibility of children binding devices themselves without a physical key through remote control, software simulation, or other means.

[0051] In this embodiment, step 400, which involves generating a one-time challenge for the blocked high-privilege exit operation, specifically includes: After the child device detects and blocks a high-privilege exit operation, it generates a unique operation identifier, operation type, child device identifier, local random number, current hosting policy version number, and operation trigger source. It then submits the above information and the family hosting root identifier to the cloud hosting service to request the generation of a one-time challenge. The cloud hosting service verifies the hosting status of the child device and the validity of the physical root credential key. If the verification is successful, it generates a cloud random number and an expiration time. After standardizing and encoding the fields of family hosting root identifier, child device identifier, unique operation identifier, operation type, hosting policy version number, local random number, cloud random number, expiration time, and operation trigger source, it calculates a digest to generate the one-time challenge.

[0052] The specific execution process for generating a one-time challenge for the blocked high-privilege exit operation is as follows: After the child device completes the high-privilege exit operation blocking, the verification process is immediately initialized, generating a 32-bit UUID format operation unique identifier. This identifier is unique across the entire system and is used to mark the entire lifecycle of this high-privilege operation. At the same time, a 128-bit true random number is generated as a local random number, and the device's hardware unique identifier, the operation type code (e.g., 0x01 represents uninstalling the application, 0x02 represents unmanaging), the currently effective managed policy version number, and the trigger source of this operation (e.g., user-initiated trigger, system detection trigger, third-party application trigger) are read.

[0053] The child client packages the generated operation unique identifier, operation type code, device hardware identifier, local random number, hosting policy version number, operation trigger source, and locally stored home hosting root identifier into a challenge generation request, and sends it to the cloud hosting service through an HTTPS encrypted channel.

[0054] Upon receiving a request, the cloud hosting service first performs a preliminary status check: it checks whether the corresponding family group exists and is in a normal state based on the family hosting root identifier; it verifies whether the device truly belongs to the family hosting group and is currently under hosting based on the device hardware identifier; and it checks whether the corresponding physical root credential key has been invalidated, reported lost, or frozen based on the family hosting root identifier.

[0055] If any of the pre-verifications fails, the cloud will immediately return the corresponding error code (e.g., 403 for unmanaged device, 401 for expired key) and terminate the challenge generation process. Devices that fail verifications five times in a row will be restricted from initiating challenge generation requests again for 10 minutes.

[0056] After all pre-verifications pass, a 256-bit true random number is generated in the cloud as the cloud random number. The expiration time of this challenge is set to the current time plus 30 seconds. At the same time, the IP address, device model, generation timestamp and other information of this request are recorded to generate a risk flag bit for backend risk control and traceability (not involved in challenge summary calculation).

[0057] The cloud platform standardizes the encoding of nine fields—family care root identifier, child device identifier, operation unique identifier, operation type code, care strategy version number, local random number, cloud random number, expiration time, and operation trigger source—in accordance with the CBOR format, ensuring that the encoding results generated by different devices and systems are completely consistent.

[0058] The cloud performs a SHA-256 hash operation on the standardized encoded data to generate a 32-byte challenge digest, which is the one-time challenge for this operation.

[0059] The cloud will return the one-time challenge, expiration time, and cloud-based random number to the child's device. At the same time, it will record all field information of this challenge and risk control assistance information in the cloud database and mark the challenge status as pending verification.

[0060] When the child's device is not connected to the network, a local offline challenge generation mechanism is used, and the specific execution process is as follows: After the child device detects and blocks a high-privilege exit operation, it checks the network connection status. If it confirms there is no network, it starts the offline challenge generation process.

[0061] The child device reads the family hosting root identifier, the current hosting policy version number, and the local offline counter value from the local secure storage area, and generates an operation unique identifier, operation type code, device hardware identifier, and a 128-bit local random number.

[0062] The child device normalizes and encodes all the above fields, calculates the SHA-256 digest, generates a local one-time challenge, increments the offline counter value by 1, and updates it to local secure storage.

[0063] Challenges generated offline can only be used to enter the pending confirmation state for exit applications and cannot directly trigger the termination of managed services or the uninstallation of applications.

[0064] After the child's device regains its network connection, it automatically uploads the offline operation records, local challenges, and subsequently generated signature data to the cloud for verification. Only after the verification is successful will the corresponding high-privilege exit operation be executed.

[0065] Most existing technologies rely solely on locally generated random numbers for challenges, making them vulnerable to tampering or prediction by local malicious programs. In this embodiment, the one-time challenge is generated jointly by local random numbers on the child's device and random numbers from the cloud. Neither party can unilaterally determine the challenge content, fundamentally eliminating the possibility of local tampering or prediction of the challenge value, significantly improving the challenge's unpredictability. The generated one-time challenge not only includes a random number but also binds all contextual information related to the current operation, such as a unique operation identifier, family hosting root, device identifier, operation type, and policy version. This further refines the challenge's binding dimensions; even with the same device and operation type, different trigger sources will generate completely different challenges. This means that any change in any parameter will result in a completely different challenge. Even if a signature is intercepted, it cannot be used for verification on other devices, for other operations, or at other times, completely solving the problem of fixed identifiers and simple challenges being easily replayable. It also provides a basis for subsequent operation tracing and risk assessment. Before generating the challenge, the cloud verifies the device hosting status and the validity of the physical key. Only devices in a normal hosting state with a valid corresponding key can obtain a legitimate challenge. This design avoids the challenge of generating invalid or deactivated keys, reducing unnecessary computations in the cloud, preventing attackers from consuming system resources through a large number of malicious requests, and intercepting illegal verification requests in advance.

[0066] In this embodiment, step S600, which involves verifying the operation signature, specifically includes: The cloud-based hosting service queries the corresponding public key and the previously stored signature counter value locally based on the family hosting root identifier. It does not accept the challenge plaintext data returned by the child's end, independently reconstructs the one-time challenge based on the original challenge fields stored locally, checks that the one-time challenge has not expired and that the operation unique identifier has not been used, verifies the operation signature using the public key, and verifies that the current signature counter value is greater than the previous signature counter value to resist key cloning and replay attacks. After all verifications pass, the execution license is generated. When replacing the physical root certificate key, the original physical root certificate key must be present and complete the signature verification. After the verification is successful, the new key will be bound and the old key will be invalidated. If the original physical root certificate key is lost, the identity of the parent will be confirmed through a multi-factor secondary verification process that includes account real-name authentication verification, guardian's bound mobile phone number verification, and facial recognition verification, or customer service manual verification of identity materials and offline valid identity certificate review. Only after the identity is confirmed can the new key be bound and the original key be invalidated. After the old key is invalidated, the cloud hosting service will reject all signature verification requests.

[0067] The specific execution process by which the cloud-hosted service verifies the operation signature and generates an execution license is as follows: On the child's end, the family care root identifier, operation unique identifier, physical key identifier, operation signature, and current signature counter value are packaged into a signature verification request and sent to the signature verification interface of the cloud care service through an HTTPS encrypted channel.

[0068] After receiving the request, the cloud-based signature verification interface first performs format validation on the request parameters to ensure that all required fields are complete and in the correct format. If any parameters are missing or incorrectly formatted, it will directly return a parameter error message and terminate the process.

[0069] Based on the home hosting root identifier and the physical key identifier, the cloud retrieves the corresponding public key information, the last signature counter value, and the current status of the physical key (normal / lost / frozen / invalid) from the encrypted database.

[0070] If the physical key is found to be lost, frozen, or invalid, an invalid key error will be returned immediately, and the IP address, device model, and timestamp of this abnormal signature verification request will be recorded. At the same time, an alert notification of invalid key attempt to verify signature will be pushed to the parent's device.

[0071] Based on the unique identifier of the operation, the cloud retrieves the core original fields corresponding to this operation from the challenge record table, including operation type, device hardware identifier, local random number, cloud random number, expiration time, managed policy version number, and operation trigger source; the generated timestamp, risk flag, and other risk control auxiliary fields are only used for traceability and do not participate in the challenge reconstruction calculation.

[0072] The cloud platform standardizes and encodes the above nine core fields in the same CBOR format as the challenge generation stage, and then recalculates the challenge digest using the SHA-256 hash algorithm, thus completing the independent reconstruction of the one-time challenge.

[0073] The cloud performs the first set of validity checks: compare the current system time with the challenge's expiration time; if the current time has exceeded the expiration time, return an error indicating that the challenge has expired; check whether the status corresponding to the operation's unique identifier is pending verification; if it has been marked as used or invalid, return an error indicating that the operation has expired.

[0074] After the first check passes, the cloud uses the retrieved public key to perform an ECDSA-SHA256 signature verification operation on the operation signature to verify its authenticity and integrity. If the verification fails, an invalid signature error is returned and recorded as a verification failure.

[0075] After the signature verification is successful, the cloud performs the second set of security checks: compare the current signature counter value with the previous signature counter value recorded in the database. If the current counter value is less than or equal to the previous value, it is determined that there is a risk of cloning keys or replay attacks. The counter error is returned immediately, the physical key is marked as suspicious, and a high-priority warning notification is pushed to the parent device.

[0076] After all checks are passed, the cloud generates an execution license for this operation. The execution license includes the following fields: unique operation identifier, device hardware identifier, operation type code, license validity period (current time plus 60 seconds), number of allowed executions (fixed to 1 time), and cloud signature.

[0077] Update database records in the cloud: Change the status of the operation's unique identifier to verified, update the previous signature counter value of the physical key to the current value, and record a complete log of this successful signature verification.

[0078] The cloud will return the generated execution license to the child's device, completing the entire verification process.

[0079] Entity root certificate key change execution process: When changing the physical root credential key, the parent initiates a change request and submits the public key and identifier of the new key. The cloud generates a unique change challenge and distributes it. After the original physical root credential key completes the signature verification of the challenge, the cloud verifies that the original key status is normal and the signature is valid. After the verification is passed, the new key is bound to the database and the old key is marked as invalid, and the association relationship of the family custody root is updated synchronously.

[0080] When the original physical root certificate key is lost, the parent's account initiates a replacement application. The cloud triggers a second verification of the parent's identity (multi-factor authentication) or transfers the process to manual review. Only after the identity is confirmed can a new physical root certificate key be bound and the original key be marked as permanently invalid. After the old key is invalidated, the cloud will directly reject all verification requests for it and it cannot be restored for use.

[0081] Anomaly Handling Mechanism: If the same device fails to verify signature 3 times consecutively, it will be restricted from initiating any high-privilege operation requests for 1 hour; if the same physical key accumulates 5 counter anomalies, it will be automatically frozen and needs to be manually unfrozen by the parent after identity verification.

[0082] Most existing technologies directly use challenge data uploaded by the terminal for signature verification, which is easily tampered with by local malicious programs to forge signatures and pass verification. In this embodiment, the cloud does not rely on any challenge data transmitted by the child terminal, but independently reconstructs the challenge by retrieving the original core fields from the local database based on the unique operation identifier, fundamentally eliminating the possibility of challenge tampering and ensuring the absolute authenticity of the basic signature verification data. Ordinary challenge response mechanisms cannot prevent the risk of physical keys being cloned. Cloned keys can use the same private key to forge legitimate signatures. This embodiment introduces a monotonically increasing counter inside the physical key. The counter automatically increments by 1 after each signature, and the cloud persistently saves the historical value of the counter and strictly verifies that the current value must be greater than the previously recorded value. Cloned keys cannot synchronize the counter state of the original key. Once the original key has been used, the counter of the cloned key will permanently lag behind and fail cloud verification, effectively preventing the mass forgery of signatures after the physical key is cloned.

[0083] Meanwhile, this embodiment establishes a complete physical key lifecycle management mechanism. Normal key replacement requires the original key hardware signature for authorization, and replacement of lost keys requires strong identity verification. All signature verification requests for invalid keys are blocked. This not only solves the pain point of legal changes after physical keys are damaged or lost, but also avoids the security risk of keys being misused by others after they are lost, ensuring the safety and controllability of the entire home care root.

[0084] In this embodiment, the generation in step S600 is only applicable to the execution permit of this high-privilege exit operation. The number of times the execution permit can be executed is fixed to 1, and the validity period is matched with different validity periods according to the risk level of the high-privilege exit operation. After the child terminal verifies the legality of the cloud signature of the execution permit, it further verifies that the operation unique identifier, child device identifier, family care root identifier, and operation type all correspond one-to-one with the current operation, and the current time is within the effective time and expiration time range. The corresponding high-privilege exit operation is executed only after all verifications pass.

[0085] The complete process of generating an execution license that applies only to this high-privilege exit operation and is then executed by the child client within the defined scope is as follows: After completing all signature verification and security checks in the cloud, a structured execution license data packet is generated, containing the following required fields: License Unique ID, Operation Unique Identifier, Device Hardware Identifier, Operation Type Code, License Effective Date, License Expiration Date, Number of Executions Allowed (fixed to 1 time), and Cloud Signature. The Cloud Signature is generated by signing all fields except the Cloud Signature field using the cloud private key.

[0086] The cloud will return the execution license data packet to the child device through an HTTPS encrypted channel, and at the same time record all field information of the license and its status as pending execution in the cloud database.

[0087] After receiving the execution permission, the child application first temporarily stores it in the application's memory, without writing it to any local persistent storage area, to prevent it from being read or tampered with by malicious programs.

[0088] The child device extracts the cloud signature from the license data packet and verifies the signature using a pre-built-in cloud public key to confirm that the license data packet has not been tampered with or forged during transmission. If signature verification fails, the license is immediately discarded and an invalid authorization message is displayed, requesting re-verification.

[0089] After the signature verification is successful, the child device performs multi-dimensional condition validation: Compare the home hosting root identifier in the license with the locally bound home hosting root identifier; if they do not match, refuse to execute. Compare the device hardware identifier in the license with the actual hardware identifier of the local device; if they do not match, refuse to execute. Compare the operation type code in the license with the type of high-privilege operation to be executed; if they do not match, refuse to execute. Compare the unique operation identifier in the license with the unique operation identifier in this application; if they do not match, execution will be rejected. Check if the current system time is between the license's effective and expiration dates; if it is outside this range, refuse to execute. Check if the allowed number of executions is 1; if not, refuse to execute.

[0090] Only after all condition checks pass will the child client execute the corresponding high-privilege exit operation. During the operation, the child client will monitor the execution status in real time to ensure that the operation is completed as expected.

[0091] Once the operation is complete, the child device immediately and completely removes the execution license data packet from memory and reports the successful execution status to the cloud. Upon receiving the report, the cloud updates the license status to "executed" and updates the device's managed status.

[0092] If an anomaly occurs during operation (such as system permissions being occupied or a sudden device restart), the child device immediately clears the permission data packet from memory and reports the operation failure to the cloud. The cloud updates the permission status to expired, and the user needs to re-initiate a high-privilege operation request and complete the full verification process.

[0093] For different types of high-privilege exit operations, the cloud will generate execution licenses with differentiated validity periods based on the operation's risk level, ensuring both security and user experience. Specifically: For quick operations such as uninstalling child apps or disabling device management permissions, the permission validity period is set to 30 seconds.

[0094] For operations that require syncing cloud data and clearing local configurations, such as removing managed status or unbinding parent accounts, the license validity period is set to 60 seconds.

[0095] For operations with a wide impact, such as resetting the family care group or invalidating the family root certificate, the permission validity period is set to 45 seconds, and a secondary confirmation prompt will pop up on the child's device before execution. The operation will only be executed after confirmation.

[0096] Existing authorization credentials typically only bind to the operation type and lack reliable anti-counterfeiting mechanisms, making them susceptible to forgery, tampering, or abuse across devices and operations. In this embodiment, the execution license is signed using a cloud-based private key, ensuring from the source that the license itself is unforgeable and untamperable. Simultaneously, the execution license is strongly bound to six dimensions: home hosting root identifier, device hardware identifier, unique operation identifier, operation type, validity period, and execution count. If any dimension does not match, the operation cannot be executed. This means that even if the license is intercepted during transmission, attackers cannot use it in other homes, on other devices, for other operations, or at other times, fundamentally avoiding the risks of forgery, tampering, and abuse of authorization credentials across scenarios.

[0097] In this embodiment, the preset high-privilege exit operation in step S300 includes at least one of the following: uninstalling the child application, unbinding the parent account, removing the childcare status, disabling device management permissions, disabling core restriction policies, resetting the family childcare group, invalidating the family root credential, switching the child's identity to the parent's identity, clearing the child application data, forcibly stopping the child application, disabling accessibility service permissions, disabling usage access permissions, disabling network filtering functions, disabling notification permissions and background running permissions, modifying the system time, and triggering a factory reset attempt.

[0098] The high-privilege exit operation preset in this plan refers to any operation that could cause the child to escape the care management, weaken the system's restrictive capabilities, or damage the integrity of the family care relationship. The specific categories and system detection and blocking methods are as follows: 1. Core Exit Operations Uninstalling child apps: In Android device management mode, app uninstallation can be directly prohibited; in normal permission mode, the in-app uninstallation-related entry point is intercepted and a verification prompt is displayed. In iOS, app control restrictions are enforced through the FamilyControls or ManagedSettings framework. When high-permission changes are involved, physical key verification is triggered in the app's foreground and recorded in the cloud.

[0099] Switching the child client to the parent client identity: This refers to switching the child client to the parent client's management identity through local configuration tampering, identity forgery, or other methods, directly gaining access to modify management rules. The system intercepts all local identity switching attempts, immediately blocking any unauthorized attempts and requiring physical key verification before proceeding.

[0100] Cancel childcare status: This refers to a request initiated by the child to leave the family childcare group. The system blocks all local exit attempts and only allows execution after the physical key verification is successful.

[0101] Unbind Parent Account: This refers to removing the child's device from a specific parent account. This operation will prevent parents from continuing to monitor and manage the child's device, therefore physical key verification is required.

[0102] Disabling Device Management Permissions: In the Android system, child apps obtain device management permissions through DevicePolicyManager to prevent uninstallation and restrict app usage, employing differentiated control strategies based on permission levels. In DeviceOwner controlled device mode, it possesses deep system-level control capabilities, directly preventing users from disabling device management permissions in system settings, locking the permission status from the ground up. In normal DeviceAdmin mode, it cannot forcibly prevent users from disabling permissions; when it detects a user attempting to disable the permission in system settings, it immediately redirects to a verification interface and displays a risk warning to raise the operational threshold. If the permission is ultimately disabled, an alert notification is immediately pushed to the parent's device, and the entire operation is recorded.

[0103] 2. Restriction and weakening operations Disabling core restriction policies: This refers to disabling core control functions such as application usage time limits, content filtering, and screen locking. The system blocks all local access points for disabling core policies, allowing parents to remotely adjust them or disable them after verification via a physical key.

[0104] Clearing application data on the child's end: Clearing application data will result in the loss of local managed configurations and policies, which is equivalent to bypassing control in disguise. The system listens for application data clearing events and intercepts and requires verification before the clearing operation is executed.

[0105] Forcefully stopping the child's application: Forcibly stopping the application will directly interrupt the managed monitoring and policy execution, which is a high-frequency soft bypass method. The system detects forced stopping behavior through process survival monitoring and system broadcast listening. Once detected, a verification prompt will be triggered immediately when the application restarts, and an alarm will be pushed to the parent's device.

[0106] Disabling accessibility service permissions: The child app relies on accessibility services for core capabilities such as application usage monitoring and content filtering. Disabling this permission will cause control failure. The system monitors the accessibility service authorization status in real time, and will immediately display a pop-up notification and require physical key verification when permission is detected to be disabled.

[0107] Disable usage tracking access: This permission is fundamental for application usage time statistics and usage behavior monitoring. Disabling it will cause core control functions to fail. When the system detects that the permission is disabled, it will immediately block the control functions and trigger a verification process.

[0108] Disabling network filtering: Disabling network filtering capabilities such as VPN and DNS filtering bypasses content access restrictions, which is a typical example of weakening control. The system monitors the network filtering service's running status and immediately triggers verification and synchronizes an alarm when it detects that the filtering is disabled.

[0109] Disabling notification and background operation permissions: Disabling notification permissions and restricting background operation will prevent parental approval requests and alert notifications from being delivered properly, and will also interrupt background monitoring. When the system detects that relevant permissions have been disabled, it will immediately display a prompt and require verification before continued use.

[0110] Modifying system time: Tampering with the system time can directly bypass time period restrictions, duration statistics, and other control rules. The system identifies time tampering behavior through network time calibration and local time anomaly detection. Once detected, it immediately corrects the control timing logic and triggers verification.

[0111] 3. System-level bypass operations Triggering a factory reset attempt: A factory reset will erase all data and applications on the device, completely bypassing managed controls. In Android device management mode, a factory reset can be disabled; on regular devices, when a factory reset request is detected, an emergency alert notification is sent to the parent device.

[0112] Reset Family Childcare Group: This refers to disbanding the entire family childcare group, and all linked child devices will be released from control. This operation requires not only physical key verification but also confirmation from all parent accounts.

[0113] Invalidate Family Root Certificate: This refers to marking the physical root certificate key as invalid, thus removing all verification permissions. This operation must be performed by the parent through offline identity verification, and all bound devices will be automatically unmanaged after execution.

[0114] Most existing technologies focus only on uninstalling applications, the most obvious bypass method, neglecting equally effective bypass techniques such as identity overreach, permission severance, process termination, system time manipulation, and network filtering bypass. This embodiment comprehensively addresses all operation types that could lead to management failure, encompassing three main categories: core exit, restriction weakening, and system-level bypass. It forms a complete set of high-privilege exit operations, ensuring that regardless of the method a child attempts to bypass control, verification via a physical key is mandatory, fundamentally plugging the security vulnerabilities of existing technologies. This embodiment categorizes high-privilege exit operations into different risk levels, employing varying verification strengths and handling measures for each level: the most risky core exit and system-level bypass operations utilize the strictest verification process and immediate alert mechanism; for restriction weakening operations, a notification is sent to the parents after successful verification. This differentiated control approach ensures absolute security for critical operations while avoiding excessive control that could disrupt normal use.

[0115] In this embodiment, after step 500, which involves signing the one-time challenge using a non-derivative private key within the entity root credential key, a replay protection verification step is also included: The cloud-hosted service manages the lifecycle of one-time challenges through database transactions or atomic state update mechanisms. It checks whether the same unique identifier or one-time challenge has been used. If it has been used, it refuses to verify the signature. It also refuses expired challenges, duplicate signatures, cross-device signatures, cross-family signatures, and signatures of different operation types. During the signature verification process, the challenge status is changed from atomicity to verification. After the signature verification is completed, it is updated to verified or invalid. This avoids the vulnerability of duplicate verification caused by concurrent requests reusing the same challenge.

[0116] Before verifying the operation signature, the cloud-hosted service must first execute a complete anti-replay verification process. Only after all verification items pass can the signature verification stage begin. The specific execution process is as follows: After receiving the signature verification request from the child's end, the cloud-based signature verification interface first extracts the unique operation identifier, the family care root identifier, the device hardware identifier, the operation type code, and the signature generation timestamp from the request.

[0117] Using the unique identifier of the operation as the key, the cloud-based system queries the challenge status table in the distributed database to retrieve the original record and current status corresponding to the operation.

[0118] Perform one-time use verification: Check if the status corresponding to the unique identifier of this operation is pending verification. If the status is verified or invalid, it means that the challenge has been used or expired. Immediately return an error message indicating that the operation has expired and record it as a suspected replay attack.

[0119] Execution timeliness verification: Compare the current cloud standard time with the expiration time in the challenge record. If the current time has exceeded the expiration time, mark the challenge status as invalid and return an expired error; to solve the problem of time asynchrony between the device and the cloud, a time error of up to ±5 seconds is allowed.

[0120] Perform cross-device verification: Compare the device hardware identifier in the request with the device hardware identifier stored in the challenge record. If they do not match, it means the signature was used on another device, and a device mismatch error is returned.

[0121] Perform cross-family verification: Compare the family hosting root identifier in the request with the family hosting root identifier stored in the challenge record. If they do not match, it means that the signature was used for another family, and a family mismatch error is returned.

[0122] Perform operation type verification: Compare the operation type code in the request with the operation type code stored in the challenge record. If they do not match, it means that the signature was used for other types of operations, and an operation type mismatch error is returned.

[0123] Perform signature verification failure frequency check: Check the signature verification failure records of the unique identifier of this operation. If the same unique identifier fails more than 3 times within 1 minute, immediately mark the challenge status as invalid and freeze the operation, returning an error message that the operation has been restricted.

[0124] After all anti-replay verification items pass, the cloud uses database transactions to atomically change the status of the unique identifier of the operation from "pending verification" to "verifying", ensuring that the same challenge cannot be entered into the signature verification process by multiple concurrent requests at the same time, avoiding duplicate verification vulnerabilities caused by concurrent reuse.

[0125] If subsequent signature verification fails and the freezing threshold is not reached, the cloud will roll back the challenge status to "pending verification" and allow a limited number of retries; if the signature verification is successful, the status will be updated to "verified"; if the challenge expires or the operation is terminated abnormally during the signature verification process, the status will be marked as "invalid" and no further signature verification requests will be accepted.

[0126] Existing anti-replay mechanisms mostly rely on timestamps or simple random numbers, and only verify replay protection through ordinary status fields. This makes them vulnerable to attackers modifying device time or intercepting replay data packets, and they also pose a race condition vulnerability in high-concurrency scenarios. This embodiment generates a system-wide unique operation identifier for each high-privilege operation. The cloud uses database transactions to atomically manage the entire lifecycle of the challenge, ensuring that the same operation identifier can only be verified once, fundamentally eliminating the possibility of replay attacks. It also solves the race condition vulnerability where the same challenge can be reused multiple times under concurrent requests, providing far greater protection than traditional status verification schemes. Ordinary anti-replay mechanisms can only prevent the same signature from being reused, but cannot prevent it from being used on other devices, other homes, or other operations. This embodiment strongly binds the signature to contextual information such as device hardware identifier, home hosting root identifier, and operation type encoding. Verification is rejected if any dimension does not match. This means that even if an attacker obtains a legitimate signature for a device, they cannot use it for other devices, other homes, or other types of high-privilege operations, significantly reducing the attack surface.

[0127] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0128] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0129] Example 2 like Figure 2 As shown, this embodiment proposes a mobile terminal hosting system for minors, including: The family care root creation module allows parents to read the physical root credential key and submit the public key information corresponding to the physical root credential key to the cloud-based care service. This creates a family care root uniquely bound to the physical root credential key. The cloud only stores the association between the public key, key identifier, and family care root, and does not store the private key. The physical root credential key has a built-in security chip, and the private key is stored inside the security chip and cannot be exported. The hardware form of the physical root credential key includes an NFC key with a security chip, a dynamic NFC security key, a FIDO security key, or customized security hardware. Ordinary NFC fixed UIDs are only used for auxiliary identification and do not constitute a secure trust root. The child-side childcare binding module allows the child to obtain the family childcare root identifier through a preset method, read the same entity root credential key, and join the family childcare group corresponding to the family childcare root after passing the challenge response verification, thus entering the childcare state. The preset method includes QR code, invitation code, family code, or near-field transmission. The high-privilege exit operation monitoring and blocking module monitors preset high-privilege exit operations in real time when the child is under supervision. When a high-privilege exit operation is detected, the corresponding blocking process is executed according to the terminal system permission level. Under high-privilege, the execution of the operation is directly blocked. Under normal permissions, the in-app operation entry is intercepted, a verification prompt is popped up, the operation behavior is recorded, and an alarm is sent to the guardian. The blocked operation one-time challenge generation module generates a one-time challenge that is uniquely bound to the context of the blocked high-privilege exit operation. The entity root credential private key signing module transmits the one-time challenge to the entity root credential key through a communication channel. The entity root credential key then uses a non-exportable private key to sign the one-time challenge, generating an operation signature. The signature verification and execution license issuance module verifies the operation signature. After the verification is successful, an execution license is generated that is only applicable to this high-privilege exit operation. The execution license is signed by the cloud hosting service using a cloud private key. The license content is bound to at least the operation unique identifier, child device identifier, family hosting root identifier, operation type, effective time, expiration time, and allowed number of executions. The execution license verification and operation execution module verifies the legality of the cloud signature of the execution license on the child end, and verifies that the license content matches the current operation context. After all verifications pass, the corresponding high-privilege exit operation is executed.

[0130] The mobile terminal hosting system for minors provided in Example 2 can realize all the processes of the mobile terminal hosting method for minors in Example 1. The functions and technical effects of each module in the mobile terminal hosting system for minors correspond to the functions and technical effects of the mobile terminal hosting method for minors in Example 1, and will not be repeated here.

[0131] Example 3 To address the aforementioned technical problems, this embodiment also provides a computer device. Please refer to [link / reference needed] for details. Figure 3 .

[0132] The computer device 3 includes a memory 31, a processor 32, and a network interface 33 that are interconnected via a system bus. It should be noted that only the computer device 3 with components 31-33 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0133] The computer device 3 can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 3 can interact with the user through a keyboard, mouse, remote control, touchpad, or voice control device.

[0134] The memory 31 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 31 may be an internal storage unit of the computer device 3, such as the hard disk or memory of the computer device 3. In other embodiments, the memory 31 may also be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Of course, the memory 31 may include both the internal storage unit and its external storage device of the computer device 3. In this embodiment, the memory 31 is typically used to store the operating system and various application software installed on the computer device 3, such as computer-readable instructions for a method of hosting a mobile terminal for minors. In addition, the memory 31 can also be used to temporarily store various types of data that have been output or will be output.

[0135] In some embodiments, the processor 32 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. The processor 32 is typically used to control the overall operation of the computer device 3. In this embodiment, the processor 32 is used to execute computer-readable instructions stored in the memory 31 or to process data, for example, to execute the computer-readable instructions of the method for hosting a mobile terminal for minors.

[0136] The network interface 33 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 3 and other electronic devices.

[0137] Example 4 This embodiment also provides another implementation method, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the above-described method for hosting a minor's mobile terminal.

[0138] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0139] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for managing a minor's mobile terminal, characterized in that, Includes the following steps: Parents read the physical root credential key and submit the public key information corresponding to the physical root credential key to the cloud hosting service to create a family hosting root. The cloud only stores the public key, key identifier, and family root association, and does not store the private key. The physical root credential key has a built-in security chip, and the private key is stored inside the security chip and cannot be exported. The hardware form of the physical root credential key includes an NFC key with a security chip, a dynamic NFC security key, a FIDO security key, or customized security hardware. Ordinary NFC fixed UID is only used for auxiliary identification and does not constitute a secure trust root. The child obtains the family care root identifier through a preset method, reads the same entity root credential key, and joins the family care group corresponding to the family care root after passing the challenge response verification, and enters the care status. The preset method includes QR code, invitation code, family code or near field transmission. When the child is under supervision, the system monitors preset high-privilege exit operations in real time. When a high-privilege exit operation is detected, the system will perform corresponding blocking actions according to the terminal system permission level. Under high-privilege, the operation will be blocked directly. Under normal-privilege, the system will intercept the in-app operation entry, pop up a verification prompt, record the operation behavior, and send an alarm to the guardian. For blocked high-privilege exit operations, generate a one-time challenge uniquely bound to the context of this operation; The one-time challenge is transmitted to the entity root credential key via a communication channel, and the entity root credential key uses a non-exportable private key to sign the one-time challenge, generating an operation signature. The operation signature is verified. Once the verification is successful, an execution license is generated that is only applicable to this high-privilege exit operation. The execution license is signed by the cloud hosting service using a cloud private key. The license content is bound to at least the operation unique identifier, child device identifier, family hosting root identifier, operation type, effective time, expiration time, and allowed number of executions. The child client verifies the legality of the cloud signature of the execution license and verifies that the license content matches the current operation context. After all verifications pass, the corresponding high-privilege exit operation is executed.

2. The method for hosting a minor's mobile terminal according to claim 1, characterized in that, The child joins the family childcare group through a challenge response verification process, specifically as follows: The child device obtains the family care root identifier through a preset method, generates a binding challenge containing the child's device identifier, the family care root identifier, and a random number, and sends it to the entity root credential key. The entity root credential key uses its internal private key to sign the binding challenge, generates a binding signature, and returns it to the child device. The child device submits the family care root identifier, the binding signature, the device identifier, and the child's account information to the cloud care service. After verifying the validity of the family care root identifier, the cloud care service uses the public key corresponding to the family care root to verify the binding signature. Once the verification is successful, the child's device is added to the family care group.

3. The method for managing a minor's mobile terminal according to claim 1, characterized in that, The specific steps for generating a one-time challenge for blocked high-privilege exit operations are as follows: After the child device detects and blocks a high-privilege exit operation, it generates a unique operation identifier, operation type, child device identifier, local random number, current hosting policy version number, and operation trigger source. It then submits the above information and the family hosting root identifier to the cloud hosting service to request the generation of a one-time challenge. The cloud hosting service verifies the hosting status of the child device and the validity of the physical root credential key. After the verification is successful, it generates a cloud random number and expiration time. The above fields are then standardized and encoded to calculate a digest, thus generating the one-time challenge.

4. The method for hosting a minor's mobile terminal according to claim 1, characterized in that, The verification of the operation signature specifically involves: The cloud-based hosting service queries the corresponding public key and the previously stored signature counter value locally based on the family hosting root identifier. It does not accept the challenge plaintext data returned by the child's end, independently reconstructs the one-time challenge based on the original challenge fields stored locally, checks that the one-time challenge has not expired and that the operation unique identifier has not been used, verifies the operation signature using the public key, and verifies that the current signature counter value is greater than the previous signature counter value to resist key cloning and replay attacks. After all verifications pass, the execution license is generated. When replacing the physical root certificate key, the original physical root certificate key must be present and complete the signature verification. After the verification is successful, the new key will be bound and the old key will be invalidated. If the original physical root certificate key is lost, the identity of the parent will be confirmed through a multi-factor secondary verification process that includes account real-name authentication verification, guardian's bound mobile phone number verification, and facial recognition verification, or customer service manual verification of identity materials and offline valid identity certificate review. Only after the identity is confirmed can the new key be bound and the original key be invalidated. After the old key is invalidated, the cloud hosting service will reject all signature verification requests.

5. The method for hosting a minor's mobile terminal according to claim 1, characterized in that, The generated execution permit is only applicable to this high-privilege exit operation. The number of times the execution permit can be executed is fixed to 1. The validity period is matched with different validity periods according to the risk level of the high-privilege exit operation. After the child verifies the legality of the cloud signature of the execution permit, it further verifies that the operation unique identifier, child device identifier, family care root identifier, and operation type all correspond one-to-one with the current operation, and that the current time is within the effective time and expiration time range. The corresponding high-privilege exit operation is executed only after all verifications pass.

6. The method for hosting a minor's mobile terminal according to claim 1, characterized in that, The preset high-privilege exit operations include at least one of the following: uninstalling the child app, unbinding the parent account, removing the childcare status, disabling device management permissions, disabling core restriction policies, resetting the family childcare group, invalidating the family root credential, switching the child app to the parent app identity, clearing the child app data, forcibly stopping the child app, disabling accessibility service permissions, disabling usage access permissions, disabling network filtering, disabling notification permissions and background running permissions, modifying the system time, and triggering a factory reset attempt.

7. The method for hosting a minor's mobile terminal according to claim 1, characterized in that, Following the step of signing the one-time challenge using a non-exportable private key from within the entity's root credential key, a replay protection verification step is also included: The cloud-hosted service manages the lifecycle of one-time challenges through database transactions or atomic state update mechanisms. It checks whether the same unique identifier or one-time challenge has been used. If it has been used, it refuses to verify the signature. It also refuses expired challenges, duplicate signatures, cross-device signatures, cross-family signatures, and signatures of different operation types. During the signature verification process, the challenge status is atomically changed from pending verification to verification. After the signature verification is completed, it is updated to verified or invalid. This avoids the vulnerability of duplicate verification caused by concurrent requests reusing the same challenge.

8. A mobile terminal hosting system for minors, characterized in that, include: The family care root creation module allows parents to read the physical root credential key and submit the public key information corresponding to the physical root credential key to the cloud care service to create a family care root. The cloud only stores the public key, key identifier, and family root association, and does not store the private key. The physical root credential key has a built-in security chip, and the private key is stored inside the security chip and cannot be exported. The hardware form of the physical root credential key includes an NFC key with a security chip, a dynamic NFC security key, a FIDO security key, or customized security hardware. Ordinary NFC fixed UID is only used for auxiliary identification and does not constitute a secure trust root. The child-side childcare binding module allows the child to obtain the family childcare root identifier through a preset method, read the same entity root credential key, and join the family childcare group corresponding to the family childcare root after passing the challenge response verification, thus entering the childcare state. The preset method includes QR code, invitation code, family code, or near-field transmission. The high-privilege exit operation monitoring and blocking module monitors preset high-privilege exit operations in real time when the child is under supervision. When a high-privilege exit operation is detected, the corresponding blocking process is executed according to the terminal system permission level. Under high-privilege, the execution of the operation is directly blocked. Under normal permissions, the in-app operation entry is intercepted, a verification prompt is popped up, the operation behavior is recorded, and an alarm is sent to the guardian. The blocked operation one-time challenge generation module generates a one-time challenge that is uniquely bound to the context of the blocked high-privilege exit operation. The entity root credential private key signing module transmits the one-time challenge to the entity root credential key through a communication channel. The entity root credential key then uses a non-exportable private key to sign the one-time challenge, generating an operation signature. The signature verification and execution license issuance module verifies the operation signature. After the verification is successful, an execution license is generated that is only applicable to this high-privilege exit operation. The execution license is signed by the cloud hosting service using a cloud private key. The license content is bound to at least the operation unique identifier, child device identifier, family hosting root identifier, operation type, effective time, expiration time, and allowed number of executions. The execution license verification and operation execution module verifies the legality of the cloud signature of the execution license on the child end, and verifies that the license content matches the current operation context. After all verifications pass, the corresponding high-privilege exit operation is executed.

9. A computer device, characterized in that, include A memory that stores computer-readable instructions; A processor that, when executing the computer-readable instructions, implements the steps of a method for hosting a mobile terminal for minors as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of a method for hosting a minor's mobile terminal as described in any one of claims 1 to 7.

Images