KR20240045934A - Electronic device including secure element and method of operating the same - Google Patents

Abstract

Disclosed is an electronic device including an application processor and a security element (SE) including the processor and memory. The processor receives an installation command including installation data of the applet from the application processor, installs the applet based on the installation command, stores the installation data and execution data of the applet in the memory, and installs the applet. store user data associated with the memory in the memory, receive a reset command for the secure element from the application processor, and in response to the reset command, retain the installation data and/or the executable data and remove the user data. It can be configured to do so.

Description

Electronic device including a security element and method of operating the same {ELECTRONIC DEVICE INCLUDING SECURE ELEMENT AND METHOD OF OPERATING THE SAME}

Embodiments of the present disclosure relate to an electronic device including a secure element (SE) and a method of operating the same.

Due to the development of wireless communication technology and security technology, the functions and services provided by personal electronic devices such as smartphones are gradually expanding. Electronic devices may include multiple applications to provide various functions and services.

To protect personal information, electronic devices can use security functions to provide services that require security. The electronic device includes a secure element (SE) (e.g., an embedded SE (eSE)), through which the user experiences a service that requires high security (e.g., a digital key, electronic banking, or electronic payment). can be provided to. The security element may include one or multiple applets, and may provide various services to the user through execution of the applets.

An electronic device according to an embodiment may include an application processor and a security element including the processor and memory. The processor may be configured to receive a first installation command including installation data of the first applet from the application processor. The processor may be configured to install the first applet based on the first installation command. The processor may be configured to store the installation data and execution data of the first applet in the memory. The processor may be configured to store first user data associated with the first applet in the memory. The processor may be configured to receive a reset command for the secure element from the application processor. The processor may be configured to maintain the installation data and/or the execution data and remove the first user data in response to the reset command.

A method of operating an electronic device according to an embodiment may include receiving a first installation command including installation data of a first applet. The method may include installing the first applet based on the first installation command. The method may include storing the installation data and execution data of the first applet in memory. The method may include storing first user data associated with the first applet in the memory. The method may include receiving a reset command for the secure element. The method may include maintaining the installation data and the execution data and removing the first user data in response to the reset command.

According to one embodiment, a non-transitory computer-readable storage medium storing one or more programs, wherein the one or more programs, when executed by at least one processor of an electronic device, cause the electronic device to: include installation data of a first applet; Receive a first installation command, install the first applet based on the first installation command, store the installation data and execution data of the first applet in a memory, and determine a first user associated with the first applet. store data in the memory, receive a reset command for the secure element from the application processor, and in response to the reset command, retain the installation data and/or the executable data and remove the first user data. It may contain configuring commands.

1 is a block diagram of an electronic device in a network environment according to various embodiments.
FIG. 2 is a diagram for explaining the configuration of an electronic device including a security element, according to an embodiment.
FIG. 3 is a diagram for explaining the configuration of an electronic device that stores user data of a security element according to an embodiment.
FIG. 4 is a diagram illustrating a data storage area of a security element according to an embodiment.
Figure 5 is a diagram for explaining the operation of a security element that removes user data according to an embodiment.
FIG. 6 is a diagram illustrating the operation of a security element that removes user data through an applet according to an embodiment.
Figure 7 is a flowchart for explaining the operation of a security element according to an embodiment.
FIG. 8 is a flowchart illustrating the operation of a security element that removes user data through an applet according to an embodiment.
Figure 9 shows a signal flow diagram illustrating a procedure for removing user data of a secure element according to one embodiment.
Figure 10 shows a signal flow diagram illustrating a procedure for removing data from a secure element according to one embodiment.
Figure 11 shows a signal flow diagram illustrating a procedure for removing user data of a secure element through an applet according to one embodiment.
Figure 12 shows a signal flow diagram explaining a procedure for changing the reset type according to one embodiment.

1 is a block diagram of an electronic device 101 in a network environment 100, according to various embodiments.

Referring to FIG. 1, in the network environment 100, the electronic device 101 communicates with the electronic device 102 through a first network 198 (e.g., a short-range wireless communication network) or a second network 199. It is possible to communicate with the electronic device 104 or the server 108 through (e.g., a long-distance wireless communication network). According to one embodiment, the electronic device 101 may communicate with the electronic device 104 through the server 108. According to one embodiment, the electronic device 101 includes a processor 120, a memory 130, an input module 150, an audio output module 155, a display module 160, an audio module 170, and a 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 may include an antenna module 197. In some embodiments, at least one of these components (eg, the connection terminal 178) may be omitted or one or more other components may be added to the electronic device 101. In some embodiments, some of these components (e.g., sensor module 176, camera module 180, or antenna module 197) are integrated into one component (e.g., display module 160). It can be.

