Power internet of things intelligent terminal trusted execution system
By introducing a trusted execution environment into the smart terminal of the power Internet of Things and utilizing TrustZone and LSM mechanisms, the security vulnerabilities of existing software protection schemes are resolved, and the integrity protection of applications and data security are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SOUTHERN POWER GRID DIGITAL GRID RESEARCH INSTITUTE CO LTD
- Filing Date
- 2022-10-09
- Publication Date
- 2026-04-21
AI Technical Summary
Existing software protection solutions for smart terminals in the power Internet of Things (IoT) have security vulnerabilities when facing malicious attacks. In particular, software encryption solutions for embedded systems are easily cracked, while hardware encryption solutions are costly and resource-constrained, and cannot effectively protect sensitive software from theft.
The trusted execution system for power IoT smart terminals, which adopts trusted execution environment technology, includes TEE clients, TEE kernel device drivers, and a trusted TEE operating system. It utilizes the TrustZone architecture and LSM mechanism to provide security isolation and authentication, and ensures the integrity and security of applications through SMC instructions and shared memory.
It achieves key protection for smart terminals of the power Internet of Things, provides highly secure and reliable software protection, ensures the integrity of applications and data security, and prevents malicious attacks.
Smart Images

Figure CN115688198B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of Internet of Things (IoT) security technology, and specifically relates to a trusted execution system for power IoT smart terminals. Background Technology
[0002] With the rapid development of the smart power Internet of Things (IoT), cybersecurity issues are becoming increasingly prominent. Because the power IoT is closely related to people's normal production and lives, social stability, and national security, and given the increasingly complex international security environment and the frequent occurrence of malicious hacker attacks, cybersecurity protection for the power IoT has become an urgent priority.
[0003] The Smart Power Internet of Things (IoT) is a vast system comprising a perception layer, a network layer, a platform layer, and an application layer. At the innermost layer of this system is the intelligent terminal device. The user-side intelligent terminal is the starting point for all data and services. Users access services and generate data on these smart terminals. Some of these service requests and data are stored within the terminal, while the vast majority are transmitted via wired or wireless networks to storage nodes in the second layer. From there, they are transmitted through an integrated air-space-ground communication network to cloud computing platforms, artificial intelligence platforms, and other systems for storage and processing. Intelligent terminals are the core devices for user interaction with the Smart Power IoT; smart meters are one example. They are not only numerous but also crucial for providing diversified and high-quality services to users. However, the security of smart terminals in the power IoT is currently a serious concern, particularly in terms of software security design. Significant vulnerabilities exist, making the processing of core data and services susceptible to external intrusion, thus impacting the operation of the entire power system.
[0004] Power IoT smart terminals typically use embedded systems. Software protection schemes for embedded systems can be summarized into the following categories: embedded software encryption, embedded software watermarking, embedded software obfuscation, and embedded software anti-tampering schemes.
[0005] Embedded software encryption is one of the core methods of embedded software protection technology. Software encryption can be divided into two categories: (1) encryption schemes that do not rely on hardware, called soft encryption; (2) encryption schemes that rely on hardware, called hardware encryption. Soft encryption mainly uses password table encryption, serial number encryption, and license encryption. A unique product serial number is generated by the registration code or license. Only by entering the correct product serial number can the embedded software run normally. Soft encryption is relatively simple to implement and has low cost, which is why it is highly sought after by many software developers. For example, Microsoft's genuine Office software still uses license encryption. However, soft encryption has a fatal flaw, which is the key protection problem. Once the key of the software product is leaked, the soft encryption of the software product will be cracked. Compared with soft encryption, hardware encryption has higher security, but the cost is also relatively higher. Hardware encryption protection mainly uses some hardware encryption modules, which add encryption / decryption logic circuits to the chip to prevent external malicious parsing attacks and protect data security.
[0006] Embedded software watermarking technology embeds software copyright information and user identity information into the software to identify piracy. When traditional software encryption technology is cracked, the presence of a software watermark provides authentication proof for the software copyright owner.
[0007] Embedded software obfuscation technology refers to performing semantic equivalent transformations on the software to be released. By effectively utilizing obfuscation algorithms, the transformed software has the same functionality as the original, but the structure and meaning of the source code are more complex, making it difficult to crack through static analysis and reverse engineering. Even the source code obtained after decompiling is difficult for humans to read and understand.
[0008] Embedded software anti-tampering technology is a technique for verifying software integrity. It can determine whether the software has been tampered with by checking whether the bytecode in the memory area is complete or whether the files on the hard drive are complete.
[0009] In the aforementioned embedded software protection schemes, pure software protection methods are unable to cope with the ever-emerging new security threats. When using core code modules at the operating system or BIOS level to verify the software integrity of other applications and modules, these core code modules, like other modules, are stored on Flash memory. When security threats use low-level methods such as JTAG to modify / replace these core modules and data, the entire software protection scheme will fail. Moreover, pure software solutions mostly employ passive integrity protection measures, which cannot effectively protect sensitive software from theft. In comparison, hardware encryption technology offers higher security, but in embedded systems, due to limited resources, relying entirely on purely hardware-based security modules places a significant burden on the system and is unsuitable as an embedded software protection solution. Summary of the Invention
[0010] The purpose of this invention is to propose a trusted execution system for smart terminals in the power Internet of Things (IoT). This system is based on trusted execution environment technology and is used to solve the security risks existing in the current power IoT.
[0011] The technical solution of this invention is a trusted execution system for power IoT intelligent terminals, the system comprising:
[0012] Power IoT smart terminal TEE customer, that is, customer API running in the user space of the general environment of power IoT;
[0013] The TEE Linux kernel device driver for the power IoT smart terminal is used to handle the interaction between the user space and the security environment in the general environment of the power IoT.
[0014] The Trusted Operating System (TEE) for power IoT smart terminals runs in a secure environment for the power IoT.
[0015] The trusted operating system of the power IoT smart terminal TEE consists of a power smart terminal TEE security kernel and library files for trusted applications to call.
[0016] The security kernel resides in the CPU kernel layer, while trusted applications reside in the CPU user layer. Trusted applications use static libraries provided by the TEE trusted operations suitable for power smart terminals to call various security services.
[0017] Furthermore, the initialization of the trusted operating system of the power IoT smart terminal is performed by a processor core. After its initialization is completed, other processor cores in a dormant state are released, and caches and memory management units are configured.
[0018] The secure kernel of the trusted operating system of the power IoT smart terminal supports parallel processing of multiple threads, with different threads performing different functions.
[0019] The memory management unit of the trusted operating system of the power IoT smart terminal uses multiple L1 level storage system address translation tables, including one address translation table with a large resolution range and multiple address translation tables with smaller resolution ranges. These tables are responsible for handling address translations not covered by the kernel mode and small-range address translation tables, as well as address matching of the trusted application context virtual address space and providing information on the address of each thread.
[0020] The stack of the trusted operating system for the power IoT smart terminal includes,
[0021] The security monitor stack is used when the processor is in security monitor mode;
[0022] A temporary stack is used during processor state transitions; interrupts are masked during the use of this stack.
[0023] Abort the stack; used when capturing data or aborting prefetch.
[0024] The thread stack is used by the current thread or process to process data. Interrupts are enabled when this stack is in use.
[0025] The trusted operating system of the power IoT smart terminal provides corresponding API functions for trusted applications through the libutee library configured in the power IoT smart terminal TEE.
[0026] Some functions are implemented using the libutee static library, which runs in the user-level secure user space.
[0027] Some functions are implemented using the TEE security core of the power intelligent terminal located in the kernel layer, which is implemented by the libutee library through system call requests.
[0028] Furthermore, the trusted operating system of the power IoT smart terminal authenticates and measures the executable files of the application through trusted applications.
[0029] The trusted operating system of the power IoT smart terminal is based on the TrustZone architecture's security isolation mechanism. It uses the hook function set by the LSM mechanism when the application is executed as a measurement point, inserts the environment switching instruction at the measurement point, and uses the unique identifier UUID of the trusted application to call the corresponding trusted application authentication and measure the executable file of the application according to the interface standard defined by GP.
[0030] The trusted application authenticates and measures the executable file of the application in the created shared memory.
[0031] The beneficial effects of this invention are that, in order to ensure the safe operation of the entire power system and achieve key protection for smart terminals of the power Internet of Things, this invention introduces a trusted execution environment and a trusted execution-specific operating system for smart terminals of the power Internet of Things, providing strong support for the protection of core software in smart terminals of the power Internet of Things. Attached Figure Description
[0032] The above and other objects, features, and advantages of exemplary embodiments of the present invention will become readily apparent from the following detailed description taken in conjunction with the accompanying drawings. Several embodiments of the invention are illustrated in the drawings by way of example and not limitation, wherein:
[0033] Figure 1 A schematic diagram of the composition of a trusted execution system for a power IoT smart terminal, one embodiment of the present invention.
[0034] Figure 2 A schematic diagram of an application integrity protection scheme for a trusted execution system for power IoT smart terminals, one embodiment of the present invention. Detailed Implementation
[0035] After studying the shortcomings of various existing security protection schemes, this disclosure proposes a security protection system for power IoT smart terminals based on a Trusted Execution Environment (TEE). A TEE is a secure area on the main processor of an embedded terminal device that guarantees the security, confidentiality, and integrity of code and data loaded into this environment. The TEE provides a more secure, isolated runtime environment than a typical operating system, offering isolated execution, trusted data confidentiality, and secure storage protection functions within embedded systems.
[0036] GlobalPlatform (GP) is the world's leading organization for developing multi-application management specifications for smart cards. Its members include IC manufacturers such as ARM, AMD, ST, NXP, and Infineon, as well as terminal manufacturers such as Apple, Samsung, and Huawei, and software vendors, operators, and third-party testing organizations. In 2011, GP drafted the Trusted Execution Environment (TEE) specification. Its core idea is to ensure that various sensitive data are stored and processed in a trusted environment. TEE provides a secure operating environment for authorized secure software, also known as "trusted applications," ensuring end-to-end security through the implementation of protection mechanisms and data access control. Among the technology platforms conforming to the TEE specification, TrustZone is a system-level security solution.
[0037] According to one embodiment of this disclosure, based on the GP Trusted Execution Environment standard and the TrustZone security mechanism, this disclosure constructs a Trusted Execution Environment system for power IoT smart terminals. This system consists of three parts: a TEE client suitable for power smart terminals—a client API running in a general environment user space; a TEE Linux kernel device driver suitable for power smart terminals—a device driver handling the interaction between the general environment user space and the secure environment; and a TEE trusted operating system suitable for power smart terminals—a trusted operating system running in the secure environment. Figure 1 As shown.
[0038] Because the TEE applicable to power intelligent terminals fully complies with the Trusted Execution Environment standard defined by GP, it provides a sound system architecture and trusted application architecture, which is conducive to system expansion and the development of trusted applications. It implements functions such as process management, system calls, memory management, shared memory, and environment switching within the executable environment.
[0039] The TEE trusted operating system for power intelligent terminals consists of a TEE security kernel for power intelligent terminals and library files for trusted applications to call. The security kernel resides in the privileged layer of the CPU, i.e., the kernel layer, while trusted applications reside in the non-privileged layer, i.e., the user layer. Trusted applications use the static libraries provided by the TEE trusted operating system for power intelligent terminals to call various security services.
[0040] According to one embodiment of this disclosure, a trusted execution system for a power IoT smart terminal includes a trusted operating system for the power IoT smart terminal TEE. The operating system includes implementation methods for platform initialization, thread processing, memory management unit, stack, library, trusted applications, etc.
[0041] (1) Platform initialization. The 'tz_sinit' function is called during system startup to initialize all processor cores. The initialization operation is performed by one processing core, which releases other cores in a dormant state after initialization is complete, and configures the caches and memory management unit.
[0042] During the 'main_init' phase, each processor core calls the 'main_init_helper' function, which is responsible for setting up the UART, clearing the BSS segment, configuring canaries for detecting buffer overflows, initializing the GIC and monitor vector table, and providing thread handles for security function functions (such as switching functions required when entering a secure environment). Table 1 lists the functional analysis of the platform initialization functions in the embodiments of this disclosure.
[0043] Table 1 Functional Analysis of Platform Initialization Functions
[0044]
[0045] (2) Thread Processing. The secure kernel supports parallel processing by multiple threads, with different threads performing different functions. For example, 'thread_init_handlers' allocates the 'init_handlers' required for the FIQ, SVC, ABORT, and PSCI signals when the trusted kernel receives them. The TEE for power intelligent terminals provides default handles for the above interrupt services and supports the use of custom handles on different development platforms. The TEE for power intelligent terminals supports three synchronization primitives between threads and the processor core: spinlocks, mutexes, and condition variables.
[0046] Spin locks are the most representative type of lock. Once a spin lock is activated, all interrupts are masked until the spin lock state is released. Spin locks are initialized using 'SPINLOCK_UNLOCK'.
[0047] A mutex (mutex) enables interrupts in a general environment when a process is in a mutex-locked state within a secure environment, and disables them otherwise. Furthermore, the mutex state cannot be used for interrupt handling, abort handling, or before the processor core selects a thread. While a mutex is locked, it cannot be unlocked by any thread other than the one that owns it, and it prevents entry into the trusted application's user space from kernel mode. Mutexes are initialized using 'MUTEX_INITIALIZER' or 'mutex_init()'.
[0048] Condition variables (CondVar) are typically used in conjunction with mutexes to wait for certain conditions to be met. When used together, the condition variable can only be executed after the mutex is released. Condition variables are initialized using 'CONDVAR_INITIALIZER' or 'condvar_init'. Table 2 lists the function properties of thread and processor core synchronization primitives in embodiments of this disclosure.
[0049] Table 2 Functionality of Thread and Processor Core Synchronization Primitives
[0050]
[0051] (3) Memory Management Unit. The TEE for power intelligent terminals uses multiple L1 level memory system address translation tables, including one address translation table with a resolution range of 4GB and multiple address translation tables with a resolution range of 32MB. These are responsible for handling address translations not covered by the kernel mode and smaller address translation tables, as well as address matching in the trusted application context virtual address space and providing address information for each thread.
[0052] The TTBR (Translation Table Base Register) is used to configure the memory space between two address translation tables. TTBR1 is typically used to point to an address translation table with a 4GB resolution range, while TTBR0 is used to point to an address translation table with a 32MB resolution range when a user match is active, and to point to an address translation table with a 4GB resolution range when there is no user match.
[0053] (4) Stacks. TEEs for power intelligent terminals provide stacks of various sizes for different processing stages, including:
[0054] Security monitor stack, 128B, processor-bound. Only used when the processor is in security monitor mode.
[0055] A temporary stack, 1KB, bound to the processor. Used during processor state transitions; interrupts are generally masked during the use of this stack.
[0056] Abort stack, 2KB, processor-bound. Used when capturing data or prefetching aborts. Page tables use aborts from the kernel for demand paging, i.e., page faults.
[0057] Thread stack, 8KB, not processor bound. Used for data processing by the current thread or process. Interrupts are enabled when the thread stack is used.
[0058] (5) libutee library. Based on the services provided by the GlobalPlatform core internal API for trusted applications, the TEE for power smart terminals provides corresponding API functions to trusted applications by configuring the libutee library. The libutee library is a static link library called by the trusted application at runtime, and runs in a non-privileged secure user space, just like the trusted application. When designing the internal API functions, the TEE for power smart terminals implements some functions using the libutee static link library, while other functions are implemented using the privileged TEE security core for power smart terminals. The libutee library requests these services through system calls.
[0059] According to one embodiment of this disclosure, a trusted execution system for power IoT smart terminals, based on the secure scheduling and trusted applications provided by a trusted operating system, includes a TEE dual-system communication mechanism suitable for power smart terminals. This mechanism provides an efficient and secure transmission method for information transfer in both general and secure environments, ensuring communication security between trusted applications and customer applications. The TEE dual-system communication mechanism suitable for power smart terminals is mainly reflected in the design and implementation of SMC (Secure Monitor Call) and shared memory. Specifically, it includes the following two aspects.
[0060] (1) SMC Processing. The SMC instruction is a special instruction, similar to the Software Interrupt Instruction (SWI), used to call the monitor routine. The TEE for power intelligent terminals uses the SMC exception vector for switching and communication between the general environment and the security environment. By configuring the corresponding bits in the MVBAR register, the initialized monitor vector table is called to query the SMC exception vector. Current monitor software design supports entering the security environment via commonly used SMC instructions and FIQ requests.
[0061] The SMC processing procedure is as follows:
[0062] 1. Pass general environment request parameters through the Trusted Execution Environment's SMC interface, call 'smc#0' to generate an SMC exception, and perform initialization in the Linux kernel's TEE device driver.
[0063] 2. This exception causes the processor to enter monitor mode. The monitor saves the current state context information and checks the 'SRC.NS' information to determine the next environment to enter. (SRC.NS indicates the environment from which the SMC instruction originated).
[0064] 3. Once the monitor determines that a secure environment has been entered, the secure kernel first allocates a thread to execute the task. If the SMC instruction is a standard call, the kernel will execute the 'thread_alloc_and_run' function to allocate an unused thread for the switch request. If no thread is currently available and all threads are in use, the kernel will return 'OPTEE_SMC_RETURN_ETHREAD_LIMIT' to the generic environment. If a thread is available, the kernel copies the relevant register values and jumps to the 'thread_std_smc_entry' function to prepare for thread execution.
[0065] 4. After the 'thread_std_smc_entry' function is executed, it will call the 'thread_stdcall_handler_ptr' function. This function points to the relevant functions required when registering the thread handle, usually pointing to the 'main_tee_entry' function. The implementation method of this process varies depending on the platform. When the platform does not require special security handling, it can directly call the 'tee_entry' function to enter the safe environment.
[0066] 5. Enter the secure environment through the 'tee_entry' function, call the secure application, and establish a session with the general application.
[0067] (2) Shared Memory. Shared memory is a memory region accessible to both insecure and secure environments, used for data exchange between the two environments. In the TEE implementation for power intelligent terminals, shared memory is allocated by the Linux driver from 'struct shm_poll', including the region's starting physical address, size information, cache status, and list of allocated memory blocks. The shared memory region is physically contiguous and is unprotected when used simultaneously in insecure and secure environments.
[0068] Shared memory in TEE designs for power intelligent terminals is typically used in the following four scenarios: 1. Client application requests shared memory. The client application uses the client interface function 'TEEC_AllocateSharedMemory()' defined by the GB organization to request shared memory allocation and provides the requested shared memory to the trusted execution environment through 'TEEC_RegisterSharedMemory()'. Since the TEE security core for power intelligent terminals does not support handling distributed memory, the shared memory provided by the client must be physically contiguous in this case. Furthermore, the number of blocks in the shared memory is incremented from 1 during initialization, and a memory region will not be released due to idleness.
[0069] 2. Linux driver requests shared memory. In some cases (such as when using a buffer of type TEEC_TempMemoryReference), a Linux driver needs to communicate with the security environment, and in this case, the driver needs to request shared memory.
[0070] 3. Shared memory requests from the TEE security kernel for power smart terminals. When the security kernel needs information from a trusted execution environment (TEE supplicant, such as dynamic trusted application loading), it needs to allocate shared memory. The allocation method for shared memory varies depending on the use case.
[0071] 4. TEE supplicant uses shared memory. When TEE supplicant receives a physical address for storing data from the secure kernel (e.g., when a trusted application is loaded), TEE supplicant must register the shared memory it needs in the same way that the client application and the Linux driver do.
[0072] According to one embodiment of this disclosure, a trusted execution system for power IoT smart terminals is provided, which is suitable for the TEE of power smart terminals to provide two forms of trusted applications: pseudo-trusted applications (PTA) and dynamically loadable trusted applications (DLTA). DLTA is designed according to the standards developed by GlobalPlatform, and in most cases, DLTA is used to perform security services.
[0073] In the compilation files of the TEE executable environment for power intelligent terminals, the PTA implementation is configured in the security kernel file. It runs at the execution environment's security privilege level, providing specific security services and embedded testing services. Due to the special design of the PTA, it is often not designed as a PTA when designing complex trusted applications.
[0074] DLTA, or Trusted Application, is dynamically loaded by the executable environment kernel when a service is requested in the general environment, and a unique identifier (UUID) of the trusted application is passed along with it. To ensure the legitimacy of the trusted application's identity, the secure kernel uses the same private key to sign all trusted applications, stores the signed trusted applications in the general environment's file system, and checks the legitimacy of the trusted application (via the tee-supplicant process) before loading it into the secure environment when a service is requested from the trusted execution environment.
[0075] The TEE for power smart terminals implements the interface standard defined by GlobalPlatform for client applications to send requests to trusted terminals. It includes five interface functions required by the general environment and five interface functions required by the executable environment when client applications request security services. See Tables 3 and 4 below.
[0076] Table 3 shows five interface functions for a general environment when a client application requests security services.
[0077]
[0078] Table 4 shows the five interface functions of the Trusted Execution Environment when a client application requests security services.
[0079]
[0080] According to one embodiment of this disclosure, a trusted execution system for power IoT smart terminals provides isolation and secure access mechanisms for confidential data and trusted applications due to the TrustZone hardware architecture and the trusted execution environment suitable for power smart terminals, thus providing a reliable foundation for the design of application integrity protection methods. Based on this, the embodiment of this disclosure designs a trusted application with identity authentication and integrity verification functions. Using LSM technology, before the executable file with embedded "identity factors" runs, it switches to the trusted execution environment, uses the trusted application to authenticate and measure it, and ensures that only applications with integrity can have execution permissions.
[0081] Specifically, LSM is a lightweight, general-purpose access control framework for the Linux kernel. LSM does not interfere with existing security policies; it adds a layer of (access) control through hook technology. Users can select suitable security modules to load into the Linux kernel according to their needs, greatly improving the flexibility and ease of use of the Linux security access control mechanism. Based on the TrustZone security isolation mechanism and the trusted execution environment suitable for power smart terminals, the hook functions defined by the LSM mechanism during application execution are used as measurement points. Environment switching instructions are inserted at these measurement points, and the unique identifier (UUID) of the trusted application is used to call the corresponding trusted application defined according to the interface standard defined by GlobalPlatform. The executable file of the application is authenticated and measured in the shared memory requested by the client application, ensuring the security of the application execution process and preventing the execution of illegal or compromised applications. The specific steps are as follows.
[0082] First, a Trusted Execution Environment (TEE) supporting application integrity protection components needs to be constructed, specifically a TEE suitable for power smart terminals. This TEE provides basic memory management, task scheduling, interrupt handling, cryptographic algorithms, key management, and a core TEE session framework. Leveraging TrustZone hardware isolation, it runs on the processor's secure core. In addition, a trusted application with robust application integrity protection capabilities needs to be built, enabling the TEE to provide authentication and verification functions for information transmitted to the general runtime environment. Specifically, this includes secure management of parameters transmitted to client applications, authentication of executable file certificates, and verification of executable file integrity. Second, a general runtime environment for executing applications needs to be constructed, namely a general operating system kernel, running on the processor's ordinary core. Furthermore, a "security hook," or metric point, is added during the system call phase of application execution using the LSM mechanism. This is achieved by entering security monitor mode via the SMC instruction, creating shared memory, invoking the trusted application, and transmitting authentication and metric parameters. Finally, a security monitor needs to be built to handle context switching between the two runtime environments. Figure 2 The diagram shown is an example of an application integrity protection scheme for the trusted execution system of the power IoT smart terminal.
[0083] The application integrity protection scheme of this disclosure utilizes the isolation environment of TrustZone to provide secure hardware conditions for the implementation of protection functions. On the other hand, it utilizes the LSM mechanism and digital authentication mechanism to provide appropriate measurement timing and reliable authentication methods for application protection.
[0084] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A trusted execution system for power IoT intelligent terminals, characterized in that, The system includes: Power IoT smart terminal TEE customer, that is, customer API running in the user space of the general environment of power IoT; The TEE kernel device driver for power IoT smart terminals is used to handle the interaction between the user space and the security environment in the general environment of power IoT. The trusted operating system for the power IoT smart terminal TEE runs in the security environment of the power IoT. The trusted operating system for the power IoT smart terminal TEE consists of a power smart terminal TEE security kernel and library files for trusted applications to call. The security kernel is located at the CPU kernel layer, and the trusted applications are located at the CPU user layer. The trusted applications use the static library provided by the trusted operation of the TEE suitable for power smart terminals to call various security services. The initialization of the trusted operating system of the power IoT smart terminal TEE is performed by one processor core. After its initialization is completed, other processor cores in the dormant state are released, and the caches and memory management unit are configured. The secure kernel of the trusted operating system of the power IoT smart terminal TEE supports parallel processing of multiple threads, with different threads performing different functions. The memory management unit of the trusted operating system of the power IoT smart terminal TEE uses multiple L1 level storage system address translation tables, including one address translation table with a resolution range of 4GB and multiple address translation tables with a resolution range of 32MB. These tables are responsible for handling address translations not covered by the kernel mode and small-range address translation tables, as well as address matching of the trusted application context virtual address space and providing information on the address of each thread. The stack of the trusted operating system for the power IoT smart terminal TEE includes: The security monitor stack is used when the processor is in security monitor mode; A temporary stack is used during processor state transitions; interrupts are masked during the use of this stack. Abort the stack; used when capturing data or aborting prefetch. The thread stack is used by the current thread or process to process data. Interrupts are enabled when this stack is in use. The trusted operating system of the power IoT smart terminal TEE provides corresponding API functions for trusted applications through the libutee library configured in the power IoT smart terminal TEE. Some functions are implemented using the libutee static link library, which runs in the secure user space of the user layer; other functions are implemented using the TEE security core of the power IoT smart terminal located in the kernel layer, and are implemented by the libutee library through system call requests. The power IoT smart terminal TEE trusted operating system authenticates and measures the executable file of the application through trusted applications. Based on the security isolation mechanism of the TrustZone architecture, it uses the hook function set by the LSM mechanism when the application is executed as the measurement point, inserts the environment switching instruction at the measurement point, and uses the unique identifier UUID of the trusted application to call the corresponding trusted application authentication and measurement of the executable file of the application according to the interface standard defined by GP. The trusted application authenticates and measures the executable file of the application in the created shared memory.
2. The trusted execution system for power IoT intelligent terminals according to claim 1, characterized in that, When the processor enters Security Monitor mode, the SMC process is as follows: (1) When the general environment request parameters are passed through the SMC interface of the Trusted Execution Environment, an SMC exception is generated by calling 'smc #0', and initialization is performed in the TEE device driver of the Linux kernel; (2) This exception causes the processor to enter monitor mode. The monitor saves the current state context information and checks the 'SRC.NS' information to determine the environment to be entered next. (3) When the monitor determines that a secure environment has been entered, the secure kernel first allocates a thread to execute the current task. If the SMC instruction is a standard call, the kernel will execute the 'thread_alloc_and_run' function to allocate an unused thread for the switching request. If no threads are currently available and all threads are in use, the kernel will return 'OPTEE_SMC_RETURN_ETHREAD_LIMIT' to the general environment. If an available thread exists, the kernel copies the relevant register values and jumps to the 'thread_std_smc_entry' function to prepare for the execution of that thread; (4) After the 'thread_std_smc_entry' function is executed, the 'thread_stdcall_handler_ptr' function will be called. The 'thread_stdcall_handler_ptr' function points to the relevant functions required when registering the thread handle, that is, it points to the 'main_tee_entry' function. (5) Enter the secure environment through the 'tee_entry' function, call the secure application, and establish a session with the general application.
Citation Information
Patent Citations
TEE-based power Internet of Things secure communication module improvement method
CN112929392A