KR102833142B1 - Dynamic kernel module protection method of mobile device and system using the same - Google Patents

Abstract

The present invention is characterized by including: a client application which generates information about a shielded kernel module as a compressed message for a trusted execution environment to trigger execution of the shielded kernel module in a general execution environment; a TrustZone kernel driver which copies the compressed message generated by the client application and transmits it to the trusted execution environment; a trusted dispatcher which receives the compressed message, verifies the integrity of the shielded kernel module, and calls a shielded module loader to initialize and execute the shielded kernel module in the trusted execution environment; and a shielded module loader which executes the shielded kernel module by calling the dispatcher.

Description

{DYNAMIC KERNEL MODULE PROTECTION METHOD OF MOBILE DEVICE AND SYSTEM USING THE SAME}

The present invention relates to a method for protecting a dynamic kernel module of a mobile device and a system using the same, and more particularly, to a method for protecting a dynamic kernel module of a mobile device and a system using the same, which can be safely executed even in a situation where the operating system is taken over by an attacker.

The Internet of Things (IoT) industry continues to grow, with the number of IoT devices expected to increase to 24 billion by 2050. In addition, IoT devices continue to appear for our daily lives, including home entertainment, critical infrastructure, and industry. Unfortunately, this situation can make IoT devices an attractive target for attackers, and security tends to be a lower priority than rapid deployment and productivity when it comes to IoT devices, which could attract more attackers to the IoT world.

Trusted Execution Environment (TEE) is a promising technology for protecting IoT devices because it can isolate execution contexts from rich execution environments (REEs). In other words, even if the operating system of the rich execution environment is compromised, security-critical logic and operations such as cryptographic operations and firmware recovery can be effectively isolated.

ARM TrustZone is one of the trusted execution environment technologies that can be used on ARM architecture-based platforms ranging from small IoT devices to servers. Various security applications using TrustZone are being proposed, such as virtualized trusted execution environments for cloud servers, one-time passwords for mobile devices, and secure advertisements. In particular, TrustZone is utilized to protect the operating system kernel by depriving the operating system of its authority and emulating important tasks in the trusted execution environment to ensure the immutability of the operating system. In addition to its application in mobile and server environments, TrustZone is also attracting attention in the IoT field.

While TrustZone enables a system to benefit from a trusted execution environment, the accessibility of TrustZone to third-party application developers and IoT service providers is limited. This is because the trusted execution environment is owned by the SoC (System on a Chip) manufacturer or the trusted execution environment software platform provider. The trusted execution environment is typically a paid service supported on a membership basis. The trusted execution environment client must develop a trusted application (TA) using the trusted execution environment application programming interfaces (APIs) provided by a particular trusted execution environment vendor. In addition, these TAs are strictly checked by the trusted execution environment vendor to prevent the distribution of new TAs with exploitable bugs. This trusted execution environment feature can delay the time required to develop and deploy new or updated trusted IoT software and delay the time to market of IoT services. Therefore, this may be the main reason why third-party IoT service providers are reluctant to use TrustZone.

Korean Patent No. 10-1894926

The present invention seeks to safely execute a kernel module while protecting it from attackers by dynamically loading the kernel module into a trusted execution environment created by utilizing security technology (TrustZone) provided by a mobile processor such as ARM.

Furthermore, the present invention seeks to ensure secure execution of third-party software without extending the existing trusted execution environment or introducing a new attack surface into the trusted execution environment.

Additionally, the present invention seeks to minimize the use of separate APIs in order to develop reliable applications.

In order to achieve the above object, the present invention is characterized by including: a client application which generates information about a shielded kernel module as a compressed message for a trusted execution environment in order to trigger execution of the shielded kernel module in a general execution environment; a TrustZone kernel driver which copies the compressed message generated by the client application and transmits it to the trusted execution environment; a trusted dispatcher which receives the compressed message, verifies the integrity of the shielded kernel module, and calls the shielded module loader to initialize and execute the shielded kernel module in the trusted execution environment; and a shielded module loader which executes the shielded kernel module by calling the dispatcher.