The processor 120, for example, executes software (e.g., program 140) to operate at least one other component (e.g., hardware or software component) of the electronic device 101 connected to the processor 120. It can be controlled and various data processing or calculations can be performed. According to one embodiment, as at least part of data processing or computation, the processor 120 stores commands or data received from another component (e.g., sensor module 176 or communication module 190) in volatile memory 132. The commands or data stored in the volatile memory 132 can be processed, and the resulting data can be stored in the non-volatile memory 134. According to one embodiment, the processor 120 includes 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 (e.g., a graphics processing unit, a neural network processing unit ( It may include 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 a secondary processor 123, the secondary processor 123 may be set to use lower power than the main processor 121 or be specialized for a designated function. You can. The auxiliary processor 123 may be implemented separately from the main processor 121 or as part of it.

The auxiliary processor 123 may, for example, act on behalf of the main processor 121 while the main processor 121 is in an inactive (e.g., sleep) state, or while the main processor 121 is in an active (e.g., application execution) state. ), together with the main processor 121, at least one of the components of the electronic device 101 (e.g., the display module 160, the sensor module 176, or the communication module 190) At least some of the functions or states related to can be controlled. According to one embodiment, co-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). there is. According to one embodiment, the auxiliary processor 123 (eg, neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. Artificial intelligence models can be created through machine learning. For example, such learning may be performed in the electronic device 101 itself, where artificial intelligence is performed, or may be performed through a separate server (e.g., server 108). Learning algorithms may include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but It is not limited. An artificial intelligence model may include multiple artificial neural network layers. Artificial neural networks include deep neural network (DNN), convolutional neural network (CNN), recurrent neural network (RNN), restricted boltzmann machine (RBM), belief deep network (DBN), bidirectional recurrent deep neural network (BRDNN), It may be one of deep Q-networks or a combination of two or more of the above, but is not limited to the examples described above. In addition to hardware structures, artificial intelligence models may additionally or alternatively include software structures.

The memory 130 may store various data used by at least one component (eg, the processor 120 or the sensor module 176) of the electronic device 101. Data may include, for example, input data or output data for software (e.g., program 140) and instructions related thereto. Memory 130 may include volatile memory 132 or non-volatile memory 134.

The program 140 may be stored as software in the memory 130 and may include, for example, an operating system 142, middleware 144, or application 146.

The input module 150 may receive commands or data to be used in a component of the electronic device 101 (e.g., the processor 120) from outside the electronic device 101 (e.g., a user). The input module 150 may include, for example, a microphone, mouse, keyboard, keys (eg, buttons), or digital pen (eg, stylus pen).

The sound output module 155 may output sound signals to the outside of the electronic device 101. The sound output module 155 may include, for example, a speaker or a receiver. Speakers can be used for general purposes such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. According to one embodiment, the receiver may be implemented separately from the speaker or as part of it.

The display module 160 can visually provide information to the outside of the electronic device 101 (eg, a user). The display module 160 may include, for example, a display, a hologram device, or a projector, and a control circuit for controlling the 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 force generated by the touch.

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 acquires sound through the input module 150, the sound output module 155, or an external electronic device (e.g., directly or wirelessly connected to the electronic device 101). Sound may be output through the electronic device 102 (e.g., speaker or headphone).

The sensor module 176 detects the operating state (e.g., power or temperature) of the electronic device 101 or the external environmental state (e.g., user state) and generates an electrical signal or data value corresponding to the detected state. can do. According to one embodiment, the sensor module 176 includes, for example, a gesture sensor, a gyro sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, It may include a temperature sensor, humidity sensor, or light sensor.

The interface 177 may support one or more designated protocols that can be used to connect the electronic device 101 directly or wirelessly with an external electronic device (eg, the electronic device 102). 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.

The connection terminal 178 may include a connector through which the electronic device 101 can be physically connected to an external electronic device (eg, the 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 (eg, a headphone connector).

The haptic module 179 can convert electrical signals into mechanical stimulation (e.g., vibration or movement) or electrical stimulation 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 electrical stimulation device.

The camera module 180 can capture still images and moving images. According to one embodiment, the camera module 180 may include one or more lenses, image sensors, image signal processors, or flashes.

The power management module 188 can manage power supplied to the electronic device 101. According to one embodiment, the power management module 188 may be implemented as at least a part of, for example, a power management integrated circuit (PMIC).

The battery 189 may 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.

Communication module 190 is configured to provide a direct (e.g., wired) communication channel or wireless communication channel between electronic device 101 and an external electronic device (e.g., electronic device 102, electronic device 104, or server 108). It can support establishment and communication through established communication channels. Communication module 190 operates independently of processor 120 (e.g., an application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module 190 is a wireless communication module 192 (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 194 (e.g., : LAN (local area network) communication module, or power line communication module) may be included. Among these communication modules, the corresponding communication module is a first network 198 (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network 199 (e.g., legacy It may communicate with an external electronic device 104 through a telecommunication network such as a cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., LAN or WAN). These various types of communication modules may be integrated into one component (e.g., a single chip) or may be implemented as a plurality of separate components (e.g., multiple chips). The wireless communication module 192 uses subscriber information (e.g., International Mobile Subscriber Identifier (IMSI)) stored in the subscriber identification module 196 within a communication network such as the first network 198 or the second network 199. The electronic device 101 can be confirmed or authenticated.

The wireless communication module 192 may support 5G networks after 4G networks and next-generation communication technologies, for example, NR access technology (new radio access technology). NR access technology provides high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimization of terminal power and access to multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low latency). -latency communications)) can be supported. The wireless communication module 192 may support high frequency bands (eg, mmWave bands), for example, to achieve high data rates. The wireless communication module 192 uses various technologies to secure performance in high frequency bands, for example, beamforming, massive array multiple-input and multiple-output (MIMO), and full-dimensional multiplexing. It can support technologies such as input/output (FD-MIMO: full dimensional MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module 192 may support various requirements specified in the electronic device 101, an external electronic device (e.g., electronic device 104), or a network system (e.g., second network 199). According to one embodiment, the wireless communication module 192 supports Peak data rate (e.g., 20 Gbps or more) for realizing eMBB, loss coverage (e.g., 164 dB or less) for realizing mmTC, or U-plane latency (e.g., 164 dB or less) for realizing URLLC. Example: Downlink (DL) and uplink (UL) each of 0.5 ms or less, or round trip 1 ms or less) can be supported.

The antenna module 197 may transmit or receive signals or power to or from the outside (eg, an external electronic device). According to one embodiment, the antenna module 197 may include an antenna including a radiator made of a conductor or a conductive pattern formed on a substrate (eg, PCB). According to one embodiment, the antenna module 197 may include a plurality of antennas (eg, an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network such as the first network 198 or the second network 199 is connected to the plurality of antennas by, for example, the communication module 190. can be selected Signals or power may be transmitted or received between the communication module 190 and an external electronic device through the at least one selected antenna. According to some embodiments, in addition to the radiator, other components (eg, radio frequency integrated circuit (RFIC)) may be additionally formed as part of the antenna module 197.

According to various embodiments, the antenna module 197 may form a mmWave antenna module. According to one embodiment, a mmWave antenna module includes: a printed circuit board, an RFIC disposed on or adjacent to a first side (e.g., bottom side) of the printed circuit board and capable of supporting a designated high frequency band (e.g., mmWave band); And a plurality of antennas (e.g., array antennas) disposed on or adjacent to the second side (e.g., top or side) of the printed circuit board and capable of transmitting or receiving signals in the designated high frequency band. can do.

At least some of the components are connected to each other through a communication method between peripheral devices (e.g., bus, general purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI)) and signal ( (e.g. commands or data) can be exchanged with each other.

According to one embodiment, commands or data may be transmitted or received between the electronic device 101 and the external electronic device 104 through the server 108 connected to the second network 199. Each of the external electronic devices 102 or 104 may be of the same or different type as the electronic device 101. According to one embodiment, all or part of the operations performed in the electronic device 101 may be executed in one or more of the external electronic devices 102, 104, or 108. For example, when the electronic device 101 needs to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device 101 may perform the function or service instead of executing the function or service on its own. Alternatively, or additionally, one or more external electronic devices may be requested to perform at least part of the function or service. One or more external electronic devices that have received the request may execute at least part of the requested function or service, or an 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 process the result as is or additionally and provide it as at least part of a response to the request. For this purpose, for example, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology can be used. The electronic device 101 may provide an ultra-low latency service using, for example, distributed computing or mobile edge computing. In another embodiment, the external electronic device 104 may include an Internet of Things (IoT) device. Server 108 may be an intelligent server using machine learning and/or neural networks. According to one embodiment, the external electronic device 104 or server 108 may be included in the second network 199. The electronic device 101 may be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

FIG. 2 is a diagram for explaining the configuration of an electronic device including a security element, according to an embodiment.

Referring to FIG. 2, the electronic device 200 (e.g., the electronic device 101 of FIG. 1) includes an application processor (AP) 202 (e.g., the processor 120 of FIG. 1) and a security element ( 210), and the security element 210 may include a processor 212 and memory 214. In one embodiment, the application processor 202 may include an application processor of the electronic device 200. In one embodiment, the application processor 202 may execute an application that can communicate with the secure element 210. The application processor 202 may communicate with the security element 210 through execution of the application.

In one embodiment, security element 210 may include an embedded security element (eSE). The security element 210 may include a chip designed to securely store data, securely process data, and protect against unauthorized access to enable secure communication with external electronic devices (not shown). there is. Processor 212 within secure element 210 may store confidential data and/or cryptographic data in memory 214 and may execute restricted applications (e.g., applets). It can be run. In one embodiment, processor 212 may execute payment applets that require a high level of security and may provide a trusted user interface that can securely transmit electronic signatures or personal information.

Processor 212 may store applets (e.g., installation data and/or executable data) directly in memory 214 and may filter access to the applets. Additionally, the processor 212 can store data (eg, user data) generated through execution of the applets in the memory 214 and keep the user data safe.

The application processor 202 may provide a reset function (e.g., factory reset, hard reset, or master reset) to restore the electronic device 200 to its initial system state by removing information stored in the electronic device 200. . In one embodiment, the application processor 202 may perform a factory reset in response to a user input or a reset command from a server (eg, a service provider server). Factory reset may include removing all data, settings, and applications stored in the electronic device 200.

In one embodiment, due to the characteristics of the security element 210, the application processor 202 cannot select data to be removed by accessing the memory 214 of the security element 210. When all contents (e.g., installation data, execution data, and user data) stored in the security element 210 are removed through a factory reset, the electronic device 200 (e.g., the application processor 202) is stored in the security element 210. It may take a lot of time to restart the security element 210 because the necessary applets of 210 must be reinstalled. In one embodiment, the memory 214 of the secure element 210 may include data related to device booting or applet execution, as well as data related to functions required by a service provider (e.g., a telecommunications carrier), such data needs to be maintained even during factory reset.

Embodiments of the present disclosure may retain some data (e.g., installation data and/or execution data) and remove certain data (e.g., user data) of the data stored in the secure element 210.

Embodiments of the present disclosure may retain some of the user data stored in the secure element 210 and remove certain user data (e.g., data associated with a payment applet, or digital key).

Embodiments of the present disclosure can shorten the restart time of the electronic device 200 by using data remaining in the security element 210 after factory reset.

FIG. 3 is a diagram for explaining the configuration of an electronic device that stores user data of a security element according to an embodiment.

Referring to FIG. 3, the processor 212 of the security element 210 includes an operating system (OS) (e.g., eSE OS) 302 and a factory reset application that processes a reset command. FRA) (304). Although not shown, processor 212 may execute one or more applets installed on secure element 210 (eg, a first applet and a second applet). The memory 214 of the security element 210 is one of a supplementary security domain (SSD) (e.g., SSD1) 314, a data storage area 318, or an optional database (DB) 312. It can contain at least one.

The auxiliary security area 314 may include installation data and execution data of one or more applets (eg, a first applet and a second applet) installed in the security element 210. The installation data may include an installation file, for example an executable load file (ELF). The executable data may include, for example, an executable file. In one embodiment, the auxiliary security area 314 may store execution data of the first applet (eg, APP1) and execution data of the second applet (eg, APP2). In one embodiment, the secondary security area 314 may include installation data of a first applet (eg, ELF1) and installation data of a second applet (eg, ELF2). In one embodiment, the secondary secure area 314 is a storage area (e.g., for storing related data (e.g., execution data (APP2) and installation data (ELF2)) of at least one specified applet (e.g., a second applet)). For example, it may include SSD2) (316).

The data storage area 318 is data related to one or more applets (e.g., a first applet and a second applet) installed in the security element 210 (e.g., data generated by the execution of each applet and/or or user data associated with each applet). In one embodiment, the data storage area 318 may store first user data (DATA1) related to the first applet and user data (DATA2) related to the second applet.

When performing a factory reset, the operating system 302 may use the FRA 304 and the option DB 312 to remove designated user data (e.g., user data within the designated area) within the data storage area 318. . FRA 304 may be configured to manage factory reset of secure element 210 . The FRA 304 may receive a reset command indicating a factory reset from the application processor 202, process the factory reset based on the reset command, and send the factory reset processing result to the application processor 202. You can report.

Option DB 312 removes related data (e.g., installation data, execution data, and/or user data) for each of the applets installed in the security element 210 when processing a factory reset in the security element 210. You can store a reset type that indicates the method of operation. The reset type may indicate whether to remove all data in the memory 214 related to applets, some designated data (for example, all user data), or some designated user data at the time of factory reset.

In one embodiment, the reset type may include at least one of a first option, a second option, a third option, or a fourth option. The first option may mean retaining all associated data, including the applet's installation data, execution data and/or user data. The second option may mean removing all user data except the applet's installation data and/or execution data. The third option may mean removing some of the user data of the applet (for example, user data specified by the applet). A fourth option may mean removing all associated data, including the applet's installation data, execution data and/or user data.

For an applet (e.g., the first applet) set to the first option, the processor 212 maintains the installation data (ELF1), execution data (APP1), and user data (DATA1) of the first applet upon factory reset. You can.

For an applet (e.g., a second applet) set to the second option, the processor 212 stores user data (DATA2) generated by the second applet while executing the second applet in a designated area in the data storage area 318. It can be stored in a storage area (for example, the second data area 408), and the user data (DATA2) from the second data area 408 can be removed based on a factory reset. Installation data (ELF1), execution data (APP1), and user data (DATA1) associated with an applet (e.g., the first applet) that is not set to the second option, and installation data (ELF2) and execution data associated with the second applet The data (APP2) is not removed and can be maintained after factory reset. In one embodiment, the processor 212 may initialize the life cycle state of the installation data (ELF2) and execution data (APP2) of the second applet upon factory reset.

For an applet (e.g., a second applet) set to the third option, the processor 212 stores the user data (DATA2) generated by the second applet while executing the second applet in the designated data storage area 318. It may be stored in a storage area (for example, general data area 404). The second applet may include a function (eg, initialization function) to delete its user data based on a factory reset. The processor 212 may execute the second applet based on a factory reset and remove the user data (DATA2) of the second applet. Installation data (ELF1), execution data (APP1), and user data (DATA1) associated with an applet (e.g., the first applet) that is not set to the second or third option, and installation data (DATA1) associated with the second applet ( ELF2) and executable data (APP2) are not removed and can be retained after factory reset. In one embodiment, the processor 212 may initialize the life cycle state of the installation data (ELF2) and execution data (APP2) of the second applet upon factory reset.

For an applet set to the fourth option (e.g., a third applet: not shown), the processor 212 provides installation data (ELF3), execution data (APP3), and user data of the third applet in response to a factory reset. (DATA3) can be removed altogether.

The option DB 312 may store a reset type for each applet (eg, a first applet, a second applet, or a third applet) installed in the security element 210. In one embodiment, the reset type indicating the data removal method for factory reset is input to the security element 210 (e.g., FRA 304) through an installation command provided from the application processor 202 during installation of each applet. It can be. In one embodiment, the installation command may include information (e.g., an option tag in installation parameters) indicating the type of reset specified by the developer of each applet or required by the service provider server. In one embodiment, the FRA 304 may receive information indicating a change in the reset type from the application processor 202 after the applet is installed. The FRA 304 may store the changed reset type in the option DB 312 through the operating system 302.

When a reset command instructing a factory reset is received from the application processor 202 to the security element 210 (e.g., the FRA 304), the FRA 304 receives the command from the option DB 312 via the operating system 302. The reset type of each applet can be read. The operating system 302 may process (e.g., remove) related data (e.g., at least one of installation data, execution data, or user data) of each applet according to the option indicated by the reset type.

Table 1 below shows an example of reset types stored in the option DB 312.

No. AID Reset Type Associated Command One A001122 - 2 A00BBCC Data Clear X {B4, 00, 01} 3 A005577 All Clear O

In one embodiment, the option DB 312 may store an applet ID (AID) and reset type fields that identify each applet. In one embodiment, the reset type field may be set to 'Data Clear' or 'All Clear'. As an example, the reset type may not be specified for an applet with AID=A001122 (e.g., the first applet), and the processor 212 may store all related data (e.g., installation data, execution data) of the applet upon factory reset. and/or user data). In one embodiment, for an applet with AID=A00BBCC (e.g., a second applet), the reset type is 'Data Clear', which means removing user data except installation data and/or execution data (e.g., a second option or a third option), and the processor 212 may remove user data excluding installation data and/or execution data of the applet upon factory reset.

In one embodiment, the option DB 312 provides a command (for example, a command) instructing an initialization function of the second applet upon factory reset for an applet (e.g., a second applet) set to 'Data Clear'. For example, {B4, 00, 01}) may be further included. In one embodiment, the initialization function according to the command may include removing user data from the data storage area 318 by the second applet. In one embodiment, the initialization function according to the command may include selecting at least some user data to be removed by the second applet and removing the selected user data from the data storage area 318. The command may be defined in advance by the owner of the second applet. The processor 212 may notify the second applet to perform an initialization function based on the command upon factory reset, and the second applet may directly remove its user data (for example, at least some user data). You can.

In one embodiment, the option DB 312 stores the applet's associated data (e.g., installation data, execution data, and/or An "Associated" field indicating whether to remove all user data may be further included. If the "Associated" field is set to YES (e.g., 'O'), the processor 212 may remove all associated data, including installation data, execution data, and user data, of the applet upon factory reset.

FIG. 4 is a diagram illustrating a data storage area of a security element according to an embodiment.

Referring to FIG. 4, the memory 214 of the security element 210 may include a data storage area 318, and the data storage area 318 includes a system area 402 and a normal data area ( 404), a first data area 406, a second data area 408, a package area 410, and a free area 412.

In one embodiment, the first data area 406 may be configured to store user data (e.g., user data (DATA1) associated with the first applet) that is designated to be retained after a factory reset. In one embodiment, the second data area 408 may be configured to store user data (e.g., user data (DATA2) associated with the second applet) that is designated to be removed upon factory reset. In one embodiment, the second data area 406 is an applet (e.g., a second data area) set to 'All Clear' (e.g., the fourth option) or 'Data Clear' (e.g., the second or third option). Applet) user data can be saved. In one embodiment, an applet (e.g., a second applet including an initialization function) set to 'Data Clear' (e.g., a third option) and specified by a command stored in the option DB 312 may store its user data. Can be stored in the general data area 404 or the second data area 408.

In addition to factory reset, the processor 212 may use the first data area 406 and the second data area 408 in the same manner. When a factory reset is instructed by the application processor 202, the processor 212 maintains the data (for example, user data of at least one applet) stored in the first data area 406 and stores the data in the second data area 408. Stored data (e.g. user data of at least one applet) can be removed. In one embodiment, the processor 212 may store the user data of the applet set to 'Data Clear' in the second data area 408 based on the reset type stored in the option DB 312. In one embodiment, the processor 212 removes the installation data and/or execution data of the applet set to 'All Clear' from the auxiliary security area 314 based on the reset type stored in the option DB 312, and removes the applet's installation data and/or execution data from the auxiliary security area 314. User data may be removed from the second data area 408 of the data storage area 318.

In one embodiment, the processor 212 may dynamically adjust the sizes of the first data area 406 and the second data area 408. The processor 212 can control the first data area 406 and the second data area 408 so that incorrect data does not occupy space, and unnecessary empty space is created in the second data area 408 due to the removed data. To prevent this from being wasted, the sizes of each of the first data area 406 and the second data area 408 can be adjusted.

Figure 5 is a diagram for explaining the operation of a security element that removes user data according to an embodiment.

Referring to FIG. 5 , in operation 502, the security element 210 (eg, FRA 304) may receive a reset command indicating a factory reset from the application processor 202 of the electronic device 200. In one embodiment, the application processor 202 includes a software module (e.g., an eSE factory reset privileged module) capable of processing a factory reset of the security element 210, and the software module The reset command can be transmitted to the security element 210.

In operation 504, the secure element 210 (e.g., FRA 304) may transmit the reset command to the operating system 302. In operation 506, the operating system 302 may obtain an option indicating the reset type of each applet from the option DB 312.

In operation 508, the operating system 302 may remove data from the data storage area 318 based on the obtained option. For an applet (e.g. a second applet) set to the second option (e.g. 'Data Clear'), the operating system 302 stores installation data (ELF2) and execution data (APP2) in the secondary secure area 314. User data (eg, DATA2) stored in the second data area 408 of the data storage area 318 can be removed without proceeding with data removal. Since the installation data (ELF2) and execution data (APP2) of the second applet are maintained after factory reset, the security element 210 can install the second applet without the need to reinstall the installation data (ELF2) and execution data (APP2). You can use it right away.

The operating system 302 may confirm that the user data (eg, DATA2) has been removed from the data storage area 318. In one embodiment, a data removal result may be received from the data storage area 318. In operation 510, the operating system 302 may transmit a response indicating the result of data removal from the data storage area 318 to the FRA 304. In operation 512, the FRA 304 may transmit the response to the application processor 202.

FIG. 6 is a diagram illustrating the operation of a security element that removes user data through an applet according to an embodiment.

Referring to FIG. 6 , in operation 602, the security element 210 (eg, FRA 304) may receive a reset command indicating a factory reset from the application processor 202 of the electronic device 200. In operation 604, the secure element 210 (e.g., FRA 304) may transmit the reset command to the operating system 302. In operation 606, the operating system 302 may obtain an option indicating the reset type of each applet from the option DB 312. The operating system 302 may not directly proceed with data removal for an applet (e.g., a second applet) set to the third option (e.g., 'Data Clear' + initialization function).

At operation 608a, the operating system 302 may request the FRA 304 to direct the initialization function of the second applet. In operation 608b, the FRA 304 may transmit a reset notification to request an initialization function to the second applet using a data removal application programming interface (API). In operation 610, the second applet may directly remove user data that requires initialization among user data in the data storage area 318 based on the data removal API. In one embodiment, the second applet supports an initialization function, and FRA 304 may call the initialization function of the second applet to remove user data specified by the second applet. In one embodiment, the second applet may distinguish between user data to keep and user data to remove, and may remove the user data in response to a reset notification from FRA 304.

The operating system 302 can confirm that the user data (eg, DATA2) is stored in the data storage area 318 directly from the data storage area 318 or through the second applet. In operation 612, the operating system 302 may transmit a response indicating the result of data removal from the data storage area 318 to the FRA 304. In operation 614, FRA 304 may transmit the response to the application processor 202.

Figure 7 is a flowchart for explaining the operation of a security element according to an embodiment. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or the order may be changed. At least one of the operations described below may be executed by the processor 212 of the secure element 210.

Referring to FIG. 7, in operation 705, the security element 210 (eg, processor 212) may receive an applet installation command. In one embodiment, the installation command may include installation data (eg, ELF) of the applet and may be received from the application processor 202. In operation 710, secure element 210 (e.g., processor 212) may store the installation data in memory 214 (e.g., auxiliary secure area 314). In operation 715, the security element 210 (e.g., processor 212) may install the applet based on the installation data. Execution data (e.g., executable file) of the applet may be stored in memory 214 (e.g., auxiliary security area 314). In one embodiment, operation 715 may be executed before operation 710.

In operation 720, the security element 210 (e.g., processor 212) identifies the reset type of the applet based on the installation parameters included in the installation command and sets the reset type to memory 214 (e.g., option It can be stored in DB (312)). In one embodiment, the installation command may include an installation parameter having an option tag indicating the reset type of the applet, and the option tag may indicate the reset type of the applet as the first option, second option, and third option described above. , or can be specified as any of the fourth options.

In operation 725, the security element 210 (e.g., processor 212) selects a data removal option (e.g., a second option) for which the reset type of the applet is specified, based on the reset type stored in the option DB 312. You can judge whether it is If the specified data removal option is yes in operation 725, then in operation 750 the security element 210 (e.g., processor 212) removes the user created by the applet while executing the applet. Data may be stored in a designated storage area (eg, second data area 408) within the memory 214. On the other hand, if the specified data removal option is not the specified data removal option (if 'No' in operation 725), in operation 730 the security element 210 (e.g., processor 212) removes the data generated by the applet while executing the applet. User data may be stored in another designated storage area (eg, first data area 406) within the memory 214.

In operation 735, the secure element 210 (e.g., processor 212) may receive a reset command instructing a factory reset. In one embodiment, the reset command may be received from the application processor 202. In operation 740, the security element 210 (e.g., processor 212) identifies from the options DB 312 that the reset type of the applet is set to the data removal option (e.g., the second option). You can. In operation 745, the security element 210 (e.g., processor 212) maintains installation data and/or execution data of the applet (e.g., a second applet) specified with a data removal option based on the reset command, and , user data can be removed from the memory 214. In one embodiment, secure element 210 (e.g., processor 212) may clear second data area 408. Installation data and/or execution data of the second applet may remain in the memory 214 even after factory reset.

FIG. 8 is a flowchart illustrating the operation of a security element that removes user data through an applet according to an embodiment. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or the order may be changed. At least one of the operations described below may be executed by the processor 212 of the secure element 210.

Referring to FIG. 8, in operation 805, the security element 210 (eg, processor 212) may receive an applet installation command. In one embodiment, the installation command may include installation data (eg, ELF) of the applet and may be received from the application processor 202. In operation 810, secure element 210 (e.g., processor 212) may store the installation data in memory 214 (e.g., auxiliary secure area 314). In operation 815, the security element 210 (e.g., processor 212) may install the applet based on the installation data. Execution data (e.g., executable file) of the applet may be stored in memory 214 (e.g., auxiliary security area 314).

In operation 820, the security element 210 (e.g., processor 212) identifies the reset type of the applet based on installation parameters included in the installation command and sets the reset type to memory 214 (e.g., option It can be stored in DB (312)). In one embodiment, the installation command may include an installation parameter having an option tag indicating the reset type of the applet, and the option tag may indicate the reset type of the applet as the first option, second option, and third option described above. , or can be specified as any of the fourth options.

In operation 825, the security element 210 (e.g., processor 212) selects a data removal option (e.g., a third option) for which the reset type of the applet is specified, based on the reset type stored in the option DB 312. You can judge whether it is If the specified data removal option is yes in operation 825, then in operation 850 the security element 210 (e.g., processor 212) determines that the user created by the applet during execution of the applet Data may be stored in a designated storage area (for example, the second data area 408 or the general data area 404) within the memory 214. On the other hand, if the specified data removal option is not the specified data removal option (if 'No' in operation 825), in operation 830 the security element 210 (e.g., processor 212) removes the data generated by the applet while executing the applet. User data may be stored in another designated storage area (for example, the first data area 406 or the general data area 404) within the memory 214.

In operation 835, the secure element 210 (e.g., processor 212) may receive a reset command instructing a factory reset. In one embodiment, the reset command may be received from the application processor 202. In operation 840, the security element 210 (e.g., processor 212) sets the reset type of the applet to a data removal option with an initialization function (e.g., a third option) from the option DB 312. It can be identified that it exists. In operation 845, the security element 210 (e.g., processor 212) maintains installation data and/or execution data of the applet (e.g., a second applet) specified with a data removal option based on the reset command, and , at least some user data of the second applet may be removed from the memory 214. In one embodiment, the secure element 210 (e.g., processor 212) may execute a second applet and remove at least some user data stored in data storage area 408 through the second applet. Installation data and/or execution data of the second applet may remain in the memory 214 even after factory reset.

Although not shown, in one embodiment the secure element 210 (e.g., processor 212) checks from the options DB 312 the reset types of one or more applets installed on the secure element 210 and maintains all of them. It may be determined whether there is at least one applet (eg, a first applet) having a reset type of option (eg, a first option). If there is a first applet with a reset type of the Keep All option, the security element 210 (e.g., processor 212) retrieves the first applet's associated data (e.g., installation data, etc.) based on the reset command. execution data and user data) may not be removed. In one embodiment, the security element 210 (e.g., processor 212) sets the reset type of the keep all option for the first applet if no options are stored in the options DB 312 for the first applet. It can be judged by having it. Related data of the first applet may remain in memory 214 even after factory reset.

Although not shown, in one embodiment the secure element 210 (e.g., processor 212) checks from the options DB 312 the reset types of one or more applets installed on the secure element 210 and removes them all. It may be determined whether there is at least one applet (eg, a third applet) having a reset type of option (eg, a fourth option). If there is a third applet with a reset type of Remove All option, the security element 210 (e.g., processor 212) retrieves the third applet's related data (e.g., installation data, etc.) based on the reset command. Execution data and user data) may be removed from the memory 214.

FIG. 9 shows a sequence diagram illustrating a procedure for removing user data of a secure element according to an embodiment. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or the order may be changed. At least one of the operations described below may be executed by the processor 212 of the secure element 210.

Referring to FIG. 9 , in operation 902, the server 314 (e.g., a service provider server) sends the installation command to install the applet on the secure element 210 through the application processor 202 of the electronic device 200. It may be transmitted to the application processor 202, including installation parameters indicating the reset type. In one embodiment, the application processor 202 may install the applet on the secure element 210 using a local script containing an installation command, in which case operation 902 may be omitted.

In operation 904, the application processor 202 may transmit an applet installation command by the server 314 or a local script to the operating system 302 of the security element 210. The installation command may include an installation package, and the installation package may include installation data and installation parameters for the applet. The installation parameters may include an option tag specifying a reset type that indicates how to remove the applet's associated data.

In operation 906, the operating system 302 may inquire with the FRA 304 whether to store the reset type according to the installation parameter, and in operation 908, upon a request from the FRA 304, the operating system 302 may request an option (e.g. For example, one of the first option, second option, third option, or fourth option) may be stored in the option DB 312. The option DB 312 may store the option along with the AID of the applet. In one embodiment, after the applet is installed, the operating system 302 receives a reset type change command specifying the reset type of the applet from the application processor 202, and stores the changed option of the reset type in the option DB 312. It can be saved in .

In operation 910, the operating system 302 may install the applet based on installation data in the installation package, and may store the installation data and execution data of the applet in the auxiliary security area 314. Although not shown, the operating system 302 may allocate storage space (for example, the second data area 408) for the applet within the data storage area 318 according to the reset type option.

In operation 912, the operating system 302 may store user data generated by the applet in the data storage area 318 (eg, the second data area 408). The operating system 302 identifies the reset type of the applet stored in the option DB 312, and stores user data in a data storage area (for example, a second option) based on identifying the reset type as a designated data removal option (e.g., a second option). 318) (for example, the second data area 408). Although not shown, the operating system 302 stores user data generated by an applet set to the specified data retention option (e.g., the first option) based on the option DB 312 in the data storage area 318 (e.g., For example, it can be stored in the first data area 408).

In operation 914, the application processor 202 may receive a reset request for a factory reset through a user input or from a server (eg, server 314). In operation 916, the application processor 202 may transmit a reset command for factory reset to the FRA 304 of the secure element 212. At operation 918, FRA 304 may transmit the reset command to operating system 302. In operation 920, the operating system 302 may request a reset type from the option DB 312 in response to the reset command. In operation 922, the operating system 302 may receive a reset type for each applet installed in the security element 210 from the option DB 312.

In operation 924, the operating system 302 stores data to remove user data in the data storage area 318 based on the received reset type indicating a data removal option (e.g., a second option or a third option). A request can be made to area 318. In one embodiment, the operating system 302 may request to clear the second data area 408 of the data storage area 318 based on the reset type. In operation 926, the second data area 408 of the data storage area 318 may be cleared. In operation 928, the operating system 302 may receive a result of data removal in the data storage area 318. Although not shown, the option DB 312 may be initialized after factory reset.

In operation 930, the operating system 302 may transmit the data removal processing result to the application processor 202. In one embodiment, the operating system 302 may perform a factory reset and transmit the processing results, including data removal, to the application processor 202. In operation 932, the application processor 202 may report the processing result to the server 314.

Figure 10 shows a signal flow diagram illustrating a procedure for removing data from a secure element according to one embodiment. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or the order may be changed. At least one of the operations described below may be executed by the processor 212 of the secure element 210.

Referring to FIG. 10 , in operation 1002, the server 314 (e.g., a service provider server) executes the installation command to install an applet on the secure element 210 through the application processor 202 of the electronic device 200. It may be transmitted to the application processor 202, including installation parameters indicating the reset type. In one embodiment, the application processor 202 may install the applet on the secure element 210 using a local script, in which case operation 1002 may be omitted.

In operation 1004, the application processor 202 may transmit an applet installation command by the server 314 or a local script to the operating system 302 of the security element 210. The installation command may include an installation package, and the installation package may include installation data and installation parameters for the applet. The installation parameters may include an option tag specifying a reset type that indicates how to remove the applet's associated data.

In operation 1006, the operating system 302 may inquire with the FRA 304 whether to store the reset type according to the installation parameter, and in operation 1008, upon a request from the FRA 304, the operating system 302 may request an option (e.g. For example, one of the first option, second option, third option, or fourth option) may be stored in the option DB 312. The option DB 312 may store the option along with the AID of the applet. In one embodiment, after the applet is installed, the operating system 302 receives a reset type change command specifying the reset type of the applet from the application processor 202 and stores the reset type option in the option DB 312. You can save it.

In operation 1010, the operating system 302 may install the applet based on installation data in the installation package, and may store the installation data and execution data of the applet in the auxiliary security area 314. Although not shown, the operating system 302 may allocate storage space (for example, the second data area 408) for the applet within the data storage area 318 according to the reset type option.

In operation 1012, the operating system 302 may store user data generated by the applet in the data storage area 318 (eg, the second data area 408). The operating system 302 identifies the reset type of the applet stored in the option DB 312, and stores user data in a data storage area (for example, a second option) based on identifying the reset type as a designated data removal option (e.g., a second option). 318) (for example, the second data area 408). Although not shown, the operating system 302 stores user data generated by an applet set to the specified data retention option (e.g., the first option) based on the option DB 312 in the data storage area 318 (e.g., For example, it can be stored in the first data area 408).

In operation 1014, the application processor 202 may receive a reset request for a factory reset through a user input or from a server (eg, server 314). In operation 1016, the application processor 202 may transmit a reset command for factory reset to the FRA 304 of the security element 212. In operation 1018, FRA 304 may transmit the reset command to operating system 302. In operation 1020, the operating system 302 may request a reset type from the option DB 312 in response to the reset command. In operation 1022, the operating system 302 may receive a reset type for each applet installed in the security element 210 from the option DB 312.

In operations 1024a and 1024b, the eSE operating system 302 instructs the data storage area 318 to remove the relevant data of the applet based on the received reset type indicating a remove all option (e.g., the fourth option). You can request it. In operation 1024a, the operating system 302 may request to clear the second data area 408 of the data storage area 318. In operation 1026a, the second data area 408 of the data storage area 318 may be cleared. In operation 1024b, operating system 302 may request removal of associated data (e.g., installation data and/or execution data) of that applet from secondary secure area 314. In operation 1026b, the associated data of the applet in the secondary secure area 314 may be removed.

In operations 1028a and 1028b, the operating system 302 may receive a result of data removal in the data storage area 318 and the auxiliary security area 314. Although not shown, the option DB 312 may be initialized after factory reset.

In operation 1030, the operating system 302 may transmit the data removal processing result to the application processor 202. In one embodiment, the operating system 302 may perform a factory reset and transmit the processing results, including data removal, to the application processor 202. In operation 1032, the application processor 202 may report the processing result to the server 314.

Figure 11 shows a signal flow diagram illustrating a procedure for removing user data of a secure element through an applet according to one embodiment. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or the order may be changed. At least one of the operations described below may be executed by the processor 212 of the secure element 210.

Referring to FIG. 11 , in operation 1102, the server 314 (e.g., a service provider server) sends the installation command to install an applet on the secure element 210 through the application processor 202 of the electronic device 200. It may be transmitted to the application processor 202, including installation parameters indicating the reset type. In one embodiment, the application processor 202 may install the applet in the secure element 210 according to a local script, in which case operation 1102 may be omitted.

In operation 1104, the application processor 202 may transmit an applet installation command by the server 314 or a local script to the operating system 302 of the security element 210. The installation command may include an installation package, and the installation package may include installation data and installation parameters for the applet. The installation parameters may include an option tag specifying a reset type that indicates how to remove the applet's associated data.

In operation 1106, the operating system 302 may inquire with the FRA 304 whether to store the reset type according to the installation parameter, and in operation 1108, at the request of the FRA 304, an option (e.g. For example, one of the first option, second option, third option, or fourth option) may be stored in the option DB 312. The option DB 312 may store the option along with the AID of the applet. In one embodiment, after the applet is installed, the operating system 302 receives a reset type change command specifying the reset type of the applet from the application processor 202 and stores the reset type option in the option DB 312. You can save it.

In operation 1110, the operating system 302 may install the applet based on installation data in the installation package, and may store the installation data and execution data of the applet in the auxiliary security area 314. Although not shown, the operating system 302 may allocate storage space (for example, the second data area 408) for the applet within the data storage area 318 according to the reset type option.

In operation 1112, the operating system 302 may store user data generated by the applet in the data storage area 318 (eg, the second data area 408). The operating system 302 identifies the reset type of the applet stored in the option DB 312, and stores user data in a data storage area (for example, a second option) based on identifying the reset type as a designated data removal option (e.g., a second option). 318) (for example, the second data area 408). Although not shown, the operating system 302 stores user data generated by an applet set to the specified data retention option (e.g., the first option) based on the option DB 312 in the data storage area 318 (e.g., For example, it can be stored in the first data area 408).

In operation 1114, the application processor 202 may receive a reset request for factory reset through a user input or from a server (eg, server 314). In operation 1116, the application processor 202 may transmit a reset command for factory reset to the FRA 304 of the security element 212. In operation 1118, the FRA 304 may transmit the reset command to the operating system 302. In operation 1120a, the operating system 302 may request a reset type from the option DB 312 in response to the reset command. In operation 1120b, the operating system 302 may receive a reset type for each applet installed in the security element 210 from the option DB 312.

In operation 1122a, the operating system 302 determines that the received reset type indicates a data removal option (e.g., a third option) that includes an initialization function of the applet 1100 (e.g., Applet A (APP A)). Based on this, a reset notification request to execute the initialization function of applet A (1100) can be transmitted to the FRA (304). In operation 1022b, FRA 304 may transmit a reset notification to applet A 1100 to request execution of an initialization function.

At operation 1024, applet A 1100 may execute a reset function and request removal of associated user data in data storage area 318. In one embodiment, applet A (1100) can distinguish between user data to be retained and user data to be removed after factory reset by the initialization function, and to remove the corresponding user data in response to the reset notification in the data storage area 318. ) can be requested. In operation 1126, at least some user data specified by applet A 1100 within the data storage area 318 may be removed. In one embodiment, among the user data generated by Applet A (1100), at least some user data distinguished by the initialization function of Applet A (1100) may be removed.

In operation 1128a, applet A 1100 may receive a data removal result from the data storage area 318. In operation 1128b, applet A 1100 may transmit the data removal result to the operating system 302.

In operation 1130, the operating system 302 may transmit the data removal processing result to the application processor 202. In one embodiment, the operating system 302 may perform a factory reset and transmit the processing results, including data removal, to the application processor 202. In operation 1132, the application processor 202 may report the processing result to the server 314.

Figure 12 shows a signal flow diagram explaining a procedure for changing the reset type according to one embodiment. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or the order may be changed. At least one of the operations described below may be executed by the processor 212 of the secure element 210.

Referring to FIG. 12, in operation 1202, the server 314 (eg, service provider server) may receive a reset type change command to change the reset type of the applet. The reset type change command may include a changed option of the applet (eg, any one of the first option, second option, third option, or fourth option). In one embodiment, the reset type change command may include installation parameters for the applet, and the installation parameters may include an option tag specifying changed options of the applet.

In operation 1206, the operating system 302 may inquire with the FRA 304 whether to change the reset type according to the installation parameter, and in operation 1208, the option set to the reset type is requested by the FRA 304. It can be saved back to the option DB (312) along with the applet's AID.

In operation 1210, the FRA 304 may request data movement to the operating system 302 according to the changed option. In one embodiment, the reset type of the applet may be changed from a data removal option (e.g., a second option or a third option) to a maintenance option (e.g., a first option) by the option tag of the installation parameter, FRA 304 may request operating system 302 to move the applet's associated user data stored in data storage area 318. In operation 1212, the operating system 302 may instruct the data storage area 318 to move the user data of the applet according to the changed option, and in operation 1214, the user data in the data storage area 318 may be moved. It can be saved. In one embodiment, the applet's user data may move from the second data area 408 to the first data area 306. Accordingly, upon factory reset, the user data of the applet can be maintained.

In operation 1216, the operating system 302 may receive the data movement result of the data storage area 318. In one embodiment, the operating system 302 may update a file allocation table (FAT) according to the data movement results to record the location to which the user data has been moved.

In operation 1218, the operating system 302 may transmit the data movement processing result to the application processor 202. In operation 1220, the application processor 202 may report the processing result of the reset type change to the server 314.

Embodiments of the present disclosure can remove designated data (for example, at least some user data of a designated applet) while maintaining important data stored in the security element even after a factory reset.

Embodiments of the present disclosure can reduce the time waste and inconvenience of reinstalling and reconfiguring all installation data and execution data of applets after a factory reset and improve the reusability of security elements.

Embodiments of the present disclosure can remove designated data through remote factory reset in situations such as device loss.

Embodiments of the present disclosure provide various options for the removal method of user data and can use a removal method according to the desired service.

Embodiments of the present disclosure may remove specified user data instead of removing all user data upon factory reset.

Embodiments of the present disclosure can selectively remove user data of each applet installed in the security element through an initialization function by factory reset.

Embodiments of the present disclosure can easily perform selective data removal by separately storing user data to be removed and user data to be retained.

The electronic device 200 according to one embodiment may include an application processor 202 and a security element 210 including the processor 212 and memory 214. The processor may be configured to receive a first installation command including installation data of the first applet from the application processor. The processor may be configured to install the first applet based on the first installation command. The processor may be configured to store the installation data and execution data of the first applet in the memory. The processor may be configured to store first user data associated with the first applet in the memory. The processor may be configured to receive a reset command for the secure element from the application processor. The processor may be configured to maintain the installation data and/or the execution data and remove the first user data in response to the reset command.

In one embodiment, the processor stores the first user data in a first data area 408 in the memory and clears the first data area before the secure element is reset in response to the reset command. It can be configured.

In one embodiment, the first data area may be allocated by the processor to store user data of at least one applet for which a data removal option is set among one or more applets installed in the security element.

In one embodiment, the installation data and/or the execution data may be maintained in the memory after the security element is reset by the reset command.

In one embodiment, the processor may be configured to obtain a reset option indicating a reset type of the first applet from the first installation command and store the reset option in the memory.

In one embodiment, the reset option may direct the secure element to retain the installation data and the execution data of the first applet and to retain the first user data when the secure element is reset.

In one embodiment, the memory may include an option database (DB), and the option DB may store a reset option indicating a reset type of each applet installed in the security element.

In one embodiment, the reset type includes: a first reset option indicating that the secure element retains associated data including installation data, execution data, and/or user data of each applet after the secure element is reset; a second reset option indicating removing user data excluding data and/or executable data, a third reset option indicating removing some specified user data among the user data of each applet, or installation data and executable data of each applet; and/or a fourth reset option indicating removing associated data including user data.

In one embodiment, the processor receives a second installation command including installation data of a second applet from the application processor, installs the second applet based on the second installation command, and installs the installation data and the second applet. Store execution data of a second applet in the memory, store second user data related to the second applet in a second data area 406 in the memory, and in response to the reset command, store the execution data of the second applet in the memory. It may be configured to maintain installation data, execution data, and the second user data in the second data area.

In one embodiment, the second data area may be allocated by the processor to store user data of at least one applet for which a data removal option is not set among one or more applets installed in the security element.

A method of operating the electronic device 200 including the security element 210 according to an embodiment may include an operation 705 of receiving a first installation command including installation data of the first applet. The method may include an operation 715 of installing the first applet based on the first installation command. The method may include an operation 710 of storing the installation data and execution data of the first applet in memory 214. The method may include an operation 750 of storing first user data related to the first applet in the memory. The method may include an operation 735 of receiving a reset command for the secure element. The method may include an operation 745 of maintaining the installation data and the execution data and removing the first user data in response to the reset command.

In one embodiment, the first user data may be stored in a first data area 408 in the memory, and the first data area may be cleared before the security element is reset in response to the reset command. .

In one embodiment, the first data area may be allocated to store user data of at least one applet for which a data removal option is set among one or more applets installed in the security element.

In one embodiment, the installation data and the execution data may be maintained in the memory after the security element is reset by the reset command.

In one embodiment, the method may further include obtaining a reset option indicating the reset type of the first applet from the first installation command (720) and storing the reset option in the memory.

In one embodiment, the reset option may direct the secure element to retain the installation data and the execution data of the first applet and to retain the first user data when the secure element is reset.

In one embodiment, the memory may include an option database (DB), and the option DB may store a reset option indicating a reset type of each applet installed in the security element.

In one embodiment, the reset type includes: a first reset option indicating that the secure element retains associated data including installation data, execution data, and/or user data of each applet after the secure element is reset; a second reset option indicating removing user data excluding data and/or executable data, a third reset option indicating removing some specified user data among the user data of each applet, or installation data and executable data of each applet; and/or a fourth reset option indicating removing associated data including user data.

In one embodiment, the method includes receiving a second installation command including installation data of a second applet, installing the second applet based on the second installation command, the installation data and the An operation of storing execution data of a second applet in the memory, an operation of storing second user data related to the second applet in a second data area 406 in the memory, and in response to the reset command, It may include maintaining installation data and execution data of the second applet and the second user data in the second data area.

In one embodiment, the second data area may be allocated to store user data of at least one applet for which a data removal option is not set among one or more applets installed in the security element.

Electronic devices according to various embodiments disclosed in this document may be of various types. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to embodiments of this document are not limited to the above-described devices.

The various embodiments of this document and the terms used herein are not intended to limit the technical features described in this document to specific embodiments, and should be understood to include various changes, equivalents, or replacements of the embodiments. In connection with the description of the drawings, similar reference numbers may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the above items, unless the relevant context clearly indicates otherwise. As used herein, “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 “A Each of phrases such as “at least one of , B, or C” may include any one of the items listed together in the corresponding phrase, or any possible combination thereof. Terms such as "first", "second", or "first" or "second" may be used simply to distinguish one component from another, and to refer to that component in other respects (e.g., importance or order) is not limited. One (e.g., first) component is said to be “coupled” or “connected” to another (e.g., second) component, with or without the terms “functionally” or “communicatively.” Where mentioned, it means that any of the components can be connected to the other components directly (e.g. wired), wirelessly, or through a third component.

The term “module” used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and is interchangeable with terms such as logic, logic block, component, or circuit, for example. It can be used as A module may be an integrated part or a minimum unit of the parts or a part thereof that performs one or more functions. For example, according to one embodiment, the module may be implemented in the form of an application-specific integrated circuit (ASIC).

Various embodiments of the present document are one or more instructions stored in a storage medium (e.g., built-in memory 136 or external memory 138) that can be read by a machine (e.g., electronic device 101). It may be implemented as software (e.g., program 140) including these. For example, a processor (e.g., processor 120) of a device (e.g., electronic device 101) may call at least one command among one or more commands stored from a storage medium and execute it. This allows the device to be operated to perform at least one function according to the at least one instruction called. The one or more instructions may include code generated by a compiler or code that can be executed by an interpreter. A storage medium that can be read by a device may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' only means that the storage medium is a tangible device and does not contain signals (e.g. electromagnetic waves), and this term refers to cases where data is semi-permanently stored in the storage medium. There is no distinction between temporary storage cases.

According to one embodiment, methods according to various embodiments disclosed in this document may be provided and included in a computer program product. Computer program products are commodities and can be traded between sellers and buyers. The computer program product may be distributed in the form of a machine-readable storage medium (e.g. compact disc read only memory (CD-ROM)) or through an application store (e.g. Play StoreTM) or on two user devices (e.g. It can be distributed (e.g. downloaded or uploaded) directly between smart phones) or online. In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

According to various embodiments, each component (e.g., module or program) of the above-described components may include a single or plural entity, and some of the plurality of entities may be separately placed in other components. there is. According to various embodiments, one or more of the components or operations described above may be omitted, or one or more other components or operations may be added. Alternatively or additionally, multiple components (eg, modules or programs) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each component of the plurality of components in the same or similar manner as those performed by the corresponding component of the plurality of components prior to the integration. . According to various embodiments, operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, or omitted. Alternatively, one or more other operations may be added.

Claims (20)

In the electronic device 200,
application processor 202; and
A security element 210 including a processor 212 and a memory 214, wherein the processor includes:
Receiving a first installation command including installation data of a first applet from the application processor,
Installing the first applet based on the first installation command,
Store the installation data and execution data of the first applet in the memory,
store first user data associated with the first applet in the memory,
Receiving a reset command for the security element from the application processor,
In response to the reset command, the electronic device is configured to maintain the installation data and/or the execution data and remove the first user data. The method of claim 1, wherein the processor:
storing the first user data in a first data area 408 in the memory,
The electronic device is configured to clear the first data area before the security element is reset in response to the reset command. The electronic device of claim 2, wherein the first data area is allocated by the processor to store user data of at least one applet for which a data removal option is set among one or more applets installed in the security element. . The method of any one of claims 1 to 3, wherein the installation data and/or the execution data are:
An electronic device characterized in that the security element is maintained in the memory after being reset by the reset command. The method of any one of claims 1 to 4, wherein the processor:
Obtain a reset option indicating a reset type of the first applet from the first installation command,
An electronic device configured to store the reset option in the memory. The method of claim 5, wherein the reset option is:
and instructing to maintain the installation data and the execution data of the first applet and to maintain the first user data when the secure element is reset. The method of any one of claims 1 to 6, wherein the memory
Contains an optional database (DB),
The option DB stores a reset option indicating a reset type of each applet installed in the security element. The method of claim 7, wherein the reset type is:
a first reset option indicating that the secure element retains associated data including installation data, execution data, and/or user data of each applet after being reset;
a second reset option indicating removal of user data excluding installation data and/or execution data of each applet;
a third reset option indicating removing a specified portion of the user data of each applet, or
An electronic device comprising at least one of a fourth reset option indicating removing associated data including installation data, execution data, and/or user data of each applet. The method of any one of claims 1 to 8, wherein the processor:
Receiving a second installation command including installation data of a second applet from the application processor,
Installing the second applet based on the second installation command,
Store the installation data and execution data of the second applet in the memory,
storing second user data related to the second applet in a second data area (406) in the memory;
In response to the reset command, the electronic device is configured to maintain installation data and execution data of the second applet and the second user data in the second data area. The method of claim 9, wherein the second data area is allocated by the processor to store user data of at least one applet for which a data removal option is not set among one or more applets installed in the security element. Electronic devices. In a method of operating an electronic device 200 including a security element 210,
An operation 705 of receiving a first installation command including installation data of the first applet;
An operation 715 of installing the first applet based on the first installation command,
An operation 710 of storing the installation data and execution data of the first applet in the memory 214;
An operation 750 of storing first user data related to the first applet in the memory;
An operation 735 of receiving a reset command for the security element;
In response to the reset command, an operation (745) of maintaining the installation data and the execution data and removing the first user data. 12. The method of claim 11, wherein the first user data is stored in a first data area (408) in the memory,
Wherein the first data area is cleared before the security element is reset in response to the reset command. The method of claim 12, wherein the first data area is allocated to store user data of at least one applet for which a data removal option is set among one or more applets installed in the security element. The method of any one of claims 11 to 13, wherein the installation data and the execution data are:
A method characterized in that the security element is maintained in the memory after being reset by the reset command. The method according to any one of claims 11 to 14,
An operation 720 of obtaining a reset option indicating a reset type of the first applet from the first installation command,
The method further comprising storing the reset option in the memory. The method of claim 15, wherein the reset option is:
and instructing the secure element to maintain the installation data and the execution data of the first applet and to retain the first user data when the secure element is reset. 17. The method of any one of claims 11 to 16, wherein the memory
Contains an optional database (DB),
The option DB stores a reset option indicating a reset type of each applet installed in the security element. The method of claim 17, wherein the reset type is:
a first reset option indicating that the secure element retains associated data including installation data, execution data, and/or user data of each applet after being reset;
a second reset option indicating removal of user data excluding installation data and/or execution data of each applet;
a third reset option indicating removing a specified portion of the user data of each applet, or
and at least one of a fourth reset option indicating removing associated data including installation data, execution data, and/or user data of each applet. The method according to any one of claims 11 to 18,
Receiving a second installation command including installation data of a second applet;
An operation of installing the second applet based on the second installation command;
An operation of storing the installation data and execution data of the second applet in the memory;
An operation of storing second user data related to the second applet in a second data area (406) in the memory;
In response to the reset command, the method comprising maintaining installation data and execution data of the second applet and the second user data in the second data area. The method of claim 19, wherein the second data area is allocated to store user data of at least one applet for which a data removal option is not set among one or more applets installed in the security element.

Images