Electronic device for run trusted application in trusted execution environment, and method and storage medium thereof
The electronic device addresses the challenge of managing multiple security OSs in a TEE by automatically switching between them to ensure reliable execution of trusted applications, enhancing the stability and efficiency of the TEE environment.
Patent Information
- Authority / Receiving Office
- KR · KR
- Patent Type
- Applications
- Current Assignee / Owner
- SAMSUNG ELECTRONICS CO LTD
- Filing Date
- 2025-02-28
- Publication Date
- 2026-07-29
AI Technical Summary
Existing electronic devices with multiple security operating systems in a trusted execution environment (TEE) face challenges in efficiently managing the execution of trusted applications (TAs) due to the need to manually check and select a suitable security OS, leading to potential execution failures and operational issues when the selected OS does not support the TA normally.
The electronic device is designed to execute a first security OS based on configuration information and switch to a second security OS if the first fails, ensuring seamless execution of TAs by prioritizing OSs within the TEE, thereby handling execution failures gracefully.
This approach ensures reliable execution of TAs by automatically switching between security OSs, minimizing operational failures and maintaining system stability even when initial OS execution fails, thus enhancing the robustness of the TEE environment.
Smart Images

Figure PAT00010_ABST
Abstract
Description
Technology Field
[0001] The present disclosure relates to an electronic device for executing a trusted application (TA) in a trusted execution environment (TEE), and to a method and a storage medium thereof. Background Technology
[0003] Secure zone technology is a technique that provides multiple execution environments (e.g., a general environment and a secure environment) and is used in processors (e.g., application processors) to protect high-value code and data. Secure zone technology provides efficient, system-wide access to security by utilizing hardware-enforced isolation embedded in the central processing unit (CPU). The concepts of the secure world (or trusted world) and the non-secure world (or non-trusted world) in secure zone technology are extended to encompass memory, software, bus transactions, interrupts, and peripherals within the system-on-chip (SoC) (e.g., application processor).
[0004] Such security domain technologies generally create a trusted execution environment (TEE) by running a trusted boot and a trusted operating system (OS). A TEE is an independent application execution environment designed to perform operations requiring a relatively high level of security, exceeding a critical security level, within an electronic device. In terms of hardware or software, a TEE is distinguished from a rich execution environment (REE), which is a general application execution environment, and can be equipped with a secure OS capable of running trusted applications (TA). A TEE can be used to protect authentication mechanisms, cryptography, mobile device management, payments, key material, and digital rights management (DRM).
[0005] The information described above may be provided as related art for the purpose of aiding understanding of the present disclosure. No claim or determination is made as to whether any of the foregoing may be applied as prior art related to the present disclosure. means of solving the problem
[0007] According to one embodiment of the present disclosure, an electronic device (101) may include one or more processors (120) including processing circuitry, and a memory (130) for storing instructions.
[0008] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause the application to recognize a request for execution in a rich execution environment (REE).
[0009] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by the one or more processors, the electronic device may cause a first security OS having a first priority among the plurality of security OSs to execute, based on configuration information for the application, which includes priorities of a plurality of security operating systems (OS) capable of executing a plurality of trusted applications (TA) associated with the application, based on an execution request for the application.
[0010] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause a first TA corresponding to the first security OS among the plurality of TAs to be executed in the first security OS.
[0011] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause a second security OS having a second priority among the security OSs other than the first security OS among the plurality of security OSs, based on the fact that the execution result of the first TA is an execution failure.
[0012] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by the one or more processors, the electronic device may cause a second TA corresponding to the second security OS among the plurality of TAs to be executed in the second security OS.
[0013] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause the application to be executed based on the result of the execution of the second TA being successful.
[0014] According to one embodiment of the present disclosure, a TA may include an application running in a trusted execution environment (TEE).
[0015] According to one embodiment of the present disclosure, the plurality of security OSs can be executed in the TEE.
[0016] According to one embodiment of the present disclosure, a storage medium for storing at least one instruction readable by a computer may be provided.
[0017] According to one embodiment of the present disclosure, the at least one instruction may cause the electronic device (101) to perform at least one operation when executed individually or collectively by one or more processors (120) including processing circuitry of the electronic device (101).
[0018] According to one embodiment of the present disclosure, the at least one operation may include an operation of checking an execution request for an application in a rich execution environment (REE).
[0019] According to one embodiment of the present disclosure, the at least one operation may include, based on a request for execution of the application, an operation to execute a first security OS having a first priority among the plurality of security OSs based on configuration information for the application, which includes priorities of a plurality of security operating systems (OS) capable of executing a plurality of trusted applications (TA) associated with the application.
[0020] According to one embodiment of the present disclosure, the at least one operation may include an operation of executing a first TA corresponding to the first security OS among the plurality of TAs on the first security OS.
[0021] According to one embodiment of the present disclosure, the at least one operation may include an operation of executing a second security OS having a second priority among the security OSs other than the first security OS among the plurality of security OSs, based on the fact that the execution result of the first TA is an execution failure.
[0022] According to one embodiment of the present disclosure, the at least one operation may include an operation of executing a second TA corresponding to the second security OS among the plurality of TAs in the second security OS.
[0023] According to one embodiment of the present disclosure, the at least one operation may include an operation to execute the application based on the execution result of the second TA being successful.
[0024] According to one embodiment of the present disclosure, a TA may include an application running in a trusted execution environment (TEE).
[0025] According to one embodiment of the present disclosure, the plurality of security OSs can be executed in the TEE.
[0026] According to one embodiment of the present disclosure, a method of an electronic device (101) may include an operation of checking an execution request for an application in a rich execution environment (REE).
[0027] According to one embodiment of the present disclosure, the method may include an operation of executing a first security OS having a first priority among a plurality of security OSs based on configuration information for the application, which includes priorities of a plurality of security operating systems (OS) capable of executing a plurality of trusted applications (TA) associated with the application, based on an execution request for the application.
[0028] According to one embodiment of the present disclosure, the method may include the operation of executing a first TA corresponding to the first security OS among the plurality of TAs on the first security OS.
[0029] According to one embodiment of the present disclosure, the method may include the operation of executing a second security OS having a second priority among the security OSs other than the first security OS among the plurality of security OSs, based on the execution result of the first TA being an execution failure.
[0030] According to one embodiment of the present disclosure, the method may include the operation of executing a second TA corresponding to the second security OS among the plurality of TAs on the second security OS.
[0031] According to one embodiment of the present disclosure, the method may include an operation to execute the application based on the execution result of the second TA being successful.
[0032] According to one embodiment of the present disclosure, a TA may include an application running in a trusted execution environment (TEE).
[0033] According to one embodiment of the present disclosure, the plurality of security OSs can be executed in the TEE. Brief explanation of the drawing
[0035] FIG. 1 is a block diagram schematically illustrating an electronic device in a network environment according to one embodiment. FIG. 2 is a diagram illustrating a central processing unit (CPU) that provides a multi-execution environment. FIG. 3 is a diagram illustrating a software architecture according to a security mode and a non-security mode according to one embodiment. Figure 4 is a diagram illustrating a situation in which an application failure occurs in a REE due to abnormal operation of a TA in a TEE that supports multiple security OSs. FIG. 5 is a diagram illustrating the operation of executing a TA in a TEE that supports multiple security OSs according to one embodiment. FIG. 6 is a diagram illustrating the operation of executing a TA in a TEE that supports multiple security OSs according to one embodiment. FIG. 7 is a diagram illustrating the operation of executing a TA in a TEE that supports multiple security OSs according to one embodiment. FIG. 8 is a flowchart illustrating the operation process of an electronic device according to one embodiment. FIG. 9 is a diagram illustrating the operation of executing a TA in a TEE that supports multiple security OSs according to one embodiment. FIG. 10 is a drawing illustrating a user interface of an electronic device executing a TA in a TEE that supports a plurality of security OSs according to one embodiment. Specific details for implementing the invention
[0036] An embodiment of the present disclosure will be described in detail below with reference to the attached drawings. In describing an embodiment of the present disclosure, if it is determined that a detailed description of related known functions or configurations could unnecessarily obscure the essence of the embodiment, such detailed description will be omitted. Furthermore, the terms described below are defined considering the functions in an embodiment of the present disclosure, and these may vary depending on the intentions or conventions of the user or operator. Therefore, their definitions should be based on the content throughout this specification.
[0037] It should be noted that technical terms used in this specification are used merely to describe specific embodiments and are not intended to limit the embodiments of this disclosure. Alternatively, unless specifically defined otherwise in this specification, technical terms used in this specification shall be interpreted in the sense generally understood by those skilled in the art to which this disclosure pertains, and shall not be interpreted in an overly broad or overly narrow sense. Furthermore, if a technical term used in this specification is an incorrect technical term that fails to accurately express the spirit of this disclosure, it shall be understood as being replaced by a technical term that can be correctly understood by those skilled in the art. Alternatively, general terms used in an embodiment of this disclosure shall be interpreted according to their prior definitions or according to the context, and shall not be interpreted in an overly narrow sense.
[0038] Alternatively, singular expressions used in this specification include plural expressions unless the context clearly indicates otherwise. In this application, terms such as "composed of" or "comprising" should not be interpreted as necessarily including all of the various components or operations described in the specification, and should be interpreted as meaning that some of the components or operations may not be included, or that additional components or operations may be included.
[0039] Alternatively, terms including ordinal numbers, such as first, second, etc., as used herein may be used to describe various components, but said components shall not be limited by said terms. Such terms are used solely for the purpose of distinguishing one component from another. For example, without departing from the scope of the present disclosure, the first component may be named the second component, and similarly, the second component may be named the first component.
[0040] When it is stated that one component is "connected" or "connected" to another component, it may be directly connected or connected to that other component, or there may be other components in between. On the other hand, when it is stated that one component is "directly connected" or "directly connected" to another component, it should be understood that there are no other components in between.
[0041] Hereinafter, an embodiment according to the present disclosure will be described in detail with reference to the attached drawings. Identical or similar components regardless of drawing symbols are given the same reference number, and redundant descriptions thereof will be omitted. Alternatively, in describing an embodiment of the present disclosure, if it is determined that a detailed description of related prior art may obscure the essence of the present disclosure, such detailed description will be omitted. Furthermore, it should be noted that the attached drawings are intended only to facilitate an easy understanding of the concept of the present disclosure and should not be interpreted as limiting the concept of the present disclosure. The concept of the present disclosure should be interpreted as extending to all modifications, equivalents, and substitutions in addition to the attached drawings.
[0042] Hereinafter, in one embodiment of the present disclosure, an electronic device will be described as an example, but the electronic device may be referred to as a terminal, mobile station, mobile equipment (ME), user equipment (UE), user terminal (UT), subscriber station (SS), wireless device, handheld device, or access terminal (AT). Alternatively, in one embodiment of the present disclosure, the electronic device may be a device equipped with communication functions, such as a mobile phone, personal digital assistant (PDA), smartphone, wireless modem, or laptop.
[0043] FIG. 1 is a block diagram schematically illustrating an electronic device (101) in a network environment (100) according to one embodiment.
[0044] Referring to FIG. 1, in a network environment (100), an electronic device (101) may communicate with an electronic device (102) through a first network (198) (e.g., a short-range wireless communication network) or with an electronic device (104) or a server (108) through a second network (199) (e.g., a long-range wireless communication network). According to one embodiment, the electronic device (101) may communicate with the electronic device (104) through a server (108). According to one embodiment, the electronic device (101) may include a processor (120), memory (130), input module (150), sound output module (155), display module (160), audio module (170), sensor module (176), interface (177), connection terminal (178), haptic module (179), camera module (180), power management module (188), battery (189), communication module (190), subscriber identification module (196), or antenna module (197). In some embodiments, at least one of these components (e.g., connection terminal (178)) may be omitted from the electronic device (101), or one or more other components may be added. In some embodiments, some of these components (e.g., sensor module (176), camera module (180), or antenna module (197)) may be integrated into a single component (e.g., display module (160)).
[0045] The processor (120) can control at least one other component (e.g., a hardware or software component) of the electronic device (101) connected to the processor (120) by executing software (e.g., a program (140)), and can perform various data processing or operations. According to one embodiment, as at least part of the data processing or operations, the processor (120) can store commands or data received from other components (e.g., a sensor module (176) or a communication module (190)) in volatile memory (132), process the commands or data stored in volatile memory (132), and store the resulting data in non-volatile memory (134). According to one embodiment, the processor (120) may include a main processor (121) (e.g., a central processing unit or an application processor) or an auxiliary processor (123) that can operate independently or together with it (e.g., a graphics processing unit, a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor). For example, if the electronic device (101) includes a main processor (121) and an auxiliary processor (123), the auxiliary processor (123) may be configured to use less power than the main processor (121) or to be specialized for a designated function. The auxiliary processor (123) may be implemented separately from the main processor (121) or as part thereof.
[0046] The auxiliary processor (123) may control at least some of the functions or states associated with at least one component of the electronic device (101) (e.g., display module (160), sensor module (176), or communication module (190)) on behalf of the main processor (121) while the main processor (121) is in an inactive (e.g., sleep) state, or together with the main processor (121) while the main processor (121) is in an active (e.g., application execution) state. According to one embodiment, the auxiliary processor (123) (e.g., image signal processor or communication processor) may be implemented as part of another functionally related component (e.g., camera module (180) or communication module (190)). According to one embodiment, the auxiliary processor (123) (e.g., neural network processing unit) may include a hardware structure specialized for processing an artificial intelligence model. The artificial intelligence model may be generated through machine learning. Such learning may be performed, for example, on the electronic device (101) itself where the artificial intelligence is performed, or through a separate server (e.g., server (108)). The learning algorithm may include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model may include a plurality of artificial neural network layers.An artificial neural network may be a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of the above, but is not limited to the examples described above. In addition to the hardware structure, the artificial intelligence model may include a software structure, either additionally or substantially.
[0047] The processor (120) may include processing circuitry. The number of processors (120) may be one or more. For example, the processor (120) may have the structure of a multi-core processor such as a dual core, quad core, or hexa core.
[0048] The processor (120) can control the operations of the electronic device (101) by executing instructions stored in memory (130). For example, the processor (120) may correspond to a plurality of processors that divide and collectively perform a plurality of operations among the processors.
[0049] The memory (130) can store various data used by at least one component of the electronic device (101) (e.g., processor (120) or sensor module (176)). The data may include, for example, input data or output data for software (e.g., program (140)) and related commands. The memory (130) may include volatile memory (132) or non-volatile memory (134).
[0050] The program (140) may be stored as software in memory (130) and may include, for example, an operating system (142), middleware (144), or an application (146).
[0051] The input module (150) can receive commands or data to be used for a component of the electronic device (101) (e.g., processor (120)) from outside the electronic device (101) (e.g., user). The input module (150) may include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).
[0052] The sound output module (155) can output a sound signal to the outside of the electronic device (101). The sound output module (155) may include, for example, a speaker or a receiver. The speaker may be used for general purposes, such as multimedia playback or recording playback. The receiver may be used to receive incoming calls. According to one embodiment, the receiver may be implemented separately from the speaker or as part thereof.
[0053] The display module (160) can visually provide information to an external (e.g., user) of the electronic device (101). The display module (160) may include, for example, a display, a holographic device, or a projector and a control circuit for controlling said device. According to one embodiment, the display module (160) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of the force generated by said touch.
[0054] The audio module (170) can convert sound into an electrical signal or, conversely, convert an electrical signal into sound. According to one embodiment, the audio module (170) can acquire sound through the input module (150) or output sound through the sound output module (155) or an external electronic device (e.g., electronic device (102)) (e.g., speaker or headphones) connected directly or wirelessly to the electronic device (101).
[0055] The sensor module (176) can detect the operating state of the electronic device (101) (e.g., power or temperature) or the external environmental state (e.g., user state) and generate an electrical signal or data value corresponding to the detected state. According to one embodiment, the sensor module (176) may include, for example, a gesture sensor, a gyroscope sensor, a barometric pressure sensor, a magnetic sensor, an accelerometer sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biosensor, a temperature sensor, a humidity sensor, or an illuminance sensor.
[0056] The interface (177) may support one or more specified protocols that can be used for the electronic device (101) to be connected directly or wirelessly to an external electronic device (e.g., electronic device (102)) (tablet and / or smartwatch). According to one embodiment, the interface (177) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.
[0057] The connection terminal (178) may include a connector through which the electronic device (101) can be physically connected to an external electronic device (e.g., electronic device (102)). According to one embodiment, the connection terminal (178) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).
[0058] The haptic module (179) can convert an electrical signal into a mechanical stimulus (e.g., vibration or movement) or an electrical stimulus that the user can perceive through tactile or kinesthetic senses. According to one embodiment, the haptic module (179) may include, for example, a motor, a piezoelectric element, or an electric stimulation device.
[0059] The camera module (180) can capture still images and video. According to one embodiment, the camera module (180) may include one or more lenses, image sensors, image signal processors, or flashes.
[0060] The power management module (188) can manage power supplied to the electronic device (101). According to one embodiment, the power management module (188) can be implemented, for example, as at least part of a power management integrated circuit (PMIC).
[0061] The battery (189) can supply power to at least one component of the electronic device (101). According to one embodiment, the battery (189) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.
[0062] It should be noted that the communication module (190) may also be referred to as a "communication circuit," and thus the communication module (190) and the communication circuit (190) may be used interchangeably as needed. The communication module (190) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between an electronic device (101) and an external electronic device (e.g., electronic device (102), electronic device (104), or server (108)), and the performance of communication through the established communication channel. The communication module (190) may include one or more communication processors that operate independently of the processor (120) (e.g., application processor) and support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module (190) may include a wireless communication module (192) (e.g., a cellular communication module, a short-range wireless communication module, or a GNSS (global navigation satellite system) communication module) or a wired communication module (194) (e.g., a LAN (local area network) communication module, or a power line communication module). The corresponding communication module among these communication modules may communicate with an external electronic device (104) via a first network (198) (e.g., a short-range communication network such as Bluetooth, Wi-Fi (wireless fidelity) direct, or IrDA (infrared data association)) or a second network (199) (e.g., a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN)). These various types of communication modules may be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips).The wireless communication module (192) can identify or authenticate the electronic device (101) within a communication network, such as a first network (198) or a second network (199), using subscriber information (e.g., International Mobile Subscriber Identifier (IMSI)) stored in the subscriber identification module (196).
[0063] The wireless communication module (192) can support 5G networks and next-generation communication technologies following 4G networks, for example, new radio access technology. NR access technology can support high-speed transmission of high-capacity data (enhanced mobile broadband (eMBB)), minimization of terminal power and connection of multiple terminals (massive machine type communications (mMTC)), or high reliability and low latency (ultra-reliable and low-latency communications (URLLC)). The wireless communication module (192) can support a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate, for example. The wireless communication module (192) can support various technologies for securing performance in the high-frequency band, such as beamforming, massive MIMO (multiple-input and multiple-output), full-dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large-scale antenna. The wireless communication module (192) can support various requirements specified in the electronic device (101), external electronic device (e.g., electronic device (104)), or network system (e.g., second network (199)). According to one embodiment, the wireless communication module (192) may support a Peak data rate (e.g., 20 Gbps or more) for eMBB realization, loss coverage (e.g., 164 dB or less) for mMTC realization, or U-plane latency (e.g., downlink (DL) and uplink (UL) each 0.5 ms or less, or round trip 1 ms or less) for URLLC realization.
[0064] An antenna module (197) can transmit a signal or power to or from an external source (e.g., an external electronic device). According to one embodiment, the antenna module (197) may include an antenna comprising a radiator made of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). According to one embodiment, the antenna module (197) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as a first network (198) or a second network (199), may be selected from the plurality of antennas, for example, by a communication module (190). A signal or power may be transmitted or received between the communication module (190) and an external electronic device through the selected at least one antenna. According to some embodiments, in addition to the radiator, other components (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as part of the antenna module (197).
[0065] According to one embodiment, the antenna module (197) may form a mmWave antenna module. According to one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent to a first surface (e.g., bottom surface) of the printed circuit board and capable of supporting a specified high frequency band (e.g., mmWave band), and a plurality of antennas (e.g., array antennas) disposed on or adjacent to a second surface (e.g., top surface or side surface) of the printed circuit board and capable of transmitting or receiving a signal of the specified high frequency band.
[0066] At least some of the above components can be connected to each other via a communication method between peripheral devices (e.g., bus, GPIO (general purpose input and output), SPI (serial peripheral interface), or MIPI (mobile industry processor interface)) and exchange signals (e.g., commands or data) with each other.
[0067] According to one embodiment, commands or data may be transmitted or received between the electronic device (101) and an external electronic device (104) through a server (108) connected to a second network (199). Each of the external electronic devices (102, or 104) may be the same or a different type of device as the electronic device (101). According to one embodiment, all or part of the operations performed on the electronic device (101) may be performed on one or more of the external electronic devices (102, 104, or 108). For example, if the electronic device (101) needs to perform a function or service automatically or in response to a request from a user or another device, the electronic device (101) may request one or more external electronic devices to perform at least part of the function or service instead of performing the function or service itself or additionally. One or more external electronic devices that receive the above request may execute at least part of the requested function or service, or additional function or service related to the request, and transmit the result of the execution to the electronic device (101). The electronic device (101) may provide the result as is or additionally processed as at least part of the response to the request. For this purpose, for example, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used. The electronic device (101) may provide ultra-low latency services using, for example, distributed computing or mobile edge computing. In one embodiment, the external electronic device (104) may include an Internet of Things (IoT) device. The server (108) may be an intelligent server using machine learning and / or neural networks. According to one embodiment, the external electronic device (104) or the server (108) may be included within a second network (199).The electronic device (101) can be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.
[0068] FIG. 2 is a diagram illustrating a central processing unit (CPU) that provides a multi-execution environment.
[0069] Referring to FIG. 2, secure zone technology is a technology that provides multiple execution environments (e.g., a general environment and a secure environment) and is used in a processor (e.g., the processor (120) of FIG. 1 or an application processor) to protect high-value code and data. Secure zone technology provides efficient and system-wide access to security using hardware-enforced isolation embedded in the central processing unit (CPU). The concepts of secure world (or trusted world) and non-secure world (or non-trusted world) in secure zone technology are extended to encompass memory, software, bus transactions, interrupts, and peripherals within a system on chip (SoC) (e.g., an application processor).
[0070] Such security domain technologies generally create a trusted execution environment (TEE) by running a trusted boot and a trusted operating system (OS). A TEE is an independent application execution environment designed to perform operations requiring a relatively high level of security, exceeding a critical security level, within an electronic device. In terms of hardware or software, a TEE is distinguished from a rich execution environment (REE), which is a general application execution environment, and can be equipped with a secure OS capable of running trusted applications (TA). A TEE can be used to protect authentication mechanisms, cryptography, mobile device management, payments, key material, and digital rights management (DRM).
[0071] As illustrated in FIG. 2, when a secure area technology is used, the CPU (211) in the SoC (e.g., processor or application processor) (200) can run applications securely and process sensitive information in terms of security based on a secure mode (215) separated from a non-secure mode (213) using hardware forced isolation. In FIG. 2, the non-secure mode (213) may correspond to a REE and a non-secure area, and the secure mode (215) may correspond to a TEE and a secure area.
[0072] Hardware (219) that can be used in the secure mode (215) corresponds to a TEE and therefore cannot be accessed by applications, kernels, and / or virtual machines (VMs) running in the REE. Here, the hardware (219) that can be used in the secure mode (215) may include secure memory and secure peripherals and can only be accessed from a secure domain. A secure domain may correspond to the secure mode (215).
[0073] Hardware (217) that can be used in non-secure mode (213) corresponds to a REE and can therefore accept access in all states. For example, hardware (217) that can be used in non-secure mode (213) can be accessed by applications, kernels, and / or VMs running in a REE and a TEE.
[0074] Applications running in the REE can request the execution of a trusted application (TA). A TA is an application running in the TEE. After requesting the execution of a TA, an application running in the REE can receive a response corresponding to that request. However, applications running in the REE cannot know information regarding the encryption and decryption operations of sensitive information having a security level higher than the threshold security level performed in the TEE. Additionally, applications running in the REE cannot know information regarding whether peripheral devices that can run in the TEE are operating.
[0075] As mentioned above, security area technology can provide a safer application execution environment by providing separate application execution environments such as REE and TEE.
[0076] FIG. 3 is a diagram illustrating a software architecture according to a security mode and a non-security mode according to one embodiment.
[0077] Referring to FIG. 3, the software architecture (300) according to the secure mode and non-secure mode may include a plurality (e.g., four) exception level (EL) regions. In one embodiment, the plurality of EL regions may include an EL0 region, an EL1 region, an EL2 region, and an EL3 region. Although FIG. 3 describes the software architecture according to the secure mode and non-secure mode using the software architecture of Trustzone technology as an example, the software architecture according to the secure mode and non-secure mode may not be limited thereto.
[0078] In one embodiment, the EL0 area may be an area where an application and a platform are executed.
[0079] In one embodiment, the EL1 area may be an area where the kernel of the OS is executed.
[0080] In one embodiment, the EL2 area may be an area where virtualization technology is supported.
[0081] In one embodiment, the EL3 region may be a region where a secure monitor call (SMC) is supported. In one embodiment, each EL region excluding the EL3 region may be divided to correspond to a non-secure mode (213) (e.g., the non-secure mode (213) of FIG. 2) and a secure mode (215) (e.g., the non-secure mode (215) of FIG. 2). In one embodiment, the non-secure mode (213) may correspond to a REE and a non-secure region, and the secure mode (215) may correspond to a TEE and a secure region. The non-secure region may also be referred to as the normal world.
[0082] In one embodiment, in a non-secure mode (213), multiple applications (311, 313, 315, 317) may be executed in the EL0 area. In one embodiment, in a non-secure mode (213), multiple OSs (Rich OSs) (321, 323) corresponding to multiple REE areas may be executed in the EL1 area. In one embodiment, in a non-secure mode (213), multiple OSs (321, 323) may be executed, and multiple applications may be executed in each of the multiple OSs (321, 323). For example, FIG. 3 illustrates a case where applications (311, 313) are executed in OS (321) and applications (315, 317) are executed in OS (323).
[0083] In one embodiment, a hypervisor (331) may be run in the EL2 area in non-security mode (213). In one embodiment, the hypervisor (331) may manage VMs and provide an isolated environment.
[0084] In one embodiment, in the EL0 area of the security mode (215), trusted services (or TAs) (319) may be executed.
[0085] In one embodiment, a trusted OS (325) and platform firmware (327) may be executed in the EL1 area of the security mode (215). Multiple security OSs may be executed in the EL1 area of the security mode (215). For example, FIG. 3 illustrates a case where multiple trusted services (319) are executed in a single trusted OS (325). In the security mode (215), TAs may be executed by running the security OS (or trusted OS (325)) and platform firmware (327). The platform firmware (327) provides functions such as protected storage or crypto at a relatively simple level compared to the security OS, and may complete necessary operations without executing TAs.
[0086] In one embodiment, a secure partition manager (SPM) (333) may be executed in the EL2 area in secure mode (215). In secure mode (215), multiple VMs, multiple security services, and multiple secure drivers may be supported (or executed) simultaneously in the EL2 area.
[0087] In one embodiment, a firmware / secure monitor (341) may be executed in the EL3 area in non-secure mode (213) and secure mode (215).
[0088] As multiple security operating systems can be supported in the TEE domain of security domain technology, a single processor (e.g., a single application processor) can support multiple security operating systems. Therefore, when products equipped with multiple security operating systems (e.g., processors and SoCs) are sold in the market, users (or TA developers) can reduce the hassle of having to check the security operating systems configured by the chipset vendor or finished product manufacturer in advance and redevelop TAs that can run on the verified security operating systems. Additionally, users (or TA developers) can identify the features provided by the multiple security operating systems or the security technologies applied to them to select a more suitable application execution environment.
[0089] However, in order for a user to select a security OS to run TA from among multiple security OSs, there may be the inconvenience of having to check in advance the security OSs supported by the electronic device and select a specific security OS among the security OSs supported by the electronic device.
[0090] In addition, after a specific security OS is selected and execution of the TA is requested on that specific security OS, there may be no difference in behavior compared to when only a single security OS is supported, even if multiple security OSs are supported in the TEE area. In particular, even if the TA does not execute normally on the selected security OS, the TA may execute normally on other security OSs supported in the TEE. However, whenever the TA does not execute normally on the selected security OS (e.g., whenever the TA behaves abnormally on the selected security OS), the abnormal behavior of the TA may lead to the failure of the operation in the REE associated with the TA, unless separate exceptional processing is implemented to explicitly change the security OS. The abnormal behavior of the TA may include the failure of the normal operation of the TA and / or the failure of the execution result of the TA. Figure 4 is a diagram illustrating a situation in which the failure of an application in the REE occurs due to the abnormal behavior of the TA in a TEE that supports multiple security OSs.
[0091] Referring to FIG. 4, a software architecture (300) according to a secure mode and a non-secure mode (e.g., the software architecture (300) of FIG. 3) may include a plurality (e.g., four) EL regions. In one embodiment, the plurality of EL regions may include an EL0 region, an EL1 region, an EL2 region, and an EL3 region. Each EL region, excluding the EL3 region, may be divided to correspond to a non-secure mode (213) (e.g., the non-secure mode (213) of FIG. 2 or FIG. 3) and a secure mode (215) (e.g., the non-secure mode (215) of FIG. 2 or FIG. 3). The non-secure mode (213) may correspond to a REE and a non-secure region, and the secure mode (215) may correspond to a TEE and a secure region. In Figure 4, the software architecture according to secure mode and non-secure mode is described using the software architecture of the trusted zone technology as an example, but the software architecture according to secure mode and non-secure mode may not be limited to this.
[0092] In non-security mode (213), an application (411) can be executed in the EL0 area.
[0093] In non-security mode (213), an OS (421) corresponding to the REE area can be executed in the EL1 area.
[0094] In non-security mode (213), a hypervisor (431) can be run in the EL2 area.
[0095] In security mode (215), multiple TAs (413, 415, 417) can be executed in the EL0 area.
[0096] In the secure mode (215), multiple secure OSs, for example, a first secure OS (secure OS 1) (423), a second secure OS (secure OS 2) (425), and a third secure OS (secure OS 3) (427), may be executed in the EL1 area.
[0097] In security mode (215), a security hypervisor (433) can be executed in the EL2 area. In security mode (215), multiple VMs, multiple security services, and multiple security drivers can be supported (or executed) simultaneously in the EL2 area.
[0098] In non-secure mode (213) and secure mode (215), a secure monitor (441) can be run in the EL3 area.
[0099] First, as a request for execution of an application (411) in non-secure mode (213) is confirmed, the OS (421) may call a function (or various functions such as macro functions) to be executed in secure mode (215) using an application programming interface (API) provided in secure mode (215). Based on the call of the OS (421), an SMC may be performed using an instruction to perform an SMC, and accordingly, the first secure OS (423) may be executed.
[0100] As a request for execution of an application (411) in non-security mode (213) is confirmed, a TA (413) associated with the application (411) may be executed in a first security OS (423), which is a security OS associated with the application (411) (①). However, if an error occurs in the TA (413) (②), the application (411) may also fail due to abnormal operation of the TA (413) (③). Abnormal operation of the TA may include failure of normal operation of the TA and / or failure of the execution result of the TA.
[0101] In particular, if a serious error such as TEE_Panic occurs in the TA (413) and the TA terminates abnormally, the application (411) may have difficulty performing exception processing. If a serious error such as TEE_Panic occurs, it may be difficult to use the TEE normally. TEE_Panic is an application programming interface (API) that causes a panic, such as a kernel panic, when a very serious problem occurs at the user platform level of the TA or the security OS. A serious error such as TEE_Panic may occur in the following cases.
[0102] (1) When an invalid request (e.g., a request for which access to trusted storage is not authorized, or a request for an invalid action) is sent to trusted storage
[0103] (2) In a crypto operation, if the order of operations is incorrect or the operator is incorrect, the crypto operation may include an encryption operation, a decryption operation, and / or a key generation operation.
[0104] (3) In a cryptographic operation, if there is no memory that needs to be accessed in connection with the cryptographic operation (e.g., data that needs to be read, and / or data that needs to be written) or if such memory exists but its capacity is insufficient
[0105] (4) If interrupt handling fails
[0106] (5) If input / output (I / O) fails during peripheral device communication (or hardware communication)
[0107] Additionally, if a persistent error occurs in a boot-related TA (e.g., Keymaster, File-based Encryption), the electronic device may enter an unusable state, such as an infinite reboot, before the OS (421) in non-secure mode (215) is loaded. A boot-related TA is generally a TA that detects the operation of specific hardware or a TA that must complete an operation to start with a function provided by specific hardware.
[0108] If the TA related to booting is a TA that checks whether the communication processor is operating normally, a communication processor crash may occur if an error occurs in that TA. Such a communication processor crash can occur either during booting or after booting.
[0109] If the TA involved in booting is a TA that generates and manages keys using a key derivation function (KDF) provided by the firmware, an error may occur in the TA and the key may not be generated. If the key is not generated in this way, subsequent operations (e.g., binary check or file check operations required for booting) may become impossible, and booting may become impossible.
[0110] Additionally, if an error occurs in the TA related to user authentication, the user may not be able to unlock the electronic device's lock state, and thus the user may be unable to use the electronic device. For example, user authentication may include personal identification number (PIN) authentication, pattern authentication, password authentication, fingerprint recognition, and / or facial recognition.
[0111] Additionally, TA related to payments (e.g., SamsungTM Samsung Pay, Samsung TM If an error occurs in a Transactional App (TA) that is frequently used by users and requires fast processing, such as Samsung Wallet, it can lead to highly sensitive issues for users, such as payment failures. Errors in such payment-related TAs may occur when a new TA fails to execute because a previously executed TA on a specific secure OS did not terminate due to an unknown cause. In this case, the new TA is likely to execute successfully if run on a different secure OS than the one where the previously executed TA, which did not terminate normally, was run.
[0112] Additionally, there may be issues where hardware failures have a more severe impact on a specific security OS compared to other security OSs among multiple security OSs. In a specific security OS, the success of encryption algorithms may be tested immediately before the TA or the security OS itself is executed on the electronic device. The encryption algorithms may include encryption algorithms based on a true random number generator (TRNG) and / or secure hash algorithms (SHA). If the encryption algorithms fail as a result of the test, the TA or security OS intended to be executed may not be able to be executed. If the encryption algorithms fail before the TA is executed, it may be impossible to execute only the TA and the non-security mode application associated with the TA. However, conversely, if the encryption algorithms fail before the security OS is executed, it may be impossible to boot the electronic device. The failure of the TA or security OS in security mode (215) due to such failure of the encryption algorithm test may be due to a hardware failure problem in which an incorrect result is returned from the hardware's encryption function. When only encryption operations implemented in software are used, the failure probability of the TA or security OS may differ depending on the security OS, even for the same electronic device. For example, even for the same electronic device, it may be impossible to execute the TA or the security OS itself due to the failure of encryption algorithms in one of the multiple security OSs, whereas it may be possible to execute the TA or the other security OS in another security OS because the encryption algorithms do not fail. Accordingly, the present disclosure may provide an electronic device for executing the TA in a TEE that supports multiple security OSs, as well as a method and a storage medium thereof.
[0113] The present disclosure may provide an electronic device that executes a TA by assigning priorities to a plurality of OSs related to the TA in a TEE that supports a plurality of security OSs, and a method and a storage medium thereof.
[0114] According to one embodiment of the present disclosure, an electronic device (101) may include one or more processors (120) including processing circuitry, and a memory (130) for storing instructions.
[0115] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause the application to recognize a request for execution in a rich execution environment (REE).
[0116] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by the one or more processors, the electronic device may cause a first security OS having a first priority among the plurality of security OSs to execute, based on configuration information for the application, which includes priorities of a plurality of security operating systems (OS) capable of executing a plurality of trusted applications (TA) associated with the application, based on an execution request for the application.
[0117] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause a first TA corresponding to the first security OS among the plurality of TAs to be executed in the first security OS.
[0118] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause a second security OS having a second priority among the security OSs other than the first security OS among the plurality of security OSs, based on the fact that the execution result of the first TA is an execution failure.
[0119] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by the one or more processors, the electronic device may cause a second TA corresponding to the second security OS among the plurality of TAs to be executed in the second security OS.
[0120] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause the application to be executed based on the result of the execution of the second TA being successful.
[0121] According to one embodiment of the present disclosure, a TA may include an application running in a trusted execution environment (TEE).
[0122] According to one embodiment of the present disclosure, the plurality of security OSs can be executed in the TEE.
[0123] According to one embodiment of the present disclosure, configuration information for the application may include locations where the plurality of TAs are stored in the plurality of security OSs, locations where client applications (CAs) in the REE that communicate with the plurality of TAs are stored, names of the plurality of security OSs, and versions of the plurality of security OSs.
[0124] According to one embodiment of the present disclosure, configuration information for the application may include input parameters for the plurality of TAs and expected output values for the plurality of TAs. In one embodiment, the configuration information for the application may include various parameters as needed, and there may be no limitations thereon.
[0125] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause a third security OS having a third priority among the security OSs other than the first security OS and the second security OS among the plurality of security OSs to be executed based on the execution result of the second TA being an execution failure.
[0126] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause a third TA corresponding to the third security OS among the plurality of TAs to be executed in the third security OS.
[0127] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause the application to be executed based on the result of the execution of the third TA being successful.
[0128] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by the one or more processors, the electronic device may be caused to identify a security OS having a priority immediately following the first priority among the plurality of security OSs, based on the execution result of the first TA being an execution failure, as at least part of the operation of executing the second security OS, based on the execution result of the first TA being an execution failure, identify whether the identified security OS is installed on the electronic device, and set the identified security OS as the second security OS based on the fact that the identified security OS is installed on the electronic device.
[0129] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by the one or more processors, the electronic device may be caused to identify the security OS having the highest priority among the remaining security OSs other than the first security OS and the identified security OS, based on the fact that the result of executing the first TA is an execution failure, as at least part of the operation of executing the second security OS, identify the security OS having the highest priority among the remaining security OSs other than the first security OS and the identified security OS, based on the fact that the identified security OS is not installed in the electronic device, identify whether the security OS having the highest priority among the remaining security OSs is installed in the electronic device, and set the security OS having the highest priority among the remaining security OSs as the second security OS, based on the fact that the security OS having the highest priority among the remaining security OSs is installed in the electronic device.
[0130] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by the one or more processors, the electronic device may be caused to refrain from executing the application based on the priority of the plurality of security OSs, after executing a set number of security OSs among the plurality of security OSs, and confirming that the application is not executed.
[0131] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause information indicating a failure to execute the application.
[0132] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by the one or more processors, the electronic device may cause the application to be prevented from being executed based on the priority of the plurality of security OSs, after executing at least some of the plurality of security OSs for a set time, and confirming that the application is not executed.
[0133] According to one embodiment of the present disclosure, when the instructions are executed individually or collectively by one or more processors, the electronic device may cause information indicating a failure to execute the application.
[0134] According to one embodiment of the present disclosure, a storage medium for storing at least one instruction readable by a computer may be provided.
[0135] According to one embodiment of the present disclosure, the at least one instruction may cause the electronic device (101) to perform at least one operation when executed individually or collectively by one or more processors (120) including processing circuitry of the electronic device (101).
[0136] According to one embodiment of the present disclosure, the at least one operation may include an operation of checking an execution request for an application in a rich execution environment (REE).
[0137] According to one embodiment of the present disclosure, the at least one operation may include, based on a request for execution of the application, an operation to execute a first security OS having a first priority among the plurality of security OSs based on configuration information for the application, which includes priorities of a plurality of security operating systems (OS) capable of executing a plurality of trusted applications (TA) associated with the application.
[0138] According to one embodiment of the present disclosure, the at least one operation may include an operation of executing a first TA corresponding to the first security OS among the plurality of TAs on the first security OS.
[0139] According to one embodiment of the present disclosure, the at least one operation may include an operation of executing a second security OS having a second priority among the security OSs other than the first security OS among the plurality of security OSs, based on the fact that the execution result of the first TA is an execution failure.
[0140] According to one embodiment of the present disclosure, the at least one operation may include an operation of executing a second TA corresponding to the second security OS among the plurality of TAs in the second security OS.
[0141] According to one embodiment of the present disclosure, the at least one operation may include an operation to execute the application based on the execution result of the second TA being successful.
[0142] According to one embodiment of the present disclosure, a TA may include an application running in a trusted execution environment (TEE).
[0143] According to one embodiment of the present disclosure, the plurality of security OSs can be executed in the TEE.
[0144] According to one embodiment of the present disclosure, configuration information for the application may include locations where the plurality of TAs are stored in the plurality of security OSs, locations where client applications (CAs) in the REE that communicate with the plurality of TAs are stored, names of the plurality of security OSs, and versions of the plurality of security OSs.
[0145] According to one embodiment of the present disclosure, configuration information for the application may include input parameters for the plurality of TAs and expected output values for the plurality of TAs. In one embodiment, the configuration information for the application may include various parameters as needed, and there may be no limitations thereon.
[0146] According to one embodiment of the present disclosure, the at least one operation may include an operation of executing a third security OS having a third priority among the security OSs other than the first security OS and the second security OS, based on the fact that the execution result of the second TA is an execution failure.
[0147] According to one embodiment of the present disclosure, the at least one operation may include an operation of executing a third TA corresponding to the third security OS among the plurality of TAs on the third security OS.
[0148] According to one embodiment of the present disclosure, the at least one operation may include an operation to execute the application based on the execution result of the third TA being successful.
[0149] According to one embodiment of the present disclosure, the operation of executing the second security OS based on the execution result of the first TA being an execution failure may include the operation of identifying a security OS having a priority immediately following the first priority among the plurality of security OSs based on the execution result of the first TA being an execution failure, the operation of identifying whether the identified security OS is installed on the electronic device, and the operation of setting the identified security OS as the second security OS based on the fact that the identified security OS is installed on the electronic device.
[0150] According to one embodiment of the present disclosure, the operation of executing the second security OS based on the execution result of the first TA being an execution failure may include: an operation of identifying the security OS having the highest priority among the remaining security OSs other than the first security OS and the identified security OS, based on the fact that the identified security OS is not installed on the electronic device; an operation of identifying whether the security OS having the highest priority among the remaining security OSs is installed on the electronic device; and an operation of setting the security OS having the highest priority among the remaining security OSs as the second security OS based on the fact that the security OS having the highest priority among the remaining security OSs is installed on the electronic device.
[0151] According to one embodiment of the present disclosure, the at least one operation may include, based on the priorities of the plurality of security OSs, executing a set number of security OSs among the plurality of security OSs and confirming that the application is not executed, refraining from executing the application.
[0152] According to one embodiment of the present disclosure, the at least one operation may include an operation that provides information indicating a failure to execute the application.
[0153] According to one embodiment of the present disclosure, the at least one operation may include, based on the priorities of the plurality of security OSs, executing at least some of the plurality of security OSs for a set time, and then refraining from executing the application based on confirming that the application is not executed.
[0154] According to one embodiment of the present disclosure, the at least one operation may include an operation that provides information indicating a failure to execute the application.
[0155] FIG. 5 is a diagram illustrating the operation of executing a TA in a TEE that supports multiple security OSs according to one embodiment.
[0156] Referring to FIG. 5, a software architecture (300) according to a secure mode and a non-secure mode (e.g., the software architecture (300) of FIG. 3 or FIG. 4) may include a plurality (e.g., four) EL regions. In one embodiment, the plurality of EL regions may include an EL0 region, an EL1 region, an EL2 region, and an EL3 region. Each EL region, excluding the EL3 region, may be divided to correspond to a non-secure mode (213) (e.g., the non-secure mode (213) of FIG. 2, FIG. 3 or FIG. 4) and a secure mode (215) (e.g., the non-secure mode (215) of FIG. 2, FIG. 3 or FIG. 4). The non-secure mode (213) may correspond to a REE and a non-secure region, and the secure mode (215) may correspond to a TEE and a secure region. In the following description, non-security mode, REE, non-security zone, and general zone may be used interchangeably and may have substantially the same meaning. Additionally, in the following description, security mode, TEE, and security zone may be used interchangeably and may have substantially the same meaning. Although the software architecture according to security mode and non-security mode in Fig. 5 is described using the software architecture of the trusted zone technology as an example, the software architecture according to security mode and non-security mode may not be limited thereto.
[0157] In non-security mode (213), an application (411) (e.g., the application (411) of FIG. 4) may be executed in the EL0 area. FIG. 5 describes an operation according to an embodiment of the present disclosure using an application (411) included in the EL0 area as an example, but the operation according to an embodiment of the present disclosure may also be applied to an application included in the EL1 area as well as the EL0 area. In this case, the application included in the EL1 area may include a kernel application.
[0158] In non-security mode (213), an OS (421) corresponding to the REE area (e.g., the OS (421) of FIG. 4) can be executed in the EL1 area.
[0159] In non-security mode (213), a hypervisor (431) (e.g., the hypervisor (431) of FIG. 4) can be executed in the EL2 area.
[0160] In security mode (215), multiple TAs (413, 417) (e.g., the TAs (413, 417) of FIG. 4) can be executed in the EL0 area.
[0161] In the security mode (215), multiple security OSs, for example, a first security OS (423) (e.g., the first security OS (423) of FIG. 4) and a third security OS (427) (e.g., the third security OS (427) of FIG. 4) may be executed in the EL1 area. In this case, the application included in the EL1 area may include a secure kernel application.
[0162] In security mode (215), a security hypervisor (433) (e.g., the security hypervisor (433) of FIG. 4) may be executed in the EL2 area. In security mode (215), multiple VMs, multiple security services, and multiple security drivers may be supported (or executed) simultaneously in the EL2 area.
[0163] In non-security mode (213) and security mode (215), a security monitor (441) (e.g., the security monitor (441) of FIG. 4) can be run in the EL3 area.
[0164] First, as an execution request for an application (411) is confirmed in a non-secure mode (213), the application (411) may transmit a TA execution request to a secure VM manager (511) requesting the execution of a TA associated with the application (411). In one embodiment, the TA execution request may include configuration information (or a configuration file) containing information about multiple secure OSs that can execute multiple TAs associated with the application (411).
[0165] In one embodiment, when the security VM manager (511) receives a TA execution request from an application (411), it may request the security VM controller (513) to execute the corresponding S-VM using the SMC based on the received TA execution request. In one embodiment, the security VM manager (511) may be included in the EL1 area of the non-security mode (213).
[0166] In one embodiment, the security VM controller (513) can load a VM in security mode (215) or run a VM requested by the security VM manager (511). In one embodiment, the security VM controller (513) may be included in the EL2 area of security mode (215).
[0167] In one embodiment, configuration information for an application (411) may include information related to multiple security OSs capable of executing multiple TAs associated with the application (411). In one embodiment, information related to multiple security OSs may include priorities for multiple security OSs, unique information for multiple security OSs, locations where multiple TAs are stored in multiple security OSs, locations where client applications (CAs) in a REE (or non-security mode (213)) communicating with multiple TAs are stored, and / or additional information. In one embodiment, additional information may include various parameters as needed, and there may be no limitations thereon.
[0168] In one embodiment, unique information for a security OS may include the name of the security OS and / or the version of the security OS.
[0169] In one embodiment, additional information may include input parameters for TA and / or expected output values for TA. Input parameters for TA may include parameters that are input when TA is executed. Expected output values for TA may include output values expected when TA is executed. In one embodiment, expected output values for TA may include error codes.
[0170] In one embodiment, additional information may optionally be added to the configuration information for the application (411), and thus, additional information may or may not be added to the configuration information for the application (411) as needed.
[0171] In one embodiment, configuration information for the application (411) may be generated when the application (411) is developed, but is not limited thereto.
[0172] In one embodiment, configuration information for an application (411) needs to be written in a format that can be parsed by a security VM manager (511). If the security VM manager (511) can support multiple file formats, the configuration information for the application (411) can be generated using multiple file formats. For example, if the security VM manager (511) can support XML (extensible markup language), YML, and JSON (javascript object notation), the configuration information for the application (411) can be generated using any one of the XML, YML, and JSON file formats.
[0173] Table 1 below may show configuration information for an application (411) written using XML.
[0174]
[0175]
[0176] In Table 1, TEE_LIST may represent configuration information for an application (411). In Table 1, TEE priority may represent the priority for a security OS.
[0177] As shown in Table 1, the configuration information for the application (411) may include information related to two security OSs (e.g., information related to TEEgris, a security OS with a priority value set to "1", and information related to QSEE, a security OS with a priority value set to "2").
[0178] As shown in Table 1, information related to TEEgris may include the priority of TEEgris (e.g., TEE priority="1"), the version of TEEgris (e.g., version 6.0), the location where the CA corresponding to TEEgris is stored (e.g., / vendor / bin / tee_client_application), the location where the TA corresponding to TEEgris is stored (e.g., / vendor / tee / 00000000-0000-0000-0000-1234567890ab), TA input parameters (e.g., input_param="1000, 0"), and expected output values (e.g., expected_result="Success || Short_Buffer").
[0179] As shown in Table 1, information related to QSEE may include the priority of QSEE (e.g., TEE priority="2"), the version of QSEE (e.g., version 5.0), the location where the CA corresponding to QSEE is stored (e.g., / vendor / bin / client_application), and the location where the TA corresponding to QSEE is stored (e.g., / nhlos / trustzone_images / securemsm / trustzone / qsapps / ta.mbn).
[0180] Table 2 below may show configuration information for an application (411) written using JSON.
[0181] Table 2
[0182]
[0183] In Table 2, TEE_LIST may represent configuration information for an application (411). In Table 2, priority may represent the priority for the security OS.
[0184] As shown in Table 2, the configuration information for the application (411) may include information related to two security OSs (e.g., information related to TEEgris, a security OS with a priority value set to "1", and information related to QSEE, a security OS with a priority value set to "2").
[0185] As shown in Table 2, information related to TEEgris may include the priority of TEEgris (e.g., "priority": "1"), the version of TEEgris (e.g., version 6.0), the location where the CA corresponding to TEEgris is stored (e.g., / vendor / bin / tee_client_application), the location where the TA corresponding to TEEgris is stored (e.g., / vendor / tee / 00000000-0000-0000-0000-1234567890ab), TA input parameters (e.g., input_param="1000, 0"), and expected output values (e.g., expected_result="Success || Short_Buffer").
[0186] As shown in Table 2, information related to QSEE may include the priority of QSEE (e.g., "priority": "2"), the version of QSEE (e.g., version 5.0), the location where the CA corresponding to QSEE is stored (e.g., / vendor / bin / client_application), and the location where the TA corresponding to QSEE is stored (e.g., / nhlos / trustzone_images / securemsm / trustzone / qsapps / ta.mbn).
[0187] As described above, when an execution request for an application (411) is confirmed in non-security mode (213), the application (411) can transmit a TA execution request requesting the execution of a TA associated with the application (411) to a security VM manager (511).
[0188] A security VM manager (511) that receives a TA execution request from an application (411) requesting the execution of a TA related to the application (411) can parse the configuration information (or configuration file) for the application (411) included in the received TA execution request and transmit an S-VM execution request to a security VM controller (513) requesting the execution of a security VM (secure VM: S-VM) corresponding to the priorities of the security OSs (①). In one embodiment, the S-VM may correspond to a security OS. Since the configuration information for the application (411) includes information related to multiple security OSs, the security VM manager (511) can transmit an S-VM execution request to the security VM controller (513) starting from the security OS with the highest priority among the multiple security OSs, based on the priority. In FIG. 5, it is assumed that the first security OS (423) has the highest priority, the second security OS has the next highest priority, and the third security OS (427) has the lowest priority. Accordingly, the security VM manager (511) can transmit an S-VM execution request to the security VM controller (513) to execute an S-VM corresponding to the first security OS (423).
[0189] A security VM controller (513) that receives an S-VM execution request from a security VM manager (511) can execute the corresponding S-VM (or first security OS (423)) based on the received S-VM execution request and allow a TA (413) related to the application (411) to be executed in the corresponding S-VM (or first security OS (423)) (②).
[0190] In one embodiment, the execution result of TA (413) may be transmitted to a security VM manager (511), and the security VM manager (511) may determine whether to execute an S-VM corresponding to the next priority security OS associated with the application (411) based on the execution result of TA (413). In one embodiment, if the execution result of TA (413) indicates an execution failure, the security VM manager (511) may decide to execute an S-VM corresponding to the next priority security OS associated with the application (411). In one embodiment, the execution failure of TA (413) may occur when it is impossible to execute TA (413) or when the first security OS (423), which is the security OS on which TA (413) is executed, terminates abnormally (e.g., when the first security OS (423) terminates abnormally due to a serious error such as TEE_Panic). As TEE_Panic has been explained in Fig. 4, the redundant explanation may be omitted here.
[0191] In FIG. 5, it is assumed that the second security OS has a higher priority than the first security OS (423). Therefore, if the execution result of TA (413) indicates an execution failure, the security VM manager (511) may decide to execute an S-VM corresponding to the second security OS, which has the next highest priority associated with the application (411).
[0192] Since the TA (413) failed to run on the first security OS (423), the security VM manager (511) can transmit an S-VM execution request to the security VM controller (513), which requests the execution of the S-VM corresponding to the second security OS, which is the security OS with the highest priority among the multiple security OSs other than the first security OS (423), based on priority.
[0193] A security VM controller (513) that receives an S-VM execution request from a security VM manager (511) needs to execute the corresponding S-VM (or second security OS) based on the received S-VM execution request and ensure that a TA related to the application (411) is executed in the corresponding S-VM (or second security OS). However, if the S-VM (or second security OS) corresponding to the S-VM execution request received from the security VM manager (511) is not installed in an electronic device (e.g., the electronic device (101) of FIG. 1), the security VM controller (513) can transmit information to the security VM manager (511) indicating that the corresponding S-VM (or second security OS) does not exist (③).
[0194] In FIG. 5, the security VM controller (513) manages a list of security OSs (or S-VMs) installed on the electronic device, and thus the security VM manager (511) may need to inquire with the security VM controller (513) about whether the second security OS is installed on the electronic device in order to check whether the second security OS is installed on the electronic device. Therefore, the security VM manager (511) cannot check whether the second security OS is installed on the electronic device until it separately inquires with the security VM controller (513) about whether the second security OS is installed on the electronic device. Therefore, the security VM manager (511) transmits an S-VM execution request corresponding to the second security OS to the security VM controller (513), and the security VM controller (513) that receives the S-VM execution request can check whether the second security OS is installed on the electronic device.
[0195] Alternatively, the security VM manager (511) may store a list of security OSs installed on the electronic device. In this case, the security VM manager (511) may transmit an S-VM execution request to the security VM controller (513) only for the security OSs installed on the electronic device among the security OSs corresponding to the configuration information for the application (411). In FIG. 5, since only the first security OS (423) and the third security OS (427) are installed on the electronic device, the list of security OSs may include only the first security OS (423) and the third security OS (427). Accordingly, the security VM manager (511) can determine whether the second security OS, which has the highest priority among the security OSs other than the first security OS (423), is installed on the electronic device based on the list of security OSs, since the TA (412) failed to execute on the first security OS (423). In FIG. 5, since the second security OS is not installed on the electronic device, the security VM manager (511) can check whether the third security OS (427), which is the security OS with the highest priority among the security OSs other than the first security OS (423) and the second security OS, is installed on the electronic device.
[0196] In one embodiment, the list of security OSs installed on the electronic device may vary depending on the criteria for generating the list of security OSs.
[0197] In one embodiment, when a list of secure OSs is generated based on whether an S-VM executable file is stored, the list of secure OSs may be stored in a secure VM manager (511). This may be because the S-VM executable file is generally stored in a non-secure mode (213).
[0198] In one embodiment, if a list of security OSs is generated based on whether the loading of the S-VM is successful, the list of security OSs may be stored in the security VM controller (513). This may be to generate a list of security OSs by considering only the S-VMs that have been successfully loaded into the actual security mode (215).
[0199] Since the TA failed to run on the second security OS, the security VM manager (511) can transmit an S-VM execution request to the security VM controller (513), which requests the execution of an S-VM corresponding to the third security OS (427), which is the security OS with the highest priority among the multiple security OSs other than the first security OS (423) and the second security OS, based on priority.
[0200] A security VM controller (513) that receives an S-VM execution request from a security VM manager (511) can execute the corresponding S-VM (or third security OS (427)) based on the received S-VM execution request and allow a TA (417) related to the application (411) to be executed in the corresponding S-VM (or third security OS (427)) (④).
[0201] In one embodiment, the execution result of TA (417) can be transmitted to a security VM manager (511), and the security VM manager (511) can determine whether to execute an S-VM corresponding to the next priority security OS associated with the application (411) based on the execution result of TA (417).
[0202] In one embodiment, if the execution result of TA (417) indicates a successful execution, the security VM manager (511) may transmit the execution result of TA (417) to the application (411). The application (411) that receives the execution result of TA (417) from the security VM manager (511) may be terminated after executing normally.
[0203] In one embodiment, if the execution result of the TA (417) indicates an execution failure, the electronic device no longer has any security OSs capable of executing TAs related to the application (411) (for example, the electronic device no longer has any security OSs corresponding to configuration information for the application (411)), so the security VM manager (511) can transmit information indicating the execution failure of the application (411) to the application (411).
[0204] In FIG. 5, the case in which the security VM manager (511) executes the application (411) by considering all of the multiple security OSs included in the configuration information for the application (411) is described as an example; however, the application (411) may be executed by considering only a set number of security OSs among the multiple security OSs included in the configuration information for the application (411). Alternatively, the security VM manager (511) may execute the application (411) by considering at least some of the multiple security OSs included in the configuration information for the application (411) during a set time. Thus, the reason for considering a set number of multiple security OSs or security OSs during a set time, rather than considering all of the multiple security OSs included in the configuration information for the application (411), may be to prevent a deterioration in service quality due to the delay in execution of the application (411).
[0205] In FIG. 5, the case in which the security VM manager (511) is included in the non-security mode (213) and the security VM controller (513) is included in the security mode (215) is described as an example, but there may be no restrictions on the mode in which the security VM manager (511) and the security VM controller (513) are included. For example, the security VM manager (511) may be included in the security mode (215) and the security VM controller (513) may be included in the non-security mode (213). For example, some of the operations performed by the security VM manager (511) may be included in the non-security mode (213), and the remainder of the operations performed by the security VM manager (511) may be implemented to be included in the security mode (215). For example, some of the operations performed by the security VM controller (513) may be included in the security mode (215), and the remainder of the operations performed by the security VM controller (513) may be implemented to be included in the non-security mode (213).
[0206] As explained above, the security VM manager and the security VM controller can perform connected operations through communication with each other, and thus the security VM manager and the security VM controller can be integrated into a single module. In the following description, the single module in which the security VM manager and the security VM controller are integrated will be referred to as the "security VM manager" for the convenience of explanation.
[0207] FIG. 6 is a diagram illustrating the operation of executing a TA in a TEE that supports multiple security OSs according to one embodiment.
[0208] Referring to FIG. 6, the operation of executing a TA in a TEE supporting multiple security OSs described in FIG. 6 may differ from the operation of executing a TA in a TEE supporting multiple security OSs described in FIG. 5 in that it is implemented in the form of a security VM manager (600) in which a security VM manager (e.g., the security VM manager (511) of FIG. 5) and a security VM controller (e.g., the security VM controller (513) of FIG. 5) are integrated.
[0209] As described in FIG. 5, when an execution request for an application (411) (e.g., the application (411) of FIG. 4 or FIG. 5) is confirmed in the REE (or non-security mode, non-security area, or general area), the application (411) may transmit a TA execution request to a security VM manager (600) requesting the execution of a TA associated with the application (411) (operation 611). The security VM manager (600) of FIG. 6 may be a module in which the security VM manager and security VM controller described in FIG. 5 are integrated. In one embodiment, the TA execution request may include configuration information (or a configuration file) containing information about multiple security OSs in which multiple TAs associated with the application (411) can be executed. In one embodiment, the configuration information for the application (411) may include information related to multiple security OSs in which multiple TAs associated with the application (411) can be executed. In one embodiment, information related to multiple security OSs may include priorities for multiple security OSs, unique information for multiple security OSs, locations where multiple TAs are stored in multiple security OSs, locations where CAs in a REE communicating with multiple TAs are stored, and / or additional information. Since the configuration information for the application (411) has been described in FIG. 5, a redundant description thereof may be omitted here. As described in FIG. 5, the configuration information for the application (411) may be implemented in the form of a list based on the priorities of the security OSs (or S-VMs), so it should be noted that in FIG. 6, the configuration information for the application (411) is expressed as an "S-VM priority list."
[0210] In one embodiment, when the security VM manager (600) receives a TA execution request from an application (411), it may request to execute a corresponding S-VM using an SMC based on the received TA execution request (Operation 613). In one embodiment, the security VM manager (600), upon receiving a TA execution request from the application (411) requesting the execution of a TA related to the application (411), may parse the configuration information (or configuration file) for the application (411) included in the received TA execution request and execute a corresponding S-VM (or security OS) corresponding to the priorities for security OSs (Operation 615). In one embodiment, the operation to execute an S-VM may include loading an S-VM and executing the loaded S-VM (S-VM Load / Run). In one embodiment, the S-VM may correspond to a security OS. Since the configuration information for the application (411) includes information related to multiple security OSs, the security VM manager (600) may request the execution of the S-VM starting with the security OS having the highest priority among the multiple security OSs based on priority. The operation related to the execution of the security OSs and corresponding TAs based on priority may be implemented similarly or substantially identically to that described in FIG. 5, and therefore the redundant description may be omitted here.
[0211] A security VM manager (600) running the corresponding S-VM (or security OS) can enable a TA (619) associated with an application (411) to run in the corresponding S-VM (or security OS) in the TEE (617) (or security mode or security zone).
[0212] In one embodiment, the execution result of TA (619) may be transmitted to a security VM manager (600), and the security VM manager (600) may determine whether to execute an S-VM corresponding to the next priority security OS associated with the application (411) based on the execution result of TA (619). In one embodiment, if the execution result of TA (619) indicates an execution failure, the security VM manager (600) may decide to execute an S-VM corresponding to the next priority security OS associated with the application (411). In one embodiment, the execution failure of TA (619) may occur when it is impossible to execute TA (619) or when the security OS on which TA (619) is executed terminates abnormally (e.g., when the security OS terminates abnormally due to a serious error such as TEE_Panic). Since TEE_Panic has been described in FIG. 4, a redundant description thereof may be omitted here. The operation of the security VM manager (600) executing the next priority security OS and the corresponding TA can be implemented similarly or substantially identically to that described in FIG. 5, and therefore the redundant description may be omitted here.
[0213] In one embodiment, if the execution result of TA (619) indicates execution success, the security VM manager (600) may transmit the execution result of TA (619) to the application (411). The application (411) that receives the execution result of TA (619) from the security VM manager (600) may be terminated after executing normally.
[0214] FIG. 7 is a diagram illustrating the operation of executing a TA in a TEE that supports multiple security OSs according to one embodiment.
[0215] Referring to FIG. 7, the operation of executing a TA in a TEE supporting multiple security OSs described in FIG. 7 may differ from the operation of executing a TA in a TEE supporting multiple security OSs described in FIG. 5 in that it is implemented in the form of a security VM manager (600) (e.g., the security VM manager (511) of FIG. 5) and a security VM controller (e.g., the security VM controller (513) of FIG. 5) integrated therein (e.g., the security VM manager (600) of FIG. 6).
[0216] As described in FIG. 5, when an execution request for an application (411) (e.g., the application (411) of FIG. 4, FIG. 5, or FIG. 6) is confirmed in the REE (or non-security mode, non-security zone, or general zone), the application (411) may transmit a TA execution request to a security VM manager (600) requesting the execution of a TA associated with the application (411). The security VM manager (600) of FIG. 7 may be a module that integrates the security VM manager and security VM controller described in FIG. 5. In one embodiment, the TA execution request may include configuration information (or a configuration file) containing information about multiple security OSs that can execute multiple TAs associated with the application (411). In FIG. 7, the configuration information for the application (411) is represented as SVMconfig.json. As described in FIG. 5, configuration information for an application (411) can be generated using any one of the file formats, for example, XML, YML, and JSON, and FIG. 7 shows configuration information (SVMconfig.json) for an application (411) created using JSON, as described in Table 2.
[0217] In one embodiment, the configuration information for the application (411) may include information related to multiple security OSs capable of executing multiple TAs associated with the application (411). In one embodiment, the information related to the multiple security OSs may include priorities for the multiple security OSs, unique information for the multiple security OSs, locations where multiple TAs are stored in the multiple security OSs, locations where CAs in the REE that communicate with the multiple TAs are stored, and / or additional information. Since the configuration information for the application (411) has been described in FIG. 5, a redundant description thereof may be omitted here.
[0218] In one embodiment, the security VM manager (600) may need to perform the following two operations.
[0219] The first operation may be to parse configuration information (e.g., SVMconfig.json) for an application (411) and to pass the parsed information to the relevant S-VM when the relevant S-VM is executed. As described in FIG. 5, the configuration information for the application (411) may be implemented in the form of a list based on the priorities of the security OS (or S-VM), and thus the configuration information for the application (411) may be expressed as an "S-VM priority list." The security VM manager (600) may identify the security OS included in the S-VM priority list that is not installed on the electronic device (e.g., the electronic device (101) of FIG. 1) and generate an S-VM list that includes the remaining security OSs, excluding the security OS included in the S-VM priority list that is not installed on the electronic device.
[0220] The second operation may be an operation of executing an application (411) by considering security OSs based on priority, corresponding to the S-VM list. Since the operation of executing an application (411) by considering security OSs based on priority can be implemented similarly or substantially identically to that described in FIG. 5, the redundant description may be omitted here.
[0221] In one embodiment, the operation of the security VM manager (600) may be described as follows.
[0222] A security VM manager (600) that receives a TA execution request from an application (411) can, in operation 711, parse configuration information (or configuration file) for the application (411) included in the received TA execution request.
[0223] A security VM manager (600) that parses configuration information (or configuration file) for an application (411) can, in operation 713, check whether security OSs included in the S-VM priority list are installed on an electronic device. In one embodiment, the security VM manager (600) can, in operation 713, check whether CAs and TAs included in the S-VM priority list are installed on an electronic device.
[0224] In operation 715, the security VM manager (600) can generate an S-VM list based on whether the security OSs included in the S-VM priority list are installed on the electronic device and whether the CAs and TAs included in the S-VM priority list are installed on the electronic device. The security VM manager (600) can generate an S-VM list by removing from the S-VM priority list the security OSs, CAs, and TAs included in the S-VM priority list that are not installed on the electronic device.
[0225] The security VM manager (600) that created the S-VM list can, in operation 717, execute the S-VM (or security OS) having the highest priority among the security OSs included in the S-VM list and execute the corresponding TA on that security OS. Since the S-VM list contains information related to multiple security OSs, the security VM manager (600) can request the execution of the S-VM starting from the security OS having the highest priority among the multiple security OSs based on priority. The operation related to the execution of the security OSs and corresponding TAs based on priority can be implemented similarly or substantially identically to that described in FIG. 5, and therefore the redundant description may be omitted here.
[0226] A security VM manager (600) that has executed the corresponding S-VM (or security OS) may receive the execution result of the TA in operation 719. Upon receiving the execution result of the TA, the security VM manager (600) may, in operation 721, execute the S-VM corresponding to the next priority security OS associated with the application (411) or execute the application (411) based on the execution result of the TA. In one embodiment, if the execution result of the TA indicates an execution failure, the security VM manager (600) may decide to execute the S-VM corresponding to the next priority security OS associated with the application (411). In one embodiment, the execution failure of the TA may occur when it is impossible to execute the TA or when the security OS on which the TA is executed terminates abnormally (e.g., when the security OS terminates abnormally due to a serious error such as TEE_Panic). As TEE_Panic has been described in FIG. 4, the redundant description may be omitted here. The operation of the security VM manager (600) executing the next priority security OS and the corresponding TA may be implemented similarly or substantially identically to that described in FIG. 5, and therefore the redundant description may be omitted here.
[0227] In one embodiment, if the execution result of TA indicates execution success, the security VM manager (600) can transmit the execution result of TA to the application (411) so that the application (411) can be executed.
[0228] FIG. 8 is a flowchart illustrating the operation process of an electronic device according to one embodiment.
[0229] Referring to FIG. 8, in operation 811, an electronic device (e.g., the electronic device (101) of FIG. 1) (e.g., one or more processors including processing circuitry) (e.g., the processor (120) of FIG. 1) can, in operation 811, recognize a request for execution for an application running in a REE (e.g., the application (411) of FIG. 4, FIG. 5, FIG. 6, or FIG. 7). In one embodiment, the REE may correspond to a non-secure mode, a non-secure area, or a general area.
[0230] An electronic device that has confirmed a request to execute an application may, in operation 813, execute a first security OS having a first priority among a plurality of security OSs based on configuration information for the application that includes priorities of a plurality of security OSs executable by a plurality of TAs associated with the application. In one embodiment, the first priority may represent the highest priority among the priorities of the plurality of security OSs. The configuration information for the application may be implemented similarly or substantially identically to that described in FIG. 5, and thus redundant descriptions may be omitted here.
[0231] An electronic device running the first security OS can, in operation 815, run the first TA corresponding to the first security OS among the plurality of TAs in the first security OS.
[0232] The electronic device that executed the first TA can check whether the result of executing the first TA is successful in operation 817.
[0233] If, upon verification, the execution result of the first TA is a failure to execute (operation 817-No), the electronic device may, in operation 819, execute a second security OS having a second priority among the security OSs other than the first security OS among the plurality of security OSs. In one embodiment, the electronic device may, based on the fact that the execution result of the first TA is a failure to execute, identify a security OS having a priority immediately following the first priority among the plurality of security OSs, check whether the identified security OS is installed on the electronic device, and, based on the fact that the identified security OS is installed on the electronic device, set the identified security OS as the second security OS. In one embodiment, the electronic device identifies the security OS having the highest priority among the remaining security OSs, excluding the first security OS and the identified security OS, based on the fact that the identified security OS is not installed on the electronic device, checks whether the security OS having the highest priority among the remaining security OSs is installed on the electronic device, and, based on the fact that the security OS having the highest priority among the remaining security OSs is installed on the electronic device, can set the security OS having the highest priority among the remaining security OSs as the second security OS.
[0234] An electronic device running a second security OS can, in operation 821, run a second TA corresponding to the second security OS among a plurality of TAs in the second security OS.
[0235] The electronic device that executed the second TA can check whether the result of executing the second TA is successful in operation 823.
[0236] If, upon verification, the result of the execution of the second TA is successful (Operation 823-Yes), the electronic device can execute the application in Operation 825.
[0237] If, as a result of checking in operation 817, the execution result of the first TA is successful (operation 817-yes), the electronic device can proceed to operation 825 to execute the application.
[0238] If, as a result of checking in operation 823, the execution result of the second TA is an execution failure (operation 823-No), the electronic device may perform an additional operation in operation 827. The additional operation of operation 827 may be described as follows.
[0239] The electronic device can execute a third security OS having a third priority among security OSs other than the first security OS and the second security OS among multiple security OSs when the execution result of the second TA is an execution failure, execute a third TA corresponding to the third security OS among multiple TAs on the third security OS, and execute an application based on the execution result of the third TA being an execution success.
[0240] Although not separately illustrated in FIG. 8, the electronic device may refrain from executing an application and provide information indicating failure to execute an application based on the priorities of a plurality of security OSs, and based on confirming that the application is not executed after a set number of security OSs among the plurality of security OSs have been executed.
[0241] Although not separately illustrated in FIG. 8, the electronic device may refrain from executing an application and provide information indicating failure to execute an application based on the priority of a plurality of security OSs, and based on confirming that the application is not executed after at least some of the plurality of security OSs have been executed for a set period of time.
[0242] FIG. 9 is a diagram illustrating the operation of executing a TA in a TEE that supports multiple security OSs according to one embodiment.
[0243] Referring to FIG. 9, the operation of executing a TA in a TEE supporting multiple security OSs described in FIG. 9 may differ from the operation of executing a TA in a TEE supporting multiple security OSs described in FIG. 5 in that it is implemented in the form of a security VM manager (600) (e.g., the security VM manager (511) of FIG. 5) and a security VM controller (e.g., the security VM controller (513) of FIG. 5) integrated therein (e.g., the security VM manager (600) of FIG. 6 or FIG. 7).
[0244] As described in FIG. 5, when an execution request for an application (411) (e.g., the application (411) of FIG. 4, FIG. 5, or FIG. 6) is confirmed in the REE (or non-security mode, non-security area, or general area), the application (411) may transmit a TA execution request to a security VM manager (600) requesting the execution of a TA associated with the application (411). The security VM manager (600) of FIG. 9 may be a module in which the security VM manager and security VM controller described in FIG. 5 are integrated. In one embodiment, the TA execution request may include configuration information (or a configuration file) containing information about multiple security OSs in which multiple TAs associated with the application (411) can be executed. In FIG. 9, the configuration information for the application (411) is represented as an S-VM priority list.
[0245] Meanwhile, in FIG. 9, the Pre-condition may include parameters that can be considered when the application (411) is developed or when configuration information for the application (411) is generated. In one embodiment, the Pre-condition may include a TEE-TA pair, an S-VM priority, CA & TA binaries, and / or an S-VM priority list.
[0246] In one embodiment, the TEE-TA pair may include TAs that can be executed (e.g., supported) in the application (411) and TEE information (e.g., information related to a security OS or S-VM) for executing each of the TAs that can be executed in the application (411).
[0247] In one embodiment, the S-VM priority may represent the priority of TEEs (e.g., security OS or S-VM) generated based on identified TEE information when considering TEE-TA pairs. In one embodiment, the S-VM priority may be generated by considering information required to execute the S-VM, e.g., related CA, TA, and / or security OS binaries.
[0248] In one embodiment, the CA & TA binaries may include the required CA and TA binaries identified while generating S-VM priorities. In one embodiment, the required CA and TA binaries identified while generating S-VM priorities may be installed on an electronic device prior to or during the release of the application (411). In one embodiment, the CA & TA binaries may include CA and TA binaries for each of the plurality of security OSs supported by the application (411).
[0249] In one embodiment, the S-VM priority list may be installed on an electronic device prior to the release of the application (411) or prior to the release of the application (411). The S-VM priority list may correspond to configuration information for the application (411).
[0250] As an execution request for the application (411) is confirmed in the REE, in operation 911, the application (411) may call the security VM manager (600). In one embodiment, the call operation of operation 911 may correspond to a TA execution request operation that requests the execution of a TA associated with the application (411).
[0251] In operation 913, the security VM manager (600) called by the application (411) can receive configuration information for the application (411) into the security VM manager (600) through the call operation of the application (411).
[0252] The security VM manager (600) that has entered configuration information for the application (411) can load the S-VM priority list in operation 915.
[0253] The security VM manager (600) that has loaded the S-VM priority list can load the S-VM with the highest priority based on the S-VM priority list in operation 917.
[0254] A security VM manager (600) that has loaded the S-VM with the highest priority can execute CA and TA related to the S-VM in operation 919. In one embodiment, the security VM manager (600) can execute CA and TA related to the S-VM based on information included in the S-VM priority list.
[0255] The security VM manager (600) that executed the CA and TA related to the S-VM can check whether there is a TEE-related issue in operation 921. In one embodiment, the TEE-related issue may include an issue where the security OS terminates abnormally due to a serious error such as TEE_Panic. Since TEE_Panic has been described in FIG. 4, the redundant description may be omitted here.
[0256] If there are no TEE-related issues, the security VM manager (600) can check whether the execution result of TA is successful in operation 923.
[0257] If the execution result of TA is successful, the security VM manager (600) can transmit the execution result for the S-VM to the application (411), and thus the application (411) can obtain the execution result for the S-VM.
[0258] If, as a result of checking in operation 921, there is a TEE-related issue, the security VM manager (600) can check in operation 927 whether the S-VM is the last S-VM on the S-VM priority list.
[0259] If the S-VM is not the last S-VM on the S-VM priority list, the security VM manager (600) can, in operation 929, identify the S-VM corresponding to the next priority and return to operation 917 to perform the operation related to the identified S-VM.
[0260] FIG. 10 is a drawing illustrating a user interface of an electronic device executing a TA in a TEE that supports a plurality of security OSs according to one embodiment.
[0261] Referring to FIG. 10, the screen (1000) may be a screen provided (e.g., output) when there is a failure to run an application (e.g., application (411) of FIG. 4, FIG. 5, FIG. 6, FIG. 7, or FIG. 9) on an electronic device (e.g., electronic device (101) of FIG. 1) (e.g., smartphone).
[0262] As described in FIGS. 5 to 9, there may be no user interface that requires direct operation by the user of the electronic device according to the operation of the electronic device running the TA in the TEE that supports multiple security OSs. However, if the execution of the application fails due to a failure in the execution of the TA, the failure of the application execution can be prevented by providing information indicating that an error has occurred (e.g., "An error was detected during execution") as shown in the screen (1000) and information inducing an update to the latest software (e.g., "Problems may occur during subsequent execution. Please always keep the latest version. Please send logs via the Samsung Members app").
[0263] According to one embodiment of the present disclosure, a method of an electronic device (101) may include an operation of checking an execution request for an application in a rich execution environment (REE).
[0264] According to one embodiment of the present disclosure, the method may include an operation of executing a first security OS having a first priority among a plurality of security OSs based on configuration information for the application, which includes priorities of a plurality of security operating systems (OS) capable of executing a plurality of trusted applications (TA) associated with the application, based on an execution request for the application.
[0265] According to one embodiment of the present disclosure, the method may include the operation of executing a first TA corresponding to the first security OS among the plurality of TAs on the first security OS.
[0266] According to one embodiment of the present disclosure, the method may include the operation of executing a second security OS having a second priority among the security OSs other than the first security OS among the plurality of security OSs, based on the execution result of the first TA being an execution failure.
[0267] According to one embodiment of the present disclosure, the method may include the operation of executing a second TA corresponding to the second security OS among the plurality of TAs on the second security OS.
[0268] According to one embodiment of the present disclosure, the method may include an operation to execute the application based on the execution result of the second TA being successful.
[0269] According to one embodiment of the present disclosure, a TA may include an application running in a trusted execution environment (TEE).
[0270] According to one embodiment of the present disclosure, the plurality of security OSs can be executed in the TEE.
[0271] According to one embodiment of the present disclosure, configuration information for the application may include locations where the plurality of TAs are stored in the plurality of security OSs, locations where client applications (CAs) in the REE that communicate with the plurality of TAs are stored, names of the plurality of security OSs, and versions of the plurality of security OSs.
[0272] According to one embodiment of the present disclosure, configuration information for the application may include input parameters for the plurality of TAs and expected output values for the plurality of TAs.
[0273] According to one embodiment of the present disclosure, the method may include the operation of executing a third security OS having a third priority among the security OSs other than the first security OS and the second security OS, based on the execution result of the second TA being an execution failure.
[0274] According to one embodiment of the present disclosure, the method may include the operation of executing a third TA corresponding to the third security OS among the plurality of TAs on the third security OS.
[0275] According to one embodiment of the present disclosure, the method may include an operation to execute the application based on the execution result of the third TA being successful.
[0276] The electronic device according to one embodiment disclosed in this document may be of various forms. The electronic device may include, for example, a portable communication device (e.g., a smartphone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. The electronic device according to the embodiment of this document is not limited to the aforementioned devices.
[0277] One embodiment of this document and the terms used therein are not intended to limit the technical features described in this document to specific embodiments, and should be understood to include various modifications, equivalents, or substitutions of said embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of said items unless the relevant context clearly indicates otherwise. In this document, phrases such as "A or B," "at least one of A and B," "at least one of A or B," "A, B or C," "at least one of A, B and C," and "at least one of A, B, or C" may each include any one of the items listed together in the corresponding phrase, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used simply to distinguish said components from other said components and do not limit said components in any other aspect (e.g., importance or order). Where any (e.g., 1st) component is referred to as “coupled” or “connected” to another (e.g., 2nd) component, with or without the terms “functionally” or “communicationly,” it means that said any component may be connected to said other component directly (e.g., via a wire), wirelessly, or through a third component.
[0278] The term "module" as used in an embodiment of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit, for example. A module may be a component formed integrally, or a minimum unit of said component or a part thereof that performs one or more functions. For example, according to an embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).
[0279] One embodiment of the present document may be implemented as software (e.g., program (140)) comprising one or more instructions stored in a storage medium (e.g., internal memory (136) or external memory (138)) readable by a machine (e.g., electronic device (101)). For example, a processor (e.g., processor (120)) of the machine (e.g., electronic device (101)) may call at least one of the one or more instructions stored in the storage medium and execute it. This enables the machine to be operated to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code that can be executed by an interpreter. The storage medium readable by the machine may be provided in the form of a non-transitory storage medium. Here, 'non-temporary' simply means that the storage medium is a tangible device and does not contain a signal (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently and cases where it is stored temporarily.
[0280] According to one embodiment, the method according to one embodiment disclosed herein may be provided by being included in a computer program product. The computer program product may be traded between a seller and a buyer as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)) or an application store (e.g., Play Store). TM It can be distributed online (e.g., downloaded or uploaded) through ) or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created on a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.
[0281] According to one embodiment, each component (e.g., module or program) of the components described above may include a singular or multiple entities, and some of the multiple entities may be separated and placed in other components. According to one embodiment, one or more of the components or operations among the aforementioned components may be omitted, or one or more other components or operations may be added. Generally or additionally, multiple components (e.g., module or program) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the multiple components in the same or similar manner as those performed by the corresponding component among the multiple components prior to integration. According to one embodiment, operations performed by the module, program, or other components may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.
Claims
Claim 1 In an electronic device (101), one or more processors (120) including processing circuitry; The electronic device includes a memory (130) for storing instructions, wherein when the instructions are executed individually or collectively by one or more processors, the electronic device: checks for an execution request for an application in a rich execution environment (REE); based on the execution request for the application, based on configuration information for the application including priorities of multiple security operating systems (OS) capable of executing multiple trusted applications (TAs) associated with the application, executes a first security OS having a first priority among the multiple security OSs; executes a first TA corresponding to the first security OS among the multiple TAs in the first security OS; based on the execution result of the first TA being an execution failure, executes a second security OS having a second priority among the multiple security OSs other than the first security OS; and executes a second TA corresponding to the second security OS among the multiple TAs in the second security OS. and based on the execution result of the second TA being successful, it causes the application to be executed, wherein the TA includes an application running in a trusted execution environment (TEE), and the plurality of security OSs are the electronic device running in the TEE. Claim 2 The electronic device according to claim 1, wherein the configuration information for the application comprises: locations where the plurality of TAs are stored in the plurality of security OSs, locations where client applications (CAs) in the REE that communicate with the plurality of TAs are stored, names of the plurality of security OSs, and versions of the plurality of security OSs. Claim 3 In paragraph 2, the configuration information for the application comprises: input parameters for the plurality of TAs, and expected output values for the plurality of TAs, said electronic device. Claim 4 In any one of claims 1 to 3, when the instructions are executed individually or collectively by the one or more processors, the electronic device: executes a third security OS having a third priority among the security OSs other than the first security OS and the second security OS among the plurality of security OSs based on the execution result of the second TA being an execution failure; executes a third TA corresponding to the third security OS among the plurality of TAs on the third security OS; and causes the application to be executed based on the execution result of the third TA being an execution success. Claim 5 In any one of claims 1 to 4, the electronic device, when the instructions are executed individually or collectively by the one or more processors, at least as part of the operation of executing the second security OS based on the result of executing the first TA being an execution failure: identifying a security OS having a priority immediately following the first priority among the plurality of security OSs based on the result of executing the first TA being an execution failure, identifying whether the identified security OS is installed on the electronic device, and causing the identified security OS to be set as the second security OS based on the fact that the identified security OS is installed on the electronic device. Claim 6 In paragraph 5, the electronic device, when the instructions are executed individually or collectively by the one or more processors, causes the electronic device to execute the second security OS based on the execution result of the first TA being an execution failure, at least as part of the operation of executing the second security OS: based on the fact that the identified security OS is not installed on the electronic device, identify the security OS having the highest priority among the plurality of security OSs other than the first security OS and the identified security OS, check whether the security OS having the highest priority among the remaining security OSs is installed on the electronic device, and, based on the fact that the security OS having the highest priority among the remaining security OSs is installed on the electronic device, cause the security OS having the highest priority among the remaining security OSs to be set as the second security OS. Claim 7 In any one of claims 1 to 6, the electronic device, when the instructions are executed individually or collectively by the one or more processors, causes the electronic device to: refrain from executing the application based on the priority of the plurality of security OSs, after executing a set number of security OSs among the plurality of security OSs, and confirming that the application is not executed, and to provide information indicating a failure to execute the application. Claim 8 In any one of claims 1 to 6, the electronic device, when the instructions are executed individually or collectively by the one or more processors, causes the electronic device to: refrain from executing the application based on the priority of the plurality of security OSs, after executing at least some of the plurality of security OSs for a set time, and confirming that the application is not executed, and to provide information indicating a failure to execute the application. Claim 9 In a storage medium storing at least one instruction readable by a computer, the at least one instruction causes the electronic device (101) to perform at least one operation when executed individually or collectively by one or more processors (120) including processing circuitry of the electronic device (101), the at least one operation being: an operation of confirming an execution request for an application in a rich execution environment (REE); and an operation of executing a first security OS having a first priority among the plurality of security OSs based on configuration information for the application, which includes priorities of a plurality of security operating systems (OS) capable of executing a plurality of trusted applications (TA) associated with the application, based on the execution request for the application. The method comprises: an operation of executing a first TA corresponding to the first security OS among the plurality of TAs on the first security OS; an operation of executing a second security OS having a second priority among the security OSs other than the first security OS among the plurality of security OSs based on the execution result of the first TA being an execution failure; an operation of executing a second TA corresponding to the second security OS among the plurality of TAs on the second security OS; and an operation of executing the application based on the execution result of the second TA being an execution success, wherein the TA includes an application executed in a trusted execution environment (TEE), and the plurality of security OSs are the storage medium executed in the TEE. Claim 10 In claim 9, the configuration information for the application comprises: locations where the plurality of TAs are stored in the plurality of security OSs, locations where client applications (CAs) in the REE that communicate with the plurality of TAs are stored, names of the plurality of security OSs, and versions of the plurality of security OSs, the storage medium. Claim 11 In claim 10, the configuration information for the application comprises: input parameters for the plurality of TAs, and expected output values for the plurality of TAs, the storage medium comprising. Claim 12 In any one of claims 9 to 11, the at least one operation comprises: an operation of executing a third security OS having a third priority among the security OSs other than the first security OS and the second security OS among the plurality of security OSs based on the execution result of the second TA being an execution failure; an operation of executing a third TA corresponding to the third security OS among the plurality of TAs on the third security OS; and an operation of executing the application based on the execution result of the third TA being an execution success. Claim 13 In any one of claims 9 to 12, the operation of executing the second security OS based on the execution result of the first TA being an execution failure comprises: an operation of identifying a security OS having a priority immediately following the first priority among the plurality of security OSs based on the execution result of the first TA being an execution failure; an operation of identifying whether the identified security OS is installed on the electronic device; and an operation of setting the identified security OS as the second security OS based on the fact that the identified security OS is installed on the electronic device. Claim 14 In claim 13, the operation of executing the second security OS based on the execution result of the first TA being an execution failure comprises: an operation of identifying the security OS having the highest priority among the remaining security OSs other than the first security OS and the identified security OS, based on the fact that the identified security OS is not installed on the electronic device; an operation of identifying whether the security OS having the highest priority among the remaining security OSs is installed on the electronic device; and an operation of setting the security OS having the highest priority among the remaining security OSs as the second security OS based on the fact that the security OS having the highest priority among the remaining security OSs is installed on the electronic device. Claim 15 In any one of claims 9 to 14, the at least one operation comprises: an operation of refraining from executing the application based on confirming that the application is not executed after executing a set number of security OSs among the plurality of security OSs based on the priorities of the plurality of security OSs; and an operation of providing information indicating a failure to execute the application. Claim 16 In any one of claims 9 to 14, the at least one operation comprises: an operation of refraining from executing the application based on confirming that the application is not executed after executing at least some of the plurality of security OSs for a set time based on the priorities of the plurality of security OSs; and an operation of providing information indicating a failure to execute the application. Claim 17 A method of an electronic device (101), comprising: an operation of confirming an execution request for an application in a rich execution environment (REE); an operation of executing a first security OS having a first priority among a plurality of security OSs based on configuration information for the application, which includes priorities of a plurality of security operating systems (OS) capable of executing a plurality of trusted applications (TAs) associated with the application based on the execution request for the application; an operation of executing a first TA corresponding to the first security OS among the plurality of TAs in the first security OS; an operation of executing a second security OS having a second priority among security OSs other than the first security OS among the plurality of security OSs based on the execution result of the first TA being an execution failure; and an operation of executing a second TA corresponding to the second security OS among the plurality of TAs in the second security OS. and based on the execution result of the second TA being successful, the method includes executing the application, wherein the TA includes an application executed in a trusted execution environment (TEE), and the plurality of security OSs are executed in the TEE. Claim 18 In claim 17, the configuration information for the application comprises: locations where the plurality of TAs are stored in the plurality of security OSs, locations where client applications (CAs) in the REE that communicate with the plurality of TAs are stored, names of the plurality of security OSs, and versions of the plurality of security OSs. Claim 19 In paragraph 18, the configuration information for the application comprises: input parameters for the plurality of TAs, and expected output values for the plurality of TAs. Claim 20 The method according to any one of claims 17 to 19, comprising: an operation to execute a third security OS having a third priority among the security OSs other than the first security OS and the second security OS among the plurality of security OSs, based on the execution result of the second TA being an execution failure; an operation to execute a third TA corresponding to the third security OS among the plurality of TAs on the third security OS; and an operation to execute the application based on the execution result of the third TA being an execution success.