Preferably, the client application loads the image of the shielded kernel module as a file stream, compresses the start address, module size, entry point and signed hash of the loaded kernel module into a message to the trusted execution environment using the trusted execution environment's API, and can call an inter-processor interrupt (IPI) to turn off other cores.

Preferably, the client application can open the TrustZone kernel driver to allow compressed messages to be passed to the trusted execution environment.

Preferably, the dispatcher can parse the received compressed message to obtain an address and a size of the shielded kernel module, allocate memory to a sandbox area of the trusted execution environment, and copy an image of the shielded kernel module to the sandbox area to which memory is allocated based on the obtained size information of the shielded kernel module.

In addition, the present invention is characterized by including a step (a) in which a user application in a general execution environment transfers a kernel module to a trusted execution environment and requests shielded execution; a step (b) in which a trusted dispatcher in the trusted execution environment verifies the integrity of the kernel module and calls a shielded module loader; and a step (c) in which a memory firewall and a sandbox are configured so that the shielded module loader safely executes the kernel module and maintains the security of the trusted execution environment.

The present invention focuses on user level application protection.

In addition, the present invention has an advantage in that it can provide an environment in which third-party IoT service providers can be guaranteed secure OS permission operations.

Additionally, the present invention differentiates itself from previous TrustZone-based work that was limited to protecting user applications by isolating privileged software such as LKMs from the untrusted general execution environment of the OS.

In addition, the present invention provides an environment in which protection software can be created according to existing kernel module development practices, so that there is no need to use an API dedicated to a trusted execution environment, thereby reducing the development effort of developers.

Furthermore, the present invention can solve the problem that various emergency device management tasks requiring the authority of the trusted execution environment can be performed on the fly by the IoT service provider without waiting for the intervention of the trusted execution environment vendor, which may hinder the time-to-market requirements of IoT devices.

Figure 1 shows an ARM architecture with TrustZone as a background technology of the present invention.
FIG. 2 shows a configuration diagram of a dynamic kernel module protection system for a mobile device according to an embodiment of the present invention.
Figure 3 illustrates a memory conversion setting according to an embodiment of the present invention.

Hereinafter, the present invention will be described in detail with reference to the contents described in the attached drawings. However, the present invention is not limited or restricted by the exemplary embodiments. The same reference numerals presented in each drawing represent components that perform substantially the same function.

The purpose and effect of the present invention can be naturally understood or made clearer by the following description, and the purpose and effect of the present invention are not limited to the following description alone. In addition, when explaining the present invention, if it is judged that a detailed description of a known technology related to the present invention may unnecessarily obscure the gist of the present invention, the detailed description will be omitted.

Fig. 1 shows an ARM architecture with TrustZone as a background technology of the present invention. Referring to Fig. 1, ARM TrustZone is a security extension of ARM processor, and TrustZone technology can divide the system into two execution environments, a general execution environment and a trusted execution environment. General software stacks such as Linux and Android-based are hosted in the general execution environment. On the other hand, the trusted execution environment protects security-critical applications such as cryptographic services and DRM (Digital Rights Management).

To ensure isolation between these environments, various hardware components are supported. ARM processors define different security states (secure and non-secure). In the non-secure state, user, kernel, and hypervisor modes are supported. In the secure state, user, kernel, and monitor modes are available. In particular, with respect to the monitor mode, the running software manages the transition between environments by saving and restoring the context of each environment. In addition to the security state of the processor, TZASC is provided to partition the DRAM for each environment. Using TZASC, several physical memory regions and their access permissions can be defined according to the security state of the processor. For example, a specific range of physical memory can be configured as a trusted execution environment region by allowing access from the trusted execution environment (secure state) but not from the normal execution environment (non-secure state). In addition to the security state and memory access control, TrustZone also protects input/output (IO) peripherals such as the display and the keypad. The TrustZone Protection Controller (TZPC) can dynamically connect these peripherals to the trusted execution environment to create secure IO channels, thereby preventing interference from a compromised common execution environment.

ARM processors support a virtual memory system that translates virtual addresses into physical addresses. This translation is performed based on page tables whose base addresses are configured using Translation Table Base Registers (TTBRs). There are typically two architecture-supported TTBRs: TTBR0 and TTBR1. On 64-bit systems, TTBR0 and TTBR1 typically contain page table base addresses for user and kernel space, respectively. On 32-bit systems, only one page table can be used due to the small address range, i.e., 4 GB. For example, in the case of a 32-bit Linux-based address space that includes user and kernel space, the setting of the Translation Table Base Control Register (TTBCR) determines whether one or both TTBRs are utilized.

When using the short descriptor format, the N flag in the TTBCR determines the size of the address translation performed via the page tables pointed to by TTBR0 and TTBR1. For example, if the N value is 0b000, only TTBR0 is used. Otherwise, both TTBR0 and TTBR1 are utilized, and the range of addresses translated using each TTBR is determined by the N value. For example, if the N value is set to 0b001, addresses less than 2 GB and greater than 2 GB of virtual memory are translated using TTBR0 and TTBR1, respectively. TTBR and TTBCR are banked registers for the non-secure and secure states of the processor. Therefore, TTBR and TTBCR can be configured independently in the normal execution environment and the trusted execution environment.

FIG. 2 illustrates a configuration diagram of a dynamic kernel module protection system (10) for a mobile device according to an embodiment of the present invention. Referring to FIG. 2, the dynamic kernel module protection system (10) for a mobile device may include a client application (100), a TrustZone kernel driver (200), a trusted dispatcher (300), a shielded module loader (400), a memory firewall (500), and a sandbox (600).

The dynamic kernel module protection system (10) of a mobile device can dynamically load a kernel module into a trusted execution environment and execute it, unlike existing systems that load a user application into a trusted execution environment. The dynamic kernel module protection system (10) can safely execute a kernel module while protecting it from an attacker by dynamically loading the kernel module into a trusted execution environment created by utilizing a security technology (TrustZone) provided by a mobile processor such as ARM. The dynamic kernel module protection system (10) can prevent performance degradation when accessing memory or a file system by allowing a kernel module dynamically loaded into the trusted execution environment to share and use a page table, thereby preventing the kernel module from being executed in a trusted execution environment, which is an area isolated from the operating system.

The dynamic kernel module protection system (10) can provide a trusted execution environment platform that allows a third party to easily use a TrustZone-based trusted execution environment in order to minimize the shortcomings of the trusted execution environment. The dynamic kernel module protection system (10) can protect kernel privilege software such as LKM (Loadable Kernel Module) by using the trusted execution environment.

Any updates to an OS whose integrity is protected by a Trusted Execution Environment-based kernel integrity monitoring typically require the Trusted Execution Environment vendor to verify the update and apply it to the OS image. However, the dynamic kernel module protection system (10) can provide an environment in which a third party can perform emergency device management tasks, such as immediately fixing an OS bug in memory, without waiting for the Trusted Execution Environment vendor to complete verification and apply the changes to the OS image.

The dynamic kernel module protection system (10) may be composed of a general execution environment component and a trusted execution environment component. The general execution environment component may include a client application (100) and a TrustZone kernel driver (200). The trusted execution environment component may include a trusted dispatcher (300), a shielded module loader (400), a memory firewall (500), and a sandbox (600).

The general execution environment can implement a simple loader that communicates with the components of the trusted execution environment to send a request for secure execution of a kernel module provided by a third party. The components of the trusted execution environment can first verify the signature and integrity of the received kernel module based on an asymmetric cryptographic algorithm in order to process the request of the general execution environment. The received kernel module can be executed under the protection of the trusted execution environment.

The dynamic kernel module protection system (10) can protect the execution of a kernel module by utilizing a TrustZone Address Space Controller (TZASC) that enables filtering access to the memory area of a trusted execution zone. The dynamic kernel module protection system (10) sets a hardware debugging watchpoint to monitor all accesses to the memory area of a trusted execution environment by a shielded kernel module, thereby taking into account programming errors that may affect the platform security of an existing trusted execution environment, such as incorrectly allocating memory of a trusted execution environment instead of an OS of a general execution environment.

The dynamic kernel module protection system (10) can rely on a public key infrastructure (PKI) widely used to protect mobile device services such as DRM to ensure that they are used only by clients of a trusted execution environment. That is, a client using the dynamic kernel module protection system (10) must register its public key with a vendor of the trusted execution environment. The vendor of the trusted execution environment stores a hash of the public key in the trusted execution environment. In order to execute a kernel module provided by a client, the module developer first signs the hash of the module using the private key, which is a registered public key pair. The dynamic kernel module protection system (10) can first verify the integrity of the public key using the hash stored in the trusted execution environment before the kernel module is loaded. Subsequently, the dynamic kernel module protection system (10) can verify the integrity of the kernel module by comparing a newly calculated hash using the public key with a decrypted hash.

The dynamic kernel module protection system (10) enables IoT service providers (clients of the trusted execution environment) to distribute kernel modules as needed and to execute them safely under TrustZone protection without disturbing the security of the trusted execution environment. The dynamic kernel module protection system (10) can minimize the developer's efforts when building a TA that requires verification and separation of logic important to the security of an application. The dynamic kernel module protection system (10) can be implemented without using an API provided by a supplier of a specific trusted execution environment.

Developers can benefit from the dynamic kernel module protection system (10) by creating kernel modules that run as shielded kernel modules for IoT services and device maintenance. For example, a kernel module can patch a kernel text region in memory on an emergency basis to fix a bug without replacing the entire kernel image and rebooting the device. Under conditions where the text region is enforced to be immutable due to the protection provided by a TEE-based memory protection solution, this patching operation may require the intervention of the TEE vendor to update the protected memory.

The dynamic kernel module protection system (10) can execute a client module with the authority of a trusted execution environment, so that intervention by a vendor of the trusted execution environment is not required. In addition, in the dynamic kernel module protection system (10), the kernel module can be isolated and protected from an untrusted OS during execution. Therefore, the dynamic kernel module protection system (10) can stably perform a memory inspection task, such as a memory dump of a general execution environment for forensic analysis, without interference from an attacker.

Since the general execution environment and the trusted execution environment use different APIs, the dynamic kernel module protection system (10) can contribute to minimizing the developer's development effort and development complexity. Below, the components of the general execution environment of the dynamic kernel module protection system (10) are described.

Shielded kernel modules can be developed using common Linux kernel symbols, which allow operations such as inspecting kernel data structures. Shielded kernel modules are standalone and can run without interacting with user processes. Shielded kernel modules may not use kernel APIs such as copy_from_user and copy_to_user. Shielded kernel modules are integrity-verified in the TEE, for which a hash of the module can be obtained based on SHA256 and signed using the developer's private key. The signed hash can be passed to the TEE along with the execution request of the shielded kernel module.

The client application (100) can generate a compressed message to the trusted execution environment with information about the shielded kernel module to trigger execution of the shielded kernel module in the normal execution environment. The client application (100) can process three input arguments: the path to the shielded kernel module image, the entry point (function name), and the signed hash.

A client application (100) loads an image of a shielded kernel module as a file stream, compresses the start address, module size, entry point, and signed hash of the loaded kernel module into a message to the trusted execution environment using the trusted execution environment's API, and can call an inter-processor interrupt (IPI) to turn off other cores.

The client application (100) can prevent TOCTTOU (time-of-check-totime-of-use) attacks that exploit race conditions between multiple cores by turning off other cores. In particular, the client application (100) can reliably perform kernel module tasks such as memory inspection in a general execution environment by preventing a potentially malicious core from hiding the attacker's footprints.

The client application (100) can open the TrustZone kernel driver so that compressed messages can be delivered to the trusted execution environment.

The TrustZone kernel driver (200) can copy the compressed message generated by the client application and send it to the trusted execution environment. Since the TrustZone kernel driver (200) resides in the general execution environment, it can be corrupted. Therefore, the TrustZone kernel driver (200) can ignore the execution request of the shielded kernel module, i.e., a denial of service (DoS) attack.

The trusted execution environment can process execution requests of shielded kernel modules. In the trusted execution environment, initialization of shielded kernel modules, memory firewall configuration, sandbox (600) activation, and module dispatching can be performed. The components of the trusted execution environment of the dynamic kernel module protection system (10) are described below.

A trusted dispatcher (300) can receive a compressed message, verify the integrity of the shielded kernel module, and call the shielded module loader (400) to initialize and execute a shielded kernel module in a trusted execution environment. The trusted dispatcher (300) is a configuration corresponding to a client application (100) in a general execution environment.

The trusted dispatcher (300) can verify the hash of the copied shielded kernel module using the signed hash of the client application (100). After verifying the hash, the trusted dispatcher (300) can call the shielded module loader to initialize and execute the shielded kernel module. The trusted dispatcher (300) can pass the host of the shielded kernel module in the sandbox (600) and the entry point to the shielded module loader.

A trusted dispatcher (300) can parse the received compressed message to obtain the address and size of the shielded kernel module, allocate memory to a sandbox (600) area of the trusted execution environment, and copy the image of the shielded kernel module to the sandbox (600) area where the memory is allocated based on the obtained size information of the shielded kernel module.

The shielded module loader (400) can execute a shielded kernel module by a call from a trusted dispatcher (300). The shielded module loader (400) is a modified version of an ELF loader and can perform general operations such as parsing an ELF header, linking kernel symbols, and loading each memory segment to properly execute a shielded kernel module.

Since the shielded kernel module runs in a trusted execution environment, the attacker cannot directly affect the execution of the module, but the attacker can still affect the execution result of the shielded kernel module by manipulating the state of the target inspection object in a timely manner. To address this issue, the client application (100) can temporarily stop all cores except the core that runs the shielded kernel module. However, this approach cannot reliably prevent the threat because the IPI for stopping other cores relies on the execution of kernel APIs that the attacker can override.

The memory firewall (500) can utilize TZASC to prevent a malicious core from interfering with the results of a shielded kernel module. The TZASC can perform access control in the physical memory area based on the security state of the CPU. The memory firewall (500) can dynamically reconfigure the TZASC before executing the shielded kernel module so that the entire physical area allocated to the normal execution environment cannot be accessed by the core in the non-secure state. The memory firewall (500) can prevent a malicious core running in the non-secure state from accessing the shielded kernel module and kernel API even if an attacker blocks an IPI stop request. The core running the shielded kernel driver can still access the entire physical memory because it is in the secure state, so that the module can be executed smoothly. This dynamic configuration of the TZASC does not require redefinition of the area because the physical memory areas for the normal execution environment and the trusted execution environment are already defined and configured at boot time. A memory firewall (500) can block read and write access to areas of the general execution environment from a core in a non-secure state by resetting the REGION_ID_ACCESS_<n> register of the TZASC.

Unintended access to the TEE due to vulnerabilities in shielded drivers or programming errors can allow an attacker to exploit these aspects to compromise the TEE. For example, an attacker can exploit shielded kernel modules to learn the internal workings of the TEE. This cannot be done through static analysis, as the OS and firmware images of the TEE are typically provided as encrypted binaries. However, since they are decrypted by the TEE at runtime, an attacker can abuse the privileges of shielded kernel modules to infer useful information about the TEE.

The sandbox (600) can separate (isolate) the area where a dynamically loaded kernel module is executed within the trusted execution environment to resolve the problem that an attacker can take control of the entire trusted execution environment by attacking the vulnerability if the kernel module loaded within the trusted execution environment has a vulnerability.

The sandbox (600) can be constructed with a watchpoint-based memory isolation technology. The method of constructing the sandbox (600) is as follows. A portion of the memory of the trusted execution environment is reserved as a sandbox area. Next, the reserved area is utilized for module allocation during the initialization phase of the shielded kernel module. Before executing a module in the sandbox (600), a watchpoint is configured to monitor all accesses outside the sandbox where software of another trusted execution environment resides.

When the shielded kernel module completes execution, the watchdog is reconfigured to allow access to the trusted execution environment area again. Since the watchdog configuration instructions are accessible from the sandbox (600), an attacker may attempt to manipulate the configuration by exploiting this. To prevent this, verification logic is used to verify that the watchdog configuration instructions are followed to verify the correctness of the configuration.

Despite the watchpoint-based protection, the outside of the sandbox (600) area is still executable. Therefore, an attacker may attempt to exploit useful TEE libraries and divert control flow to the non-sandboxed area to achieve a successful attack, but it would be very difficult to dynamically or statically analyze the internal layout of the TEE. In particular, the encrypted TEE software prevents static analysis. In addition, the watchpoint-based sandbox (600) prevents runtime information leakage from the layout of the TEE. As a result, an attacker cannot pinpoint the location of useful code chunks in the TEE.

Another embodiment of the present invention provides a method for protecting a dynamic kernel module of a mobile device, which may include a step (a) in which a user application in a general execution environment transfers a kernel module to a trusted execution environment and requests shielded execution, a step (b) in which a trusted dispatcher in the trusted execution environment verifies the integrity of the kernel module and calls a shielded module loader, and a step (c) in which a memory firewall and a sandbox are configured so that the shielded module loader safely executes the kernel module and maintains the security of the trusted execution environment.

Although the present invention has been described in detail through representative examples above, those skilled in the art will understand that various modifications can be made to the above-described embodiments without departing from the scope of the present invention. Therefore, the scope of the rights of the present invention should not be limited to the described embodiments, but should be determined by all changes or modifications derived from the claims and equivalent concepts as well as the claims.

10: Dynamic Kernel Module Protection System for Mobile Devices
100 : Client Application
200 : TrustZone Kernel Driver
300: Trusted Dispatcher
400 : Shielded Module Loader
500 : Memory Firewall
600 : Sandbox

Claims (5)

A client application that generates a compressed message to the trusted execution environment with information about the shielded kernel module to trigger execution of the shielded kernel module in the normal execution environment;
A TrustZone kernel driver that copies compressed messages generated by the client application and transmits them to the trusted execution environment;
A trusted dispatcher for receiving a compressed message, verifying the integrity of the shielded kernel module, and calling the shielded module loader to initialize and execute the shielded kernel module in a trusted execution environment; and
A shielded module loader that executes the shielded kernel module by a call from the trusted dispatcher;
A dynamic kernel module protection system for a mobile device, characterized in that the client application loads the image of a shielded kernel module as a file stream, compresses the start address, module size, entry point and signed hash of the loaded kernel module into a message to the trusted execution environment using the API of the trusted execution environment, and calls an inter-processor interrupt to turn off other cores.
delete In paragraph 1,
The above client application,
A dynamic kernel module protection system for a mobile device, characterized by opening the TrustZone kernel driver so that compressed messages can be transmitted to a trusted execution environment.
In paragraph 1,
The above dispatcher,
A dynamic kernel module protection system for a mobile device, characterized in that the system parses a received compressed message to obtain the address and size of the shielded kernel module, allocates memory to a sandbox area of a trusted execution environment, and copies the image of the shielded kernel module to the sandbox area to which memory is allocated based on the obtained size information of the shielded kernel module.
(a) Step where a client application in a normal execution environment transfers a kernel module to a trusted execution environment and requests shielded execution;
(b) step in which a trusted dispatcher in a trusted execution environment verifies the integrity of the kernel module and calls a shielded module loader; and
(c) step of configuring a memory firewall and a sandbox so that the shielded module loader safely executes the kernel module and maintains the security of the trusted execution environment;
A method for protecting a dynamic kernel module of a mobile device, characterized in that in the step (a), the client application loads the image of the shielded kernel module as a file stream, compresses the start address, module size, entry point, and signed hash of the loaded kernel module into a message to the trusted execution environment using the API of the trusted execution environment, and calls an inter-processor interrupt to turn off other cores.