Authority management method and system for equipment flash, chip and intelligent terminal

Abstract

The invention discloses an authority management method and system for equipment flashing, a chip and an intelligent terminal.The method comprises the steps that when an authorization mode for equipment flashing is a quick start authorization mode, a boot loader is started; the client application initiates a first authorization authentication request via the first trusted execution environment client interface; the trusted execution environment core driver receives the first authorization authentication request and switches the operating environment of the processor from a common world to a secure world; the trusted operating system receives and analyzes the first authorization authentication request, and schedules an early trusted application to obtain equipment fingerprint information from the first storage partition; when the equipment fingerprint information passes verification, modifying the first authorization mark, and correspondingly modifying the second authorization mark stored in the second storage partition; and the intelligent terminal is switched into the factory mode. According to the method and the device, the original flashing port can be controllably opened, so that the risk of illegal flashing is avoided, and meanwhile, legal flashing operation is guaranteed.

Description

Technical Field

[0001] This application relates to the fields of terminal and electronic technology, and more particularly to a device flashing permission management method and system, chip, and smart terminal. Background Technology

[0002] With the widespread adoption of smart terminals, two diametrically opposed flashing control strategies have emerged in the industry to ensure the system integrity and data security of smart terminals in commercial and industrial applications. (I) Physical blocking, which directly disables the device's native flashing mode. While this strategy effectively prevents illegal flashing, it also blocks all legitimate authorized flashing requests, causing significant inconvenience to production, maintenance, and firmware upgrades. (II) Completely disregarding non-financial devices, retaining full native flashing functionality. While this approach ensures convenient maintenance, it leaves the device in an "unprotected" state after delivery. Anyone with physical access to the device can use publicly available tools to flash it at will, rendering the device manufacturer's security policies and the commercial software ecosystem ineffective.

[0003] Therefore, there is an urgent need for a solution that can both strictly prevent illegal flashing and open temporary channels for legitimate production and maintenance needs, so as to controllably "open" the native flashing port, thereby eliminating the risk of illegal flashing while ensuring legitimate flashing operations. Summary of the Invention

[0004] In view of this, this application discloses a device flashing permission management method and system, chip, and smart terminal that can controllably "open" the native flashing port, thereby eliminating the risk of illegal flashing while ensuring legitimate flashing operations.

[0005] Firstly, this application provides a method for managing permissions during device flashing, including: When the device flashing authorization mode is fast boot authorization mode, the bootloader is started; the bootloader is configured with a first trusted execution environment client interface and a trusted execution environment core driver; The client application initiates the first authorization authentication request through the client interface of the first trusted execution environment; The trusted execution environment core driver receives the first authorization and authentication request and switches the processor's operating environment from the normal world to the secure world; wherein, the normal world is configured to run a general-purpose operating system; the secure world is isolated from the normal world and is configured to execute a trusted execution environment; The trusted operating system receives and parses the first authorization and authentication request, and schedules an early trusted application to obtain device fingerprint information from the first storage partition; When the device fingerprint information is verified, the first authorization flag is modified to switch the smart terminal from commercial mode to factory mode, allowing the flashing operation to be performed.

[0006] Optionally, the permission management method further includes: porting and adapting the first trusted execution environment client interface to the bootloader; the first trusted execution environment client interface is implemented by the trusted execution environment core driver; The interface name and parameter definitions of the first trusted execution environment client interface correspond one-to-one with the preset trusted execution environment client interface standard specification.

[0007] Optionally, the permission management method further includes: packaging at least one early trusted application together with the trusted execution environment operating system code to generate a trusted execution environment image file, and generating a registry corresponding to the at least one early trusted application during the packaging process; During the startup process of the Trusted Execution Environment (TEE) core driver, the TEE image file is loaded into the secure world, and the early trusted application is loaded in the secure world according to the registry.

[0008] Optionally, the permission management method further includes: when the authorization mode for flashing the device is the debug interface authorization mode, after the operating system starts, sending a second authorization authentication request to the system service through the debug bridge daemon; the system service forwards the second authorization authentication request to the client application; The client application sends the second authorization authentication request through the second trusted execution environment client interface; After receiving the second authorization and authentication request, the Trusted Execution Environment (TEX) driver switches the processor's operating environment from the normal world to the secure world and forwards the second authorization and authentication request to the secure world. The trusted operating system receives and parses the second authorization authentication request, and schedules a trusted application to obtain device fingerprint information from the replay protection storage partition.

[0009] Optionally, the permission management method further includes: when modifying the first authorization tag, modifying the second authorization tag stored in the second storage partition accordingly; the security of the first storage partition is higher than that of the second storage partition; When no authorized device is connected, if the first authorization mark and the second authorization mark are detected to be different, the first authorization mark shall be used as the standard and the second authorization mark shall be modified accordingly.

[0010] Optionally, the permission management method further includes: modifying the first authorization flag and correspondingly modifying the second authorization flag stored in the second storage partition when the smart terminal is in flashing mode and before restoring factory settings; thereby switching the smart terminal from the factory mode to the commercial mode.

[0011] Secondly, this application provides a chip including a processor and a communication interface. The communication interface is used to receive a request and transmit the request to the processor, and the processor processes the request, thereby executing the above-mentioned permission management method.

[0012] Thirdly, this application provides a smart terminal, including the aforementioned chip and a memory; the memory stores a computer program, the computer program including instructions, and the instructions are executed by a processor in the chip.

[0013] Fourthly, this application provides a device flashing permission management system, including: An authorized device, connected to the smart terminal described in the third aspect above, is configured to identify the device status of the smart terminal; switch communication methods and authorization modes according to the device status, and send a first authorization authentication request to the smart terminal through a first communication protocol, or send a second authorization authentication request to the smart terminal through a second communication protocol; the authorization modes include a quick start authorization mode and a debug interface authorization mode; The smart terminal is configured to receive the first authorization authentication request or the second authorization authentication request, and report the device fingerprint information obtained from the first storage partition to the server; wherein, the device fingerprint information includes the device public key; the first storage partition stores the device private key and the cloud public key; The server is configured to, upon receiving device fingerprint information reported by the smart terminal, sign the device fingerprint information using a cloud private key to generate a digital signature; the server stores a cloud public key, a cloud private key, and a device public key.

[0014] Optionally, the access control system further includes: the server is also configured to authenticate the identity information of the authorized device, and when the identity information is authenticated, allow the authorized device to send a first authorization authentication request or a second authorization authentication request; The server is also configured to perform a signature operation after recognizing the validity of the device fingerprint information reported by the smart terminal.

[0015] In summary, this application provides a method, system, chip, and smart terminal for managing device flashing permissions, which has the following beneficial effects: 1) When performing a device flashing operation, the flashing request is first authorized and authenticated; the flashing operation is only allowed when the authorization and authentication are successful; this not only effectively prevents illegal flashing behavior and protects the integrity of the device system, but also does not affect the legitimate production and maintenance operations throughout the entire life cycle of the device.

[0016] In addition, the authorization verification is loaded into the bootloader, and the first trusted execution environment client interface and core driver are integrated into the bootloader. This allows the smart terminal to complete the authorization authentication for device flashing through the fast boot authorization mode even when the operating system fails to start normally or the native debugging interface is disabled.

[0017] 2) By porting and adapting the first trusted execution environment (TEE) client interface and its core driver to the bootloader, the device has the authorization and authentication capability for flashing before the operating system kernel is loaded. Simultaneously, by adhering to the pre-defined TEE client interface standard, ensuring a one-to-one correspondence between the client interface name and parameter definitions, not only can security applications developed for the upper-layer operating system be seamlessly migrated to the bootloader stage, greatly improving code reusability and development efficiency, but also achieving consistency in the security service call paradigm throughout the entire lifecycle.

[0018] 3) After the operating system boots up, a second authorization authentication request is initiated using the debug bridge daemon, enabling the smart terminal to complete the authorization process through standard system services during normal operation. This mechanism effectively utilizes the operating system's mature debugging interfaces and system service framework, providing a convenient and flexible authorization channel for scenarios such as device maintenance and software upgrades.

[0019] 4) When modifying the authorization flag in the high-security first storage partition, the corresponding flag stored in the second storage partition is modified simultaneously, ensuring the consistency of security policies between the system's underlying layer and upper-layer applications. More importantly, when no authorization device is connected, the system automatically checks the consistency of the flag states in the two storage partitions and automatically repairs the out-of-sync flags in the second storage partition, using the more secure first authorization flag as a benchmark. This ensures both the immutability of the security policy decision source and the high efficiency of the system's execution of security policies during daily operation, effectively preventing system malfunctions or security vulnerabilities caused by flag asynchrony.

[0020] 5) During the flashing process of a smart terminal, before the factory reset is performed, by simultaneously modifying the first authorization tag and the second authorization tag, not only is the safe and controllable switching from factory mode to commercial mode achieved, but the authorization tags stored at the system's bottom layer and read by the upper layer application are also ensured to be consistent. Attached Figure Description

[0021] The following is a brief introduction to the accompanying drawings used in the description of the embodiments of this application: Figure 1 This is an example diagram of a device flashing permission management system provided in an embodiment of this application.

[0022] Figure 2 This is a flowchart illustrating a device flashing permission management method provided in this application embodiment.

[0023] Figure 3 This is another flowchart illustrating the permission management method for device flashing provided in this application embodiment.

[0024] Figure 4 This is an example diagram of the device flashing permission management method provided in the embodiments of this application.

[0025] Figure 5 This is a flowchart illustrating the authorization and authentication process in the quick-start authorization mode provided in this application embodiment.

[0026] Figure 6 This is a flowchart illustrating the authorization and authentication process under the authorization mode of the debugging interface provided in this application embodiment.

[0027] Figure 7 This is a structural block diagram of the smart terminal provided in the embodiments of this application. Detailed Implementation

[0028] To more clearly illustrate the technical solutions of the embodiments of this application, the specific implementation methods of this application will be described below with reference to the accompanying drawings. The accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without creative effort. Adjustments and improvements made without departing from the concept of this application are all within the protection scope of this application.

[0029] To keep the drawings simple, only the parts related to the corresponding embodiments are shown schematically in each figure, and they do not represent the actual structure of the product. In addition, to make the drawings simple and easy to understand, some parts with the same structure or function are only shown schematically in some figures, and there may actually be more or fewer parts with the same structure or function.

[0030] In this application, unless otherwise expressly specified and limited, ordinal numbers, such as "first," "second," etc., are used only to distinguish and describe related objects, and should not be construed as indicating or implying the relative importance or order between related objects; furthermore, they do not represent the quantity of related objects. "Multiple" includes two or more, and other quantifiers are similar. " / " is used to describe the relationship between related objects, indicating an "or" relationship between them. "And / or" is used to describe the relationship between related objects, including any combination relationship between them, such as "a and / or b" including: "a alone," "b alone," or "a and b." "One or more" or "at least one" of multiple objects refers to any object or any combination of multiple objects, such as "one or more of a1, a2, a3" or "at least one of a1, a2, a3" including: "a1 alone," "a2 alone," "a3 alone," "a1 and a2," "a1 and a3," "a2 and a3," or "a1, a2 and a3."

[0031] With the widespread adoption of smart devices, device security has become a critical issue. Especially in commercial and industrial applications, devices often need to be protected against unauthorized modifications, such as firmware flashing, to ensure system integrity and data security. Unauthorized firmware flashing can lead to risks such as malware infection, leakage of critical business data, tampering with proprietary applications, and devices being removed from a unified management platform. To address this problem, a common approach is to physically block the flashing process by directly disabling the device's native firmware flashing mode.

[0032] However, in the entire lifecycle management of smart terminals, flashing the firmware—that is, rewriting or modifying the device's operating system—is a necessary step in the process of device production, testing, after-sales maintenance, and software upgrades. Completely disabling flashing would lead to problems such as low production efficiency, increased maintenance costs, and a significant shortening of the device's lifecycle.

[0033] Furthermore, many manufacturers do not control the flashing of firmware on non-financial devices, retaining the original flashing functionality entirely. While this approach ensures convenience for production and maintenance, it leaves the devices in a "defenseless" state after delivery to the customer. Anyone with physical access to the device can use publicly available original flashing tools to arbitrarily flash it, completely undermining the security policies set by the device manufacturer and the commercial software ecosystem.

[0034] Therefore, there is an urgent need for a solution that, under the premise that the device has enabled anti-flashing policies for security control, allows the native flashing port to be "opened" in an authorized scenario in a controlled manner, thereby eliminating the risk of illegal flashing while ensuring the smoothness and efficiency of legal flashing operations.

[0035] This application provides a device flashing permission management method, system, chip, and smart terminal. When performing a device flashing operation, the flashing request is first authorized and authenticated; only when the authorization and authentication are successful is the flashing operation allowed. This not only effectively prevents illegal flashing behavior and protects the integrity of the device system, but also does not affect the legitimate production and maintenance operations throughout the entire life cycle of the device.

[0036] The access control system is described below with reference to the accompanying diagram: Figure 1 This is an example diagram of a device flashing permission management system provided in an embodiment of this application. Please refer to it. Figure 1 This application discloses a device flashing permission management system, including: The authorized device is configured to connect to the smart terminal and identify the device status of the smart terminal; it switches the communication method and authorization mode according to the device status, and sends a first authorization authentication request to the smart terminal through a first communication protocol, or sends a second authorization authentication request to the smart terminal through a second communication protocol; its authorization mode includes a quick start authorization mode and a debug interface authorization mode.

[0037] The smart terminal is configured to, upon receiving a first authorization authentication request or a second authorization authentication request, retrieve device fingerprint information from a first storage partition and report the device fingerprint information to a server; wherein, the device fingerprint information includes a device public key; the first storage partition stores a device private key and a cloud public key.

[0038] The server is configured to sign the device fingerprint information reported by the smart terminal using a cloud private key to generate a digital signature; the server stores a cloud public key, a cloud private key, and a device public key.

[0039] The smart terminal is configured to, upon receiving a digital signature, use the cloud public key stored in the first storage partition to verify the digital signature issued by the server; when the verification is successful, the device public key is deemed valid and the device fingerprint information is verified; when the device fingerprint information is verified, the first authorization flag is modified, and the second authorization flag stored in the second storage partition is modified accordingly; this switches the smart terminal from commercial mode to factory mode, allowing the flashing operation to be performed.

[0040] In this embodiment, during the smart terminal production stage, the server collects the device fingerprint information of the smart terminal. The device fingerprint information includes a device random number, CRC checksum, device public key, and expiration time. The server stores a cloud public key and a cloud private key; these are generated on the server, and the cloud private key is always kept secret by the server. The server distributes and stores the device fingerprint information and cloud public key in the first storage partition of the smart terminal. The first storage partition also stores the device public key and device private key; these device public and private keys are randomly generated within the smart terminal's internal security environment (such as a TEE or SE security chip) during initial initialization. After generation, the device serial number is strongly bound to the device public key and sent together to the server for registration.

[0041] After performing a factory reset, the smart terminal enters commercial mode, where its native flashing mode (i.e., factory mode) is disabled by default. The factory reset clears all test data, temporary configurations, and traces of factory mode, ensuring the smart terminal is delivered to the user in a standardized state. Users need to activate the smart terminal upon first use. If a user encounters software upgrades, component replacements, or other issues requiring flashing, they must use an authorization tool (AuthTool) to return the smart terminal to factory mode. This authorization tool is deployed on an authorized device (e.g., a computer) and integrates the ADB (Android Debug Bridge) protocol (the second communication protocol) and the Fastboot protocol (the first communication protocol). AuthTool intelligently identifies the device status, including whether the operating system is running normally or in Fastboot mode, and automatically switches between ADB and Fastboot protocols to ensure a connection with the smart terminal under any circumstances. After launching the authorization tool, it checks for connected smart devices. When a smart device connects to the authorization device via USB cable, the authorization device receives the flashing request from the smart device. The authorization tool does not directly execute the flashing operation; instead, it first authenticates the flashing request. Only after successful authentication will the flashing operation be performed. The authentication process is as follows: The authorized device identifies the current state of the smart terminal. If the smart terminal is detected as being in normal power-on mode, it switches to the ADB protocol and uses the debug interface authorization mode. In debug interface authorization mode, authorization verification is performed through the system debug interface during normal operating system operation. If the smart terminal is detected as being in Fastboot mode, it switches to the Fastboot protocol and uses the fast boot authorization mode. Fast boot authorization mode is activated before the operating system completes boot or when the operating system malfunctions and cannot boot normally. When the authorization mode is identified as debug interface authorization mode, the authorized device sends the first authorization authentication request for flashing operation to the smart terminal via the ADB protocol. When the authorization mode is identified as fast boot authorization mode, the authorized device sends the second authorization authentication request for flashing operation to the smart terminal via the Fastboot protocol.

[0042] The device fingerprint information, including the device public key, is retrieved from the first storage partition of the smart terminal. This fingerprint information is then reported to the server. Upon receiving the fingerprint information, the server signs it using its cloud-based private key to generate a digital signature, which is then sent to the smart terminal. The smart terminal uses the cloud-based public key stored in the first storage partition to verify the digital signature sent by the server. If the verification is successful, the device public key is deemed valid, meaning the device fingerprint information has been verified, thus completing the authorization and authentication of the flashing operation request.

[0043] After obtaining authorization for the flashing operation request, flashing permissions are granted, which involves modifying the first authorization flag and the corresponding second authorization flag. This allows the smart terminal to switch from commercial mode (also known as normal working mode) to factory mode (also known as native flashing mode), permitting the flashing operation. For example, changing the first authorization flag from 1 to 0 allows the smart terminal to enter factory mode; an authorization flag of 0 indicates native flashing mode or factory mode, allowing the flashing operation; an authorization flag of 1 indicates commercial mode or normal working mode, disallowing the flashing operation.

[0044] In one implementation, the server is further configured to perform a signature operation after verifying that the device fingerprint information reported by the smart terminal is legitimate.

[0045] In this embodiment, before the server signs the device fingerprint information using a cloud-based private key to generate a digital signature, it needs to authenticate the smart terminal. This authentication is based on pre-set smart terminal registration information: during the smart terminal's production phase, before restoring factory settings, the smart terminal will report its device public key to the server for registration. In the subsequent authorization and authentication process, the server will compare the received device public key with the registered and stored device public key. If they match, the device fingerprint information is deemed legitimate, and a signature operation is performed on the device fingerprint information. If the device fingerprint information is illegitimate, the signature operation is abandoned. By pre-registering the device public key with the server during the production phase, the server verifies the smart terminal's identity by comparing the received public key with the pre-registered public key, preventing unauthorized access and effectively preventing the terminal's identity from being tampered with or impersonated, ensuring that the object of each authorization operation is unique and trustworthy. When the device fingerprint information includes the device public key, the smart terminal's authorization and authentication includes: comparing the matching of the device public key to verify the legitimacy of the device's identity; and using the pre-stored cloud public key to verify the signature data to ensure the integrity and trustworthiness of the data source. When the device fingerprint information also includes a device random number and expiration time, the authorization and authentication of its smart terminal may also include: checking the validity period of the authorization data to confirm its timeliness; and defending against replay attacks by verifying the device random number.

[0046] In one implementation, the server is further configured to authenticate the identity information of the authorized device, and when the identity information is successfully authenticated, allow the authorized device to send a first authorization authentication request or a second authorization authentication request.

[0047] In this embodiment, to ensure the security and controllability of the authorization tool, account registration and real-name authentication of the authorization tool, as well as the application for authorization counts for flashing tasks, must be completed on the server first. When using AuthTool to perform flashing authorization, the server not only verifies the legitimacy of the account itself, but also checks whether the account has available authorization counts. Only after the authorization tool passes the account legitimacy and authorization count verification can it initiate authorization authentication to the smart terminal. After the terminal authorization authentication is successful, the authorization tool will be granted flashing permissions to perform flashing operations on the smart terminal. At the same time, relevant information for each authorization authentication operation (including device SN, authorization time, operator ID, authorization result, etc.) will be uploaded to the server in real time by the authorized device and stored in an immutable database; all authorization records of any authorized device can be queried through the web backend. The management of the authorization tool and the management of smart terminal authentication are flexible in deployment, and can be deployed centrally on the same server or distributed across different servers; for example: the first server is used for upper-layer business management, providing the authorization tool with account registration and verification, authorization quota allocation, and full-process operation auditing. The second server, acting as the root of trust for the smart terminal's identity, provides services for verifying the authenticity of the smart terminal and issuing authorization credentials through the identification of device fingerprint information and digital signatures.

[0048] The following description, with reference to the accompanying drawings, further describes the permission management method executed by the processor in the smart terminal or chip: In one implementation, please refer to Figure 2 , Figure 4 and Figure 5 This application discloses a method for managing permissions during device flashing, including: S110. When the device flashing authorization mode is fast boot authorization mode, the bootloader is started; the bootloader is configured with the first trusted execution environment client interface and the trusted execution environment core driver.

[0049] S120. The client application initiates the first authorization authentication request through the client interface of the first trusted execution environment.

[0050] S130. The Trusted Execution Environment (TEE) core driver receives the first authorization and authentication request and switches the processor's operating environment from the normal world to the secure world. The normal world is configured to run a general-purpose operating system. The secure world is isolated from the normal world and is configured to execute the TEE.

[0051] S140. The trusted operating system receives and parses the first authorization authentication request, and schedules an early trusted application to obtain device fingerprint information from the first storage partition; wherein, the device fingerprint information includes the device public key; the first storage partition stores the device private key and the cloud public key; S150. When the device fingerprint information passes verification, the first authorization tag is modified to switch the smart terminal from commercial mode to factory mode, allowing the flashing operation to be performed. To facilitate the operating system's accurate reading of the authorization tag, the first authorization tag is mapped and stored in a second storage partition, and the authorization tag in the second storage partition serves as the second authorization tag. When the first authorization tag is modified, the second authorization tag stored in the second storage partition is modified accordingly; the security of the first storage partition is higher than that of the second storage partition.

[0052] In this embodiment, the processor CPU is logically divided into two independent working areas (i.e., the normal world and the secure world), each with its own permissions, accessible resources, and corresponding tasks. For example, the normal world handles general computing tasks, while the secure world handles security-critical tasks. The smart terminal adopts a security architecture with both Android and TEE environments. In this architecture, the Android system is used as the rich execution environment, while a trusted execution environment is built based on the TEE operating system. The rich execution environment is configured in the normal world, and the trusted execution environment is configured in the secure world. The RPMB replay protection memory partition in the storage chip is used as the first storage partition, which stores device fingerprint information. This first storage partition has hardware-level write protection and authentication mechanisms, making it very secure and difficult to tamper with; thus achieving tamper-proof storage and access control of device fingerprint information, authorization tags, encryption keys, etc. The original partition in the same or different storage chips is used as the second storage partition, and the first authorization tag is mapped and stored in the second storage partition. The authorization tag stored in the second storage partition is regarded as the second authorization tag. The second storage partition is the storage location marked "working"; that is, it is stored on a regular partition, which facilitates the system to quickly read and execute policies.

[0053] All write operations on the first and second storage partitions require authentication and permission verification through an authorization tool, and can only be executed after successful authorization. For example, when modifying the authorization flag indicating "disable / enable native flashing tool port", the authorization tool and the security system in the smart terminal must complete authentication before the authorization flag in the first and second storage partitions can be updated synchronously, thereby achieving controlled management of this function port.

[0054] When a smart terminal is in commercial mode and fails to boot normally due to system failure, such as a system crash during the kernel loading phase, the ADB-based authorization tool cannot run due to system service unavailability. Its native flashing mode has been forcibly disabled and cannot be unblocked using ADB-based authorization tools. By pressing a custom button, the smart terminal can be directly booted and enter Bootloader mode.

[0055] When the device is flashed in the Fast Startup authorization mode, the bootloader is started, and the Trusted Execution Environment Core Driver (TEE Core Driver) and the Trusted Operating System (TEE OS) in the secure world are initialized. Early Trusted Applications (Early TA) are loaded into the secure world under the management of the Trusted Application Manager (TAManager). The Trusted Application Manager (TA Manager) and the Early Trusted Application Registry Table (Early TA Registry Table) are responsible for managing early trusted applications during the early startup phase.

[0056] In the Normal World, the Client Application (CA) runs within the Bootloader's address space. It's a task or module within the Bootloader responsible for handling the initial authorization request, sending it to the Secure World via the Trusted Execution Environment (TEE) Client API. The TEE Core Driver is the core driver of the Trusted Execution Environment (TEE) within the Bootloader; it handles calls from the TEE Client API, receives the initial authorization request, and triggers the CPU to switch from the Normal World to the Secure World.

[0057] In the Secure World, an Early Trusted Application (ETA) is a trusted application running in the Secure World before the Linux kernel boots. Upon receiving an authorization and authentication request from the trusted operating system, it invokes the cryptography service and RPMB file system within the trusted operating system to provide authorization and authentication services (i.e., cryptographic services), such as signature verification, for the Early Trusted Application. Its RPMB file system allows the Early Trusted Application to securely access the RPMB file system (corresponding to the first storage partition) early in the boot process, reading and writing hardware-protected authorization tags or device fingerprint information.

[0058] Upon receiving the first authorization authentication request, the Early Trusted Application (Early TA) reads the device fingerprint information from the first storage partition and generates response data containing the device fingerprint information. This response data is then returned to the server via the same communication channel used to receive the first authentication request. Upon receiving a digital signature from the server, the Early TA sends the digital signature to the Early TA via the same communication channel used to send the first authentication request. The Early TA verifies the digital signature by invoking cryptographic operations and the RPMB file system. If the verification passes, the device public key is deemed valid, and the device fingerprint information is verified; modification of the first authorization flag is permitted, allowing the smart terminal to switch from commercial mode to factory mode and enabling flashing operations. After the first authorization flag is modified, the corresponding second authorization flag stored in the second storage partition is modified. If the verification fails, the device public key is deemed invalid, and the device fingerprint information fails verification; modification of the first authorization flag is not permitted, the smart terminal cannot switch from commercial mode to factory mode, and flashing operations are not allowed, thus preventing tampering with the operating system. The above flashing method avoids the need to disassemble the device or upgrade to a special firmware version via OTA when repairing smart terminals. This flashing solution is not only simple to operate and low in cost, but also meets the requirements for operational efficiency and standardized processes in the scenario of batch device modification.

[0059] In one embodiment, this application discloses a permission management method for device flashing, which further includes: porting and adapting a first trusted execution environment client interface to the bootloader; the first trusted execution environment client interface is implemented by a trusted execution environment core driver; The interface name and parameter definitions of the first trusted execution environment client interface correspond one-to-one with the preset trusted execution environment client interface standard specifications.

[0060] In this embodiment, the first Trusted Execution Environment (TEE) client interface is implemented during the bootloader stage. The first TEE client interface differs from the second TEE client interface in Linux / Android environments: all functions of the first TEE client interface are directly provided by the TEE core driver, without relying on upper-layer operating system services; while in Linux / Android systems, the second TEE client interface is implemented in conjunction with the kernel driver. The interface name, parameter types, parameter order, and return value definition of the first TEE client interface maintain a strict one-to-one mapping with the GPTEE Client API specification defined by the GlobalPlatform standards organization. This ensures that applications can obtain the same programming interface when calling trusted services in different execution environments (bootloader and operating system), providing a pathway for secure service calls in the early stages of startup.

[0061] In one embodiment, this application discloses a method for managing permissions during device flashing, which further includes: At least one early trusted application is packaged together with the trusted execution environment operating system code to generate a trusted execution environment image file, and a registry corresponding to at least one early trusted application is generated during the packaging process; During the startup process of the Trusted Execution Environment (TEE) core driver, the TEE image file is loaded into the Secure World, and early trusted applications are loaded in the Secure World based on the registry.

[0062] In this embodiment, at least one early trusted application is directly integrated into the trusted execution environment system image. The early trusted applications are packaged together using the packaging script packimg.py to generate the tee.img image file. During the packaging process, an early trusted application registry is generated, which records the identity, entry address, and resource access permission information of each early trusted application.

[0063] The Trusted Execution Environment (TEE) core driver is ported and adapted to the U-Boot or Little Kernel bootloader runtime environment, enabling the bootloader to access the TEE through standard interfaces. By extending the TEE runtime framework, a communication channel is established between the bootloader and early trusted applications. Specifically, the modified TEE runtime framework allows the device to invoke the corresponding early trusted applications through the TEE core driver during the boot loading phase to perform device authentication, authorization verification, and security policy verification operations, thereby achieving device security status verification and authorization decisions before the operating system kernel is loaded.

[0064] In one implementation, please refer to Figure 3 , Figure 4 and Figure 6 This application discloses a method for managing permissions during device flashing, which also includes: S210. When the device flashing authorization mode is debug interface authorization mode, after the operating system starts, the debug bridge daemon sends a second authorization authentication request to the system service; the system service forwards the second authorization authentication request to the client application. S220. The client application sends a second authorization authentication request through the client interface of the second trusted execution environment. S230. After receiving the second authorization authentication request, the Trusted Execution Environment (TEXE) driver switches the processor's operating environment from the normal world to the secure world and forwards the second authorization authentication request to the secure world. S240: The trusted operating system receives and parses the second authorization authentication request, and schedules the trusted application to obtain device fingerprint information from the first storage partition.

[0065] In this example, when the smart terminal operating system is running normally, the authorized device communicates with the system service (Systool Service / SunmiService) via the ADB protocol. The system-level service acts as a "bridge" between the authorization tool and the underlying security hardware of the smart terminal. The ADB daemon (Adbd) receives the second authorization authentication request sent by the authorization tool and forwards the second authorization authentication request to the system service; the system service forwards the second authorization authentication request to the client application (CA).

[0066] In the normal world, client applications initiate a second authorization authentication request to the Trusted Execution Environment (TEE) driver in kernel space by calling the Second Trusted Execution Environment Client Interface (TEE_Client_API). User-space client applications invoke the TEE driver in kernel space by manipulating the device file ( / dev / teex, file of opt-teee driver) provided by the TEE driver. The TEE driver generates switching instructions, triggering the Monitor Mode, which switches the CPU from the normal world to the secure world. The Monitor Mode serves as the channel for the CPU to switch between the normal and secure worlds.

[0067] In the secure world, the protected first storage partition can be accessed, and the Trusted Operating System (TEEOS) can begin running. The Trusted Operating System sends a second authorization authentication request to the Trusted Application (TA). Upon receiving the second authorization authentication request, the Trusted Application calls the Trusted Execution Environment Internal Interface (TEE_Internal_API) to obtain the device fingerprint information from the first storage partition, generates response data containing the device fingerprint information, and returns the response data to the server through the same communication channel used to receive the second authentication request.

[0068] Upon receiving a digital signature from the server, the device sends the signature to a trusted application through the same communication channel used to send the second authentication request. The trusted application verifies the digital signature. If verification is successful, the device public key is deemed valid, and the device fingerprint information is verified. Modification of the first authorization flag is permitted, allowing the smart terminal to switch from commercial mode to factory mode and enabling a firmware flashing operation. After the first authorization flag is modified, the corresponding second authorization flag stored in the second storage partition is modified. If verification fails, the device public key is deemed invalid, and the device fingerprint information fails verification. Modification of the first authorization flag is not permitted, the smart terminal cannot switch from commercial mode to factory mode, and firmware flashing is not allowed.

[0069] In one embodiment, the access control method further includes: when no authorized device is connected, if a difference is detected between a first authorization tag and a second authorization tag, the first authorization tag shall be used as the standard, and the second authorization tag shall be modified accordingly.

[0070] In this embodiment, when the smart terminal is not connected to an authorized device, the client application checks whether the second authorization tag is consistent with the first authorization tag periodically or when triggered by an external request through the secure sys.io hardware interface; for example, the authorization tag is verified when the smart terminal is powered on. If the second authorization tag is out of sync with the first authorization tag (e.g., the AP-side tag has been tampered with), the first authorization tag is used to overwrite and repair the second authorization tag. The storage of the second authorization tag and the first authorization tag is synchronously detected through the hardware operation interface provided by sys.io; sys.io is an interface that directly interacts with the underlying hardware of the device (such as the storage controller). The client application reads the first authorization tag stored in the first storage partition through sys.io; reads and writes the second authorization tag stored in the second storage partition; and compares and synchronizes the second authorization tag and the first authorization tag to ensure that the second authorization tag and the first authorization tag are consistent.

[0071] In one implementation, the permission management method further includes: modifying the first authorization flag and correspondingly modifying the second authorization flag stored in the second storage partition when the smart terminal is in flashing mode and before restoring factory settings; thereby switching the smart terminal from factory mode to commercial mode.

[0072] In this embodiment, after the smart terminal enters flashing mode and completes system reinstallation or component replacement in factory mode, the updated device fingerprint information of the smart terminal needs to be reported to the server to complete identity re-registration. After storing the device public key, the server modifies the first authorization flag before restoring factory settings, switching the smart terminal from factory mode to commercial mode; and correspondingly modifies the second authorization flag stored in the second storage partition. After receiving the device fingerprint information, the server stores the corresponding device public key for subsequent authorization authentication. Before performing the factory reset operation, it modifies the first authorization flag stored in the first storage partition and simultaneously modifies the second authorization flag stored in the second storage partition to ensure the consistency of the states of the first and second authorization flags, thereby completing the secure switch of the device from the production testing environment to the commercial application environment. Through this embodiment, a secure state migration of the device after a major software update or hardware replacement is achieved, ensuring the legitimacy and security of the smart terminal in the commercial environment.

[0073] In one embodiment, this application discloses a chip including a processor and a communication interface. The communication interface is used to receive requests and transmit the requests to the processor. The processor processes the requests, thereby executing the device flashing permission management method described in the above embodiment.

[0074] In one implementation, such as Figure 7 As shown, Figure 7 This is a structural block diagram of the smart terminal provided in an embodiment of this application. Please refer to it. Figure 7 This application discloses a smart terminal 100, including the aforementioned chip and a memory 120; the memory 120 stores a computer program, which includes instructions that are executed by a processor 110 in the chip. For example, when the computer program runs, it converts user operations or system calls into corresponding request information and transmits it to the processor through the communication interface; the processor receives and parses the request information and executes the operation corresponding to the request to implement the management process of device flashing permissions.

[0075] In this embodiment, the processor is, for example, a general-purpose processor, such as a central processing unit (CPU), and the memory is either internal or external to the device. Alternatively, the above units can be implemented as hardware circuits. The functionality of some or all units can be achieved through the design of the hardware circuits, which can be understood as one or more processors. For example, in some implementations, the hardware circuit is an application-specific integrated circuit (ASIC), which implements the functionality of some or all units by designing the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a programmable logic device (PLD), which can include a large number of logic gates. The logical relationships between the logic gates are configured through a configuration file, thereby achieving the functionality of some or all units. All units of the above device can be implemented entirely through processor-invoked programs, entirely through hardware circuits, or partially through processor-invoked programs with the remaining parts implemented through hardware circuits.

[0076] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not described in detail or in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Furthermore, the above embodiments can be freely combined as needed.

Claims

1. A method for managing permissions during device flashing, characterized in that, include: When the device flashing authorization mode is fast boot authorization mode, start the bootloader; The bootloader is configured with a first trusted execution environment client interface and a trusted execution environment core driver. The client application initiates the first authorization authentication request through the client interface of the first trusted execution environment; The Trusted Execution Environment (TEE) core driver receives the first authorization and authentication request and switches the processor's operating environment from the normal world to the secure world; wherein, the normal world is configured to run a general-purpose operating system; the secure world is isolated from the normal world and is configured to execute the TEE. The trusted operating system receives and parses the first authorization and authentication request, and schedules an early trusted application to obtain device fingerprint information from the first storage partition; When the device fingerprint information is verified, the first authorization flag is modified to switch the smart terminal from commercial mode to factory mode, allowing the flashing operation to be performed.

2. The access control method according to claim 1, characterized in that, Also includes: The first trusted execution environment client interface is ported and adapted to the bootloader; The first trusted execution environment client interface is implemented by the trusted execution environment core driver; The interface name and parameter definitions of the first trusted execution environment client interface correspond one-to-one with the preset trusted execution environment client interface standard specification.

3. The access control method according to claim 1, characterized in that, Also includes: At least one early trusted application is packaged together with the trusted execution environment operating system code to generate a trusted execution environment image file, and a registry corresponding to the at least one early trusted application is generated during the packaging process; During the startup process of the Trusted Execution Environment (TEE) core driver, the TEE image file is loaded into the secure world, and the early trusted application is loaded in the secure world according to the registry.

4. The access control method according to claim 1, characterized in that, Also includes: When the device flashing authorization mode is debug interface authorization mode, after the operating system starts, a second authorization authentication request is sent to the system service through the debug bridge daemon process; The system service forwards the second authorization authentication request to the client application; The client application sends the second authorization authentication request through the second trusted execution environment client interface; After receiving the second authorization and authentication request, the Trusted Execution Environment (TEX) driver switches the processor's operating environment from the normal world to the secure world and forwards the second authorization and authentication request to the secure world. The trusted operating system receives and parses the second authorization authentication request, and schedules a trusted application to obtain device fingerprint information from the replay protection storage partition.

5. The access control method according to any one of claims 1 to 4, characterized in that, Also includes: When modifying the first authorization tag, the second authorization tag stored in the second storage partition is modified accordingly; The security of the first storage partition is higher than that of the second storage partition; When no authorized device is connected, if the first authorization mark and the second authorization mark are detected to be different, the first authorization mark shall be used as the standard and the second authorization mark shall be modified accordingly.

6. The access control method according to claim 5, characterized in that, Also includes: When the smart terminal is in flashing mode and before restoring factory settings, the first authorization flag is modified, and the second authorization flag stored in the second storage partition is modified accordingly. This switches the smart terminal from the factory mode to the commercial mode.

7. A chip, characterized in that, The chip includes a processor and a communication interface, the communication interface being used to receive a request and transmit the request to the processor, the processor processing the request such that the method as described in any one of claims 1 to 6 is executed.

8. A smart terminal, characterized in that, The chip includes the chip as described in claim 7, and a memory; the memory stores a computer program, the computer program including instructions that are executed by a processor in the chip.

9. A device flashing permission management system, characterized in that, include: An authorized device, connected to the smart terminal as described in claim 8, is configured to identify the device status of the smart terminal; According to the device status, the communication method and authorization mode are switched, and a first authorization authentication request is sent to the smart terminal through a first communication protocol, or a second authorization authentication request is sent to the smart terminal through a second communication protocol; The authorization modes include a quick start authorization mode and a debug interface authorization mode; The smart terminal is configured to receive the first authorization authentication request or the second authorization authentication request, and report the device fingerprint information obtained from the first storage partition to the server; wherein, the device fingerprint information includes the device public key; the first storage partition stores the device private key and the cloud public key; The server is configured to, upon receiving device fingerprint information reported by the smart terminal, sign the device fingerprint information using a cloud private key to generate a digital signature; the server stores a cloud public key, a cloud private key, and a device public key.

10. The access control system according to claim 9, characterized in that: The server is also configured to authenticate the identity information of the authorized device, and when the identity information is authenticated, allow the authorized device to send a first authorization authentication request or a second authorization authentication request; The server is also configured to perform a signature operation after recognizing the validity of the device fingerprint information reported by the smart terminal.

Images