Electronic apparatus and method of zeroization in memory of electronic apparatus

Abstract

A user terminal according to one embodiment may store zeroing information corresponding to an area to be zeroed among a memory area allocated to any one of a plurality of processes. The user terminal may monitor whether the user terminal enters a mode where a RAM dump can be secured before the app process completes its use of the allocated memory area. If the user terminal enters a mode where a RAM dump can be secured, it may perform zeroing on the area to be zeroed based on the zeroing information.

Description

Technology Field

[0001] The following disclosure relates to an electronic device and a method for memory zeroing of an electronic device. Background Technology

[0002] When a failure occurs during the operation of an electronic device, information stored in memory may be used to identify the cause of the failure and perform debugging. A ram dump technique, which extracts data stored in memory as is, may be used to identify the cause of the failure or for debugging. In this case, the data stored in memory may include not only general information but also information requiring a high level of security (e.g., passwords, personal information, etc.). The problem to be solved

[0003] Security can be improved by reducing the possibility of exposure of key data by minimizing the vulnerable period, that is, the period during which an attacker can obtain key data remaining in memory through a ram dump.

[0004] By encrypting the address information of the memory area where key data is stored, attacks by attackers on key data can be prevented. means of solving the problem

[0005] A user terminal (101, 800) according to one embodiment includes a memory (130, 810) in which computer-executable instructions are stored, and a processor (120, 830) that accesses the memory (130, 810) and executes the instructions for the operation of a plurality of processes (411, 412, 413), wherein the instructions store zeroing information (433, 434, 435) corresponding to an area (315, 355) to be zeroed out of an area of ​​memory (130, 810) allocated to one of the plurality of processes (411, 412, 413), and monitors whether the user terminal (101, 800) enters a mode in which a RAM dump can be secured before the application process completes the use of the allocated memory (130, 810) area, and the RAM When entering a mode where a dump can be secured, the area to be zeroed (315, 355) can be configured to be zeroed based on the zeroing information (433, 434, 435).

[0006] A method for zeroing out memory (130, 810) of a plurality of processes (411, 412, 413) running on a user terminal (101, 800) according to one embodiment comprises: an operation 210 of storing zeroing information (433, 434, 435) corresponding to an area to be zeroed out (315, 355) among an area of ​​memory (130, 810) allocated to any one of the plurality of processes (411, 412, 413); an operation 220 of monitoring whether the user terminal (101, 800) enters a mode capable of securing a RAM dump before the app process completes the use of the allocated memory (130, 810) area; and, when the user terminal enters a mode capable of securing a RAM dump, regarding the area to be zeroed out (315, 355) based on the zeroing information (433, 434, 435). It may include operation 230 that performs zeroing.

[0007] A method for zeroing out memory (130, 810) of a plurality of processes (411, 412, 413) running on a user terminal (101, 800) according to one embodiment comprises: an operation 510, 520 of allocating an available memory (130, 810) area to an app process upon receiving a request for memory (130, 810) allocation from any one of the plurality of processes (411, 412, 413); an operation 5360 of encrypting information related to the area to be zeroed (315, 355) in response to the app process specifying an area to be zeroed (315, 355) among the memory (130, 810) areas allocated to the app process; an operation 540 of storing zeroing information (433, 434, 435) corresponding to the area to be zeroed (315, 355); and the app The process may include an operation 550 for monitoring whether the user terminal (101, 800) enters a mode where a RAM dump can be secured before the process completes the use of the allocated memory (130, 810) area, and an operation 560 for performing zeroing on the area to be zeroed (315, 355) by decrypting the encrypted information based on the zeroing information (433, 434, 435) when the RAM dump can be secured. Effects of the invention

[0008] An electronic device according to one embodiment stores zeroing information corresponding to a zeroing area in a memory region where key data is stored, and when it is detected that it has entered a mode in which a RAM dump can be secured, it can prevent the occurrence of a period vulnerable to an attacker's attack by performing zeroing on the zeroing area in advance using the zeroing information.

[0009] An electronic device according to one embodiment can block the exposure of the location of the area to be zeroed out by encrypting information related to the area to be zeroed out among the memory areas allocated to the app process (e.g., starting address and size information of the area to be zeroed out).

[0010] An electronic device according to one embodiment can safely store key data even if an attacker intentionally interferes with encryption or decryption by zeroing out not only the area to be zeroed out but also the entire memory area allocated to the app process and / or the stack or heap of the app process in the event that the storage or reading of zeroing information fails, the encryption of information related to the area to be zeroed out fails, or the decryption of encrypted information fails. Brief explanation of the drawing

[0011] FIG. 1 is a block diagram of an electronic device in a network environment according to various embodiments. FIG. 2 is a flowchart illustrating a memory zeroing method according to one embodiment. FIG. 3 is a drawing illustrating an example of an area to be zeroed out according to one embodiment. FIG. 4 is a flowchart illustrating a memory zeroing method according to another embodiment. FIG. 5 is a drawing illustrating various configuration examples of zeroing information corresponding to each of a plurality of processes according to one embodiment. FIG. 6 is a diagram illustrating the operation between an app process running on a user terminal and an operating system (OS) according to one embodiment. FIG. 7 is a flowchart illustrating a memory zeroing method according to another embodiment. FIG. 8 is a block diagram of a user terminal according to one embodiment. Specific details for implementing the invention

[0012] Hereinafter, embodiments will be described in detail with reference to the attached drawings. In the description with reference to the attached drawings, identical components are given the same reference numeral regardless of the drawing number, and redundant descriptions thereof will be omitted.

[0014] FIG. 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) may communicate with an electronic device (102) through a first network (198) (e.g., a short-range wireless communication network) or may communicate with at least one of 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)).

[0015] 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)), for example, 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 lower 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.

[0016] 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 model is executed, 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.

[0017] 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).

[0018] 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).

[0019] 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).

[0020] 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.

[0021] 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.

[0022] 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).

[0023] 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 biometric sensor, a temperature sensor, a humidity sensor, or a fingerprint sensor.

[0024] 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)). 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.

[0025] 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).

[0026] 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.

[0027] 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.

[0028] The power management module (188) can manage the 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).

[0029] 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.

[0030] The communication module (190) can 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., cellular communication module, short-range wireless communication module, or GNSS (global navigation satellite system) communication module) or a wired communication module (194) (e.g., LAN (local area network) communication module, or power line communication module). The corresponding communication module among these communication modules can communicate with an external electronic device (104) through a first network (198) (e.g., a short-range communication network such as Bluetooth, WiFi (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 the first network (198) or the second network (199) using subscriber information (e.g., International Mobile Subscriber Identifier (IMSI)) stored in the subscriber identification module (196).

[0031] 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) can support a 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., downlink (DL) and uplink (UL) each 0.5 ms or less, or round trip 1 ms or less) for realizing URLLC.

[0032] 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).

[0033] According to various embodiments, 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.

[0034] 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.

[0035] According to one embodiment, commands or data may be transmitted or received between an 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).

[0036] According to one embodiment, all or part of the operations performed on the electronic device (101) may be performed on one or more external electronic devices (102, 104, or 108). For example, when 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. Upon receiving the request, one or more external electronic devices may perform at least part of the requested function or service, or additional functions or services 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 another 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) 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.

[0038] FIG. 2 is a flowchart illustrating a memory zeroing method according to one embodiment. In the following embodiments, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

[0039] Referring to FIG. 2, a user terminal according to one embodiment (e.g., the electronic device (101) of FIG. 1, the user terminal (800) of FIG. 8) can perform zeroing through operations 210 to 230. Hereinafter, operations described as being performed by the user terminal (101, 800) can be understood as being performed by the operating system (142) of the user terminal (101, 800) even without separate description. Here, the term 'operating system (os)' (142) can be understood to encompass all various software programs that are executed for the operation of a user terminal (101, 800), such as a secure kernel (e.g., the kernel (430) of FIG. 4, the kernel (703) of FIG. 7) and a boot loader (e.g., the boot loader (705) of FIG. 7), in addition to the kernel described below. Hereinafter, for operations performed by entities other than the kernel (430, 703), such as the secure kernel (450) or the boot loader (705), the respective entities will be explicitly described.

[0040] In operation 210, the user terminal (101, 800) may store zeroing information corresponding to an area to be zeroed (e.g., 315, 355) among the memory areas allocated to any one of the multiple processes (e.g., the processes of FIG. 4 (411, 412, 413)). In this specification, 'zeroing' means erasing information stored in a certain area of ​​memory, and by replacing the information stored in a certain area with a specific value (e.g., '0') or a random pattern, the original information stored can be prevented from being identified by an attacker.

[0041] Additionally, the 'area to be zeroed' may correspond to a zeroing target area among the memory areas allocated to the app process that must be zeroed out to delete key data in the event of an attack by an attacker. The area to be zeroed (315, 355) may correspond to a part of the memory area allocated to the app process. The area to be zeroed (315, 355) may be one or multiple. The area to be zeroed (315, 355) may be set by the app process passing to the application programming interface (API) the starting address (e.g., 'FFOOF') of the area to be zeroed (315) specified by itself (the app process) among the memory areas allocated to itself (the app process) and the length (e.g., 10) of the area to be zeroed (315). The starting address of the area to be zeroed (315) and the length of the area to be zeroed (315) are information related to the area to be zeroed (315) and can be encrypted prior to operation 210. An example of the area to be zeroed (315) is described in more detail with reference to FIG. 3 below.

[0042] The zeroing information may include, for example, at least one of first information indicating whether there is one or more areas (315, 355) to be zeroed in the memory area allocated to the app process, second information indicating whether the entire stack or heap of the app process to be zeroed, and third information indicating a list of areas (315, 355) to be zeroed. The first information must be included in the zeroing information, and depending on the value of the first information, the second information or the third information may be optionally included.

[0043] The first information may indicate that there is one or more zeroing areas (315, 355) in the memory area allocated to the app process. For example, the variable representing the first information may be 'needToZeroize'. If the variable representing the first information ('need To Zeronize') is set to 'true', it may indicate that there is one or more zeroing areas (315, 355) in the memory area allocated to the app process. If the variable representing the first information ('need To Zeronize') is set to 'false', it may indicate that there is no zeroing area (315) in the memory area allocated to the app process, for example, as in the second area (330) of FIG. 3.

[0044] The second information may indicate whether to zero out the entire stack or heap of the app process. For example, the variable representing the second information may be 'ZeroizAll'. If the variable representing the second information ('ZeroizAll') is set to 'true', the user terminal (101, 800) may zero out the entire stack or heap of the app process. The case where the variable representing the second information ('ZeroizAll') is set to 'true' may correspond to a situation where the kernel (430, 703) of the user terminal (101, 800) cannot obtain a list of areas (315, 355) to be zeroed out. Here, 'situations where a list of areas to be zeroed cannot be obtained' may include, for example, cases where the security area of ​​a processor (120, 830) for a security operating system (405) malfunctions and the boot loader (705) fails to decrypt encrypted information; cases where an attacker interferes with the encryption of information related to the areas to be zeroed (315, 355) and the kernel (430, 703) fails to encrypt information related to the areas to be zeroed (315, 355); and cases where the kernel (430, 703) fails to store or read zeroed information, but is not necessarily limited thereto. The security area of ​​the processor (120, 830) may be, for example, a Trust Zone, but is not necessarily limited thereto.

[0045] A user terminal (101, 800) can determine whether encryption of information related to the area to be zeroed (315, 355) has failed based on zeroing information (e.g., second information). If encryption of information related to the area to be zeroed (315, 355) has failed and a variable ('ZeroizAll') representing the second information is set to 'true', the user terminal (101, 800) can block exposure of key data even if an attacker interferes with encryption or decryption by zeroing out the entire memory area allocated to the app process or the stack or heap of the app process.

[0046] The third information may represent a list of areas to be zeroed (315, 355). For example, the variable representing the third information may be 'area list to be zeroed'. The variable representing the third information ('area list to be zeroed') may correspond to a list containing information related to the areas to be zeroed (315, 355). In this case, the information related to the areas to be zeroed (315, 355) may be encrypted and stored in the list. For example, if there are two areas to be zeroed (315, 355) (a first area and a second area), the list may include the starting address and length of each of the first area and the second area. The starting address and length of each of the first area and the second area may be encrypted and stored in the list.

[0047] The user terminal (101, 800) can store zeroing information for each app process. For example, if the user terminal (101, 800) fails to store zeroing information for app process A, or fails to read zeroing information for app process A, it may zero out the entire memory area allocated to app process A, or it may zero out the stack or heap of app process A. An example of zeroing information stored for each app process is explained in more detail with reference to 4 below.

[0048] The user terminal (101, 800) can delete the zeroing information of the app process as the operation of the app process is terminated.

[0049] In operation 220, the user terminal (101, 800) can monitor whether the user terminal (101, 800) enters a mode where a RAM dump can be obtained before the app process completes the use of the memory area allocated to it (the app process). Whether the user terminal (101, 800) enters a mode where a RAM dump can be obtained can be determined, for example, by the input of a predetermined key combination, entry into an upload mode by the system's watchdog, or whether a kernel panic occurs. Here, the predetermined key combination may include, for example, a specific string or a specific key combination such as 'abd', 'ddms', or 'frida', but is not necessarily limited thereto.

[0050] Here, the 'mode in which a RAM dump can be obtained' can be interpreted to encompass not only the upload mode, in which a user terminal (101, 800) is forcibly rebooted to upload a RAM dump so that, for example, a developer, a technician at a service center, or an attacker can obtain key data (passwords, personal information, etc.) remaining in memory (e.g., DRAM), but also cases where the user terminal (101, 800) is in a ready state for obtaining a RAM dump or in a state in which a RAM dump can be obtained. The 'ready state for obtaining a RAM dump' may correspond to a state in which a predetermined key combination is entered or a kernel panic is recognized, the reason is recorded in memory (e.g., memory (130) of FIG. 1, memory (810) of FIG. 8), and booting is performed on the user terminal (101, 800). Additionally, the ‘state in which a RAM dump can be secured’ may correspond to a state in which the boot loader (705) reads the reason written to the memory area set by the kernel and enters a RAM dump mode according to the reason.

[0051] In operation 230, if the user terminal (101, 800) enters a mode where a RAM dump can be secured based on the monitoring result of operation 220, the user terminal (101, 800) can perform zeroing on the area to be zeroed (315, 355) based on the zeroing information stored in operation 210.

[0052] For example, a specific string such as 'abd', 'ddms', or 'frida' or a specific key combination may be entered by a user at a user terminal (101, 800), or a kernel panic may occur due to an error within the kernel, and the panic() function within the kernel may be called. Here, the panic() function may correspond to a function that performs preprocessing tasks to enable the user terminal (101, 800) to enter a mode where a RAM dump can be secured, such as upload mode, not only when a kernel panic occurs.

[0053] The kernel (430, 703) may perform booting for a RAM dump after recording the reason for entering the RAM dump mode (e.g., a specific key combination, or a kernel panic) along with an indication that it is entering the RAM dump mode in a predetermined specific memory area. When booting is performed, the kernel (430, 703) or the boot loader (705) may recognize that it is entering a mode where a RAM dump can be secured by reading the reason in the memory area set by the kernel (430, 703).

[0054] For example, if the starting address and size information of the area to be zeroed (315, 355) is encrypted based on zeroing information, the kernel (430, 703) or the boot loader (705) can decrypt the encrypted information and perform zeroing on the area to be zeroed (315, 355) according to the decrypted information. The user terminal (101, 800) can prevent leakage of key data stored in the area to be zeroed (315, 355) by performing zeroing on the area to be zeroed (315, 355) prior to entering a mode where a RAM dump can be obtained (e.g., kernel panic mode or upload mode) through the above process.

[0055] According to an embodiment, if decryption of encrypted information (e.g., starting address and size information of the area to be zeroed (315, 355)) fails, the kernel (430, 703) or boot loader (705) may, instead of zeroing the area to be zeroed (315, 355), zero out the entire memory area allocated to the app process or zero out the stack or heap of the app process to prevent leakage of key data. The above-described process may be performed by an entity other than the kernel (430, 703) or boot loader (705), and is not necessarily limited thereto.

[0057] FIG. 3 is a drawing illustrating an example of a region to be zeroed out according to one embodiment. Referring to FIG. 3, regions to be zeroed out (315, 355) stored in a part of the available region (305) of a memory (300) according to one embodiment are shown.

[0058] The memory (300) is a volatile memory, for example, a DRAM (Dynamic Random Access Memory). Among the available areas (305) of the memory (300), the first area (310) may be allocated to process A (e.g., process A (411) of FIG. 4), the second area (330) may be allocated to app process B (e.g., process B (412) of FIG. 4), and the third area (350) may be allocated to app process C (e.g., process C (413) of FIG. 4).

[0059] At this time, process A (411) can call an application programming interface (API) to specify a zeroing area (315) in which key data is stored among the memory areas allocated to it (e.g., first area (310)). Process A (411) can pass information related to the zeroing area (315), including the starting address (e.g., 'FFOOF') and length (e.g., '10') of the zeroing area (315), as input values ​​to the application programming interface (API).

[0060] When the kernel (430, 703) calls the application interface (API) by process A (411), it can encrypt the information related to the area to be zeroed (315) passed through the application interface (API) (e.g., the starting address ('FFOOF') and length ('10') of the area to be zeroed (315)) and update the zeroing information of process A (411) according to the encrypted information (the starting address ('FFOOF') and length ('10') of the area to be zeroed (315)).

[0061] According to the embodiments, processes may designate the entire third area (350) assigned to them as the area (355) to be initialized, such as process C (413), or may not designate the area to be initialized for the second area (330) assigned to them, such as process B (412).

[0063] FIG. 4 is a diagram illustrating various configuration examples of zeroing information corresponding to each of a plurality of processes according to one embodiment. Referring to FIG. 4, when a plurality of processes (411, 412, 413) for an app (410) are run on a user terminal (101, 800), the configuration of zeroing information for each process is illustrated.

[0064] The kernel (430) and secure kernel (450) of the user terminal (101, 800) can manage the area (315) to be zeroed according to the configuration of zeroing information (433, 434, 435) for each process (411, 412, 413). Here, the secure kernel (450) can be distinguished from the kernel (430) as a separate operating system for operating the secure area of ​​the processor (120, 830). The secure kernel (450) can perform security-related functions and transmit security-related responses through the secure area (e.g., trust zone (tz)) of the processor (120, 830). The secure area of ​​the processor (120, 830) may correspond to an area provided by the processor (120, 830) in hardware within the user terminal (101, 800). The security area of ​​the processor (120, 830) is separated from the kernel (430) and may correspond to an area used to perform security-related operations, such as encryption and / or decryption, for example.

[0065] As described above, the zeroing information (433, 434, 435) may include, for example, at least one of the following: first information indicating whether there is one or more areas to be zeroed (e.g., areas to be zeroed (315, 355) of FIG. 3) in the memory area allocated to the app process; second information indicating whether the entire heap or stack of the process to be zeroed; and third information indicating a list of areas to be zeroed (315).

[0066] For example, an app process A (411) may call an API to set memory zeroization (MZ) for a memory area (315) to be zeroed out among the memory areas allocated to it. In this case, since there is one or more areas (315) to be zeroed out set by the app process A (411), the kernel (430) may set the first information among the zeroing information (433) corresponding to the app process A (411) to 'true'. At this time, since there is no need to zero out the entire heap or stack of the app process A (411), the second information may be set to 'false'. Additionally, the kernel (430) may encrypt and store the third information regarding the list of areas (315) to be zeroed out among the zeroing information (433), that is, information related to the areas (315) to be zeroed out. At this time, encryption of information related to the area to be zeroed out (315) can be performed, for example, by a Trust Application (TA) that operates in the secure area. The TA can perform operations in the secure area that are security-sensitive to general app processes.

[0067] When the user terminal (101, 800) enters a mode where a RAM dump can be secured, such as an upload mode, for example, the area to be zeroed (315) stored in the third information of the zeroing information (433) of the app process A (411) can be zeroed.

[0068] For example, since process B (412) did not call an application programming interface (API) to set the area to be zeroed, the kernel (430) can set the first information ('need To Zeronize') among the zeroing areas (434) corresponding to process B (412) to 'false'. Additionally, since there is no need to zero out the entire heap or stack allocated to process B (412) for process B (412), the variable ('ZeroizAll') representing the second information among the zeroing areas (434) can be set to 'false'.

[0069] Additionally, process C (413) may call an API to set the zeroing (MZ) for the area to be zeroed out (e.g., the third area (355) in FIG. 3) among the memory areas allocated to it, but receive a signal from the secure operating system (450) that the operation cannot be performed in the secure area of ​​the processor. "The signal that the operation cannot be performed in the secure area of ​​the processor may occur, for example, due to a malfunction in the secure area of ​​the processor (120, 830) or a failure in encryption of information related to the area to be zeroed out (355) due to an attack, but is not necessarily limited thereto."

[0070] In this case, since there is one or more zeroing areas (355) set by process C (413), the kernel (430) can set the first information among the zeroing information (435) corresponding to process C (413) to 'true'. At this time, since the encryption of the information related to the zeroing areas (355) failed, the kernel (430) can set the second information to 'true' to zero out the entire heap or stack of process C (413). At this time, since the encryption of the information related to the zeroing areas (355) failed, the value of the third information, that is, the information about the list of zeroing areas among the zeroing information (435), may not be stored.

[0072] FIG. 5 is a flowchart illustrating a memory zeroing method according to another embodiment. In the following embodiments, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

[0073] Referring to FIG. 5, a user terminal (101, 800) according to one embodiment can perform zeroing through operations 510 to 560.

[0074] In operation 510, the user terminal (101, 800) may receive a memory allocation request from any one of the multiple processes (411, 412, 413) of the app process.

[0075] In operation 520, the user terminal (101, 800) can allocate an available memory area to the app process that requested memory allocation in operation 510.

[0076] In operation 530, the user terminal (101, 800) may encrypt information related to the area to be zeroed (315) in response to the app process specifying the area to be zeroed among the memory areas allocated to the app process in operation 520. In one embodiment, the reason for encrypting information related to the area to be zeroed (315) is as follows. In order to perform zeroing at a specific time, one or more areas to be zeroed may be designated in advance, and information related to one or more areas to be zeroed (e.g., the address of one or more areas to be zeroed) may be stored in memory. In this case, storing the address of one or more areas to be zeroed may cause another security problem. For example, if the memory area where information about one or more areas to be zeroed is stored can be read, an attacker can easily find out the location of all data that is important enough to be zeroed out. Accordingly, in one embodiment, information about one or more areas to be zeroed out can be individually encrypted and securely stored so that an attacker cannot know where the areas to be zeroed out are.

[0077] In operation 540, the user terminal (101, 800) can store zeroing information corresponding to the information encrypted in operation 530 (e.g., the starting address and size information of the area (315) to be zeroed).

[0078] In operation 550, the user terminal (101, 800) can monitor whether the user terminal (101, 800) enters a mode where a RAM dump can be obtained before the app process finishes using the allocated memory area.

[0079] In operation 560, if the user terminal (101, 800) enters a mode where a RAM dump can be secured based on the monitoring result of operation 550, the user terminal (101, 800) can perform zeroing on the area to be zeroed (315) by decrypting the information encrypted in operation 530 based on the zeroing information stored in operation 540.

[0080] For example, if the kernel of the user terminal (101, 800) fails to store zeroing information, fails to read zeroing information, fails to encrypt information related to the area to be zeroed (315), or if the boot loader (705) fails to decrypt the encrypted information, the user terminal (101, 800) may zero out the entire memory area allocated to the app process, or zero out the stack or heap of the app process.

[0082] FIG. 6 is a diagram illustrating the operation between an app process and an operating system (OS) running on a user terminal (101, 800) according to one embodiment. In the following embodiments, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

[0083] Referring to FIG. 6, when an attacker's attack (630) occurs, the process of zeroing out the area (315) set by process A (e.g., app process (411) of FIG. 4) through operation 605 to operation 635 is illustrated.

[0084] In operation 605, process A (411) may request the operating system (OS) (142) to allocate memory (e.g., a heap or a stack) to store sensitive data (e.g., a key, a password (PW), or other personal information). App process A (411) may request the operating system (OS) (142) to allocate a heap, for example, by calling the malloc() function.

[0085] In operation 610, the operating system (OS) (142) may allocate an available memory area (e.g., DRAM) to process A (411) after zeroing it out. The operating system (OS) (142) may, for example, zero out the available memory area before allocating it to process A (411), or zero out the memory area when it is returned from another process that has finished using it, and then allocate it to process A (411). It does not matter how the zeroing performed by the operating system (OS) (142) before allocating the memory area to process A (411) is performed.

[0086] In operation 615, process A (411) may request that a memory area (e.g., a heap) allocated by the operating system (OS) (142) be designated as the area (315) to be zeroed out. Process A (411) may call an application programming interface (API) to request that the area (315) to be zeroed out be designated. Process A (411) may pass, for example, the starting address and size (length) of the area (315) to be zeroed out as input values ​​to the application programming interface (API).

[0087] When an application program interface (API) is called by process A (411), in operation 620, the operating system (OS) (142) can set the area to be zeroed (315) corresponding to the starting address and size (length) of the area to be zeroed received from the application program interface (API), and can encrypt the area to be zeroed (315). At this time, the operating system (OS) (142) can update the zeroing information (433) corresponding to process A (411) as follows.

[0088] - 1st information('needToZeroize') = true,

[0089] - 2nd information('zeroizeAll') = false,

[0090] - Add information related to the encrypted area to be zeroed (315) to the third information ('area list to be zeroed').

[0091] The zeroing information (433) corresponding to process A (411) can all be deleted by the operating system (OS) (142) when process A (411) is terminated.

[0092] In operation 625, process A (411) can store and use sensitive data (e.g., keys, passwords, other personal information) in a memory area allocated from the operating system (OS) (142).

[0093] For example, an attacker's attempt to dump RAM may occur in operation 630 after operation 625. When monitoring that the user terminal (101, 800) enters a mode where RAM dump can be secured in accordance with the attacker's attempt to dump RAM, in operation 635, the operating system (OS) (142) can secure the areas (315) to be zeroed out from the zeroing information of each process saved in operation 620 and zero out all of the said areas.

[0094] In operation 635, if the second information ('zeroizeAll') among the zeroing information of each process is set to 'true', or if the decryption of information related to the encrypted zeroing area (315) fails, the operating system (OS) (142) may zero out the entire stack and heap of the process. This may be a measure to ensure that key data can be zeroed out even if an attacker interferes with the decryption of information related to the zeroing area (315) by causing a denial of service to the security area of ​​the processor (120, 830) through an intentional DoS attack. The operating system (OS) (142) may, for example, perform zeroing out the entire stack and heap of the process by the panic() function within the kernel.

[0095] For example, in operation 630, the attacker's attempt to dump RAM does not occur, and the use of the memory area being used in operation 625 may be completed. In this case, in operation 640, process A (411) may return the memory area to the operating system (OS) (142). Process A (411) may, for example, call the memset() function to directly zero out the memory area (heap) and then call the free() function to return the heap to the operating system (OS) (142).

[0096] In operation 645, the operating system (OS) (142) may mark the memory area returned from process A (411) as an available memory area. The operating system (OS) (142) may, for example, zero out the data corresponding to the memory area returned from process A (411) in the available list to '00000000'. The operating system (OS) (142) may zero out the area when it returns the memory area from process A (411), or it may zero out the area when it allocates it to another process (e.g., process B (412)).

[0097] In operation 650, process B (412) can request memory allocation from the operating system (OS) (142).

[0098] In operation 655, the operating system (OS) (142) may allocate an available memory area to process B (412) in response to the memory allocation request of operation 650. Since the memory area returned by process A (411) is also one of the available memory areas, the operating system (OS) (142) may allocate the memory area returned by process A (411) to process B (412).

[0099] According to one embodiment, when a user terminal (101, 800) enters a mode in which a RAM dump can be obtained, the operating system zeros out all pre-specified areas (e.g., areas to be zeroed out (315)) to a specific value (e.g., '0') or an arbitrary pattern, so that there is no vulnerable period during which an attacker can obtain key data (e.g., passwords, personal information) remaining in memory (e.g., DRAM) through a RAM dump, in other words, there is no vulnerable period, thereby reducing the possibility of exposure of key data.

[0101] FIG. 7 is a flowchart illustrating a memory zeroing method according to another embodiment. In the following embodiments, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel.

[0102] Referring to FIG. 7, the app process (701), kernel (703), and boot loader (705) of a user terminal (101, 800) according to one embodiment can perform zeroing through operations 710 to 790.

[0103] In operation 710, the app process (701) can request memory allocation from the kernel (703).

[0104] In operation 720, the kernel (703) can allocate an available memory area to the app process (701) that requested memory allocation.

[0105] In operation 730, the app process (701) can specify an area (315) to be zeroed out of the memory areas allocated by the kernel (703). When the app process (701) specifies an area (315) to be zeroed out by calling an application programming interface (API), the kernel (703) can receive information related to the area (315) to be zeroed out specified by the app process (701) through the application programming interface (API).

[0106] In operation 740, the kernel (703) sets a memory area according to the designation of the app process (701) as a zeroing area, and in operation 750, can encrypt information related to the zeroing area (315) (e.g., the starting address and size information of the zeroing area (315)).

[0107] In operation 760, the kernel (703) may store zeroing information corresponding to the information encrypted in operation 750 (e.g., the starting address and size information of the area (315) to be zeroed). The kernel (703) may also transmit the zeroing information to the boot loader (705).

[0108] In operation 770, the kernel (703) can monitor whether the user terminal (101, 800) enters a mode where a RAM dump can be obtained before the app process (701) completes the use of the memory area allocated through operation 720. The kernel (703) can set a reason to enter a mode where a RAM dump can be obtained (e.g., upload mode) and reboot the user terminal (101, 800). When the user terminal (101, 800) is rebooted, the boot loader (705) can determine whether to perform a normal boot or enter upload mode by checking the reason to enter a mode where a RAM dump can be obtained. For example, if there is no reason to enter upload mode, the boot loader (705) can perform a normal boot. Conversely, if it enters upload mode, the boot loader (705) can perform zeroing on the area to be zeroed at that time.

[0109] If, as a result of monitoring operation 770, the user terminal (101, 800) does not enter a mode where a RAM dump can be secured, the kernel (703) may continue to monitor for entry into a mode where a RAM dump can be secured, or may terminate the monitoring operation.

[0110] As a result of monitoring operation 770, if the user terminal (101, 800) enters a mode where a RAM dump can be secured, in operation 780, the boot loader (705) can decrypt the information encrypted in operation 750 based on the zeroing information stored in operation 760.

[0111] In operation 790, the boot loader (705) can perform zeroing on the area to be zeroed (315) according to the decrypted information (e.g., the starting address and size information of the area to be zeroed (315)).

[0113] FIG. 8 is a block diagram of a user terminal according to one embodiment. Referring to FIG. 8, a user terminal (800) according to one embodiment may include a memory (810) and a processor (830). The memory (810) and the processor (830) may be connected to each other via a communication bus (805).

[0114] The memory (810) can store computer-executable instructions. In addition, the memory (810) can store various information generated during the processing of the aforementioned processor (830). In addition, the memory (810) can store various data and programs. The memory (810) may include volatile memory or non-volatile memory. The memory (810) may store various data by being equipped with a large-capacity storage medium such as a hard disk.

[0115] The processor (830) can access memory (810) to execute stored instructions for running multiple processes. At this time, the instructions may be configured to store zeroing information corresponding to an area to be zeroed among the memory areas allocated to one of the multiple processes. Additionally, the instructions may be configured to monitor whether the user terminal enters a mode where a RAM dump can be obtained before the app process finishes using the allocated memory area. Additionally, if the user terminal enters a mode where a RAM dump can be obtained, the instructions may be configured to zero out the area to be zeroed based on the zeroing information.

[0116] Additionally, the processor (830) may perform at least one method or an algorithm corresponding to at least one method described above through FIGS. 1 to 7. The processor (830) may be a user terminal implemented in hardware having a circuit having a physical structure for executing desired operations. For example, the desired operations may include code or instructions included in a program. The processor (830) may be composed of, for example, a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), or a NPU (Neural Network Processing Unit). For example, the user terminal (800) implemented in hardware may include a microprocessor, a central processing unit, a processor core, a multi-core processor, a multiprocessor, an ASIC (Application-Specific Integrated Circuit), or a FPGA (Field Programmable Gate Array).

[0117] The processor (830) can execute a program and control the user terminal (800). The program code executed by the processor (830) can be stored in memory (810).

[0119] According to one embodiment, a user terminal (101, 800) includes a memory (130, 810) in which computer-executable instructions are stored, and a processor (120, 830) that accesses the memory (130, 810) and executes the instructions for the operation of a plurality of processes (411, 412, 413), wherein the instructions store zeroing information (433, 434, 435) corresponding to an area (315, 355) to be zeroed out of an area of ​​memory (130, 810) allocated to any one of the plurality of processes (411, 412, 413), and monitors whether the user terminal (101, 800) enters a mode in which a RAM dump can be secured before the application process completes the use of the allocated memory (130, 810) area, and When entering a mode where a RAM dump can be secured, the area to be zeroed (315, 355) can be configured to be zeroed based on the zeroing information (433, 434, 435).

[0120] According to one embodiment, the zeroing information (433, 434, 435) may include at least one of the following: first information indicating whether there is one or more areas to be zeroed (315, 355) in the allocated memory (130, 810) area; second information indicating whether to zero out the entire stack or heap of the app process; and third information indicating a list of areas to be zeroed (315, 355).

[0121] According to one embodiment, the area to be zeroed (315, 355) can be set by the app process transmitting the starting address of the area to be zeroed (315, 355) and the size of the area to be zeroed (315, 355) to the application programming interface (API).

[0122] According to one embodiment, the instructions may be configured to monitor whether the RAM dump can be secured by the occurrence of at least one of the input of a predetermined key combination and a kernel panic.

[0123] According to one embodiment, the instructions may be further configured to encrypt information related to the area to be zeroed (315, 355) among the allocated memory (130, 810) areas.

[0124] According to one embodiment, information related to the area to be zeroed (315, 355) may include the starting address of the area to be zeroed (315, 355) among the allocated memory (130, 810) areas and the size of the area to be zeroed (315, 355).

[0125] According to one embodiment, the instructions may be further configured to determine whether encryption of information related to the area to be zeroed (315, 355) has failed based on the zeroing information (433, 434, 435), and if it is determined that encryption has failed, to zero out the entire allocated memory area (130, 810) or to zero out the stack or heap of the app process.

[0126] According to one embodiment, the instructions may be configured to decrypt the encrypted information based on the zeroing information (433, 434, 435) and perform the zeroing on the area to be zeroed (315, 355) according to the decrypted information.

[0127] According to one embodiment, the instructions may be configured to further perform at least one of the operations of zeroing out the entire allocated memory (130, 810) area and zeroing out the stack or heap of the app process when the decryption of the encrypted information fails.

[0128] According to one embodiment, the commands may be further configured to receive a designation for the area to be zeroed out (315, 355) from the app process.

[0129] According to one embodiment, the instructions may be configured to further perform at least one of the following operations: zeroing out the entire allocated memory (130, 810) area and zeroing out the stack or heap of the app process when the storage of the zeroing information (433, 434, 435) fails or the reading of the zeroing information (433, 434, 435) fails.

[0130] According to one embodiment, the commands may be configured to delete the zeroing information (433, 434, 435) of the app process as the operation of the app process ends.

[0131] According to one embodiment, a method for zeroing out memory (130, 810) of a plurality of processes (411, 412, 413) running on a user terminal (101, 800) comprises: an operation 210 of storing zeroing information (433, 434, 435) corresponding to an area to be zeroed out (315, 355) among the memory (130, 810) areas allocated to any one of the plurality of processes (411, 412, 413); an operation 220 of monitoring whether the user terminal (101, 800) enters a mode capable of securing a RAM dump before the app process completes the use of the allocated memory (130, 810) area; and, if the user terminal enters a mode capable of securing a RAM dump, [to the] area to be zeroed out (315, 355) based on the zeroing information (433, 434, 435). It may include operation 230 that performs zeroing for.

[0132] According to one embodiment, the monitoring operation may include an operation to monitor whether the RAM dump can be secured by the occurrence of at least one of the input of a predetermined key combination and a kernel panic.

[0133] According to one embodiment, the memory (130, 810) zeroing method may further include an operation of encrypting information related to the area to be zeroed (315, 355) among the allocated memory (130, 810) areas.

[0134] According to one embodiment, information related to the area to be zeroed (315, 355) may include the starting address of the area to be zeroed (315, 355) among the allocated memory (130, 810) areas and the size of the area to be zeroed (315, 355).

[0135] According to one embodiment, a method for zeroing out memory (130, 810) of a plurality of processes (411, 412, 413) running on a user terminal (101, 800) comprises: an operation 510, 520 of allocating an available memory (130, 810) area to an app process upon receiving a request for memory (130, 810) allocation from any one of the plurality of processes (411, 412, 413); an operation 5360 of encrypting information related to the area to be zeroed (315, 355) in response to the app process specifying an area to be zeroed (315, 355) among the memory (130, 810) areas allocated to the app process; an operation 540 of storing zeroing information (433, 434, 435) corresponding to the area to be zeroed (315, 355); and the It may include an operation 550 for monitoring whether the user terminal (101, 800) enters a mode where a RAM dump can be secured before the app process completes the use of the allocated memory (130, 810) area, and an operation 560 for performing zeroing on the area to be zeroed (315, 355) by decrypting the encrypted information based on the zeroing information (433, 434, 435) when the RAM dump can be secured.

[0136] According to one embodiment, the zeroing information (433, 434, 435) may include at least one of the following: first information indicating whether there is one or more areas to be zeroed (315, 355) in the allocated memory (130, 810) area; second information indicating whether to zero out the entire stack or heap of the app process; and third information indicating a list of areas to be zeroed (315, 355).

[0137] According to one embodiment, the memory (130, 810) zeroing method may further include at least one of the following: an operation to zero out the entire allocated memory (130, 810) area in at least one of the following cases: failure to store the zeroing information (433, 434, 435), failure to read the zeroing information (433, 434, 435), failure to encrypt information related to the area to be zeroed (315, 355), and failure to decrypt the encrypted information; and an operation to zero out the stack or heap of the app process.

Claims

Claim 1 A user terminal comprises: a memory in which computer-executable instructions are stored; and a processor that accesses the memory and executes the instructions for the operation of a plurality of processes, wherein the instructions are configured to encrypt information related to the area to be zeroed, store zeroing information corresponding to the area to be zeroed, in response to a designation of an area to be zeroed among a memory area allocated to any one of the plurality of processes, and monitor whether the user terminal enters a mode in which a RAM dump can be secured before the application process completes the use of the allocated memory area, and if the user terminal enters a mode in which a RAM dump can be secured, decrypt the encrypted information based on the zeroing information to zero out the area to be zeroed. Claim 2 A user terminal according to claim 1, wherein the zeroing information comprises at least one of: first information indicating whether there is one or more areas to be zeroed in the allocated memory area; second information indicating whether to zero out the entire stack or heap of the app process; or third information indicating a list of areas to be zeroed. Claim 3 delete Claim 4 delete Claim 5 delete Claim 6 delete Claim 7 delete Claim 8 delete Claim 9 delete Claim 10 delete Claim 11 delete Claim 12 delete Claim 13 A memory zeroing method for a plurality of processes running on a user terminal, comprising: storing zeroing information corresponding to an area to be zeroed among a memory area allocated to any one of the plurality of processes; monitoring whether the user terminal enters a mode where a RAM dump can be secured before the app process completes the use of the allocated memory area; and, if the user terminal enters a mode where a RAM dump can be secured, performing zeroing of the area to be zeroed based on the zeroing information, wherein in at least one of the cases where the storage of the zeroing information fails, where the reading of the zeroing information fails, where the encryption of information related to the area to be zeroed fails, and where the decryption of the encrypted information fails, the entire allocated memory area to be zeroed; or further comprising at least one of the operations of zeroing the stack or heap of the app process. Claim 14 A memory zeroing method according to claim 13, wherein the monitoring operation includes monitoring whether the RAM dump can be secured by the occurrence of at least one of inputting a predetermined key combination or a kernel panic. Claim 15 A memory zeroing method according to claim 13, further comprising an operation of encrypting information related to the area to be zeroed among the allocated memory areas. Claim 16 In paragraph 15, the information related to the area to be zeroed includes the starting address of the area to be zeroed among the allocated memory areas and the size of the area to be zeroed, a memory zeroing method. Claim 17 A memory zeroing method for a plurality of processes running on a user terminal, comprising: an operation of allocating an available memory area to an app process upon receiving a request for memory allocation from any one of the plurality of processes; an operation of encrypting information related to the area to be zeroed in response to the app process specifying an area to be zeroed among the memory areas allocated to the app process; an operation of storing zeroing information corresponding to the area to be zeroed; an operation of monitoring whether the user terminal enters a mode where a RAM dump can be secured before the app process completes the use of the allocated memory area; and an operation of performing zeroing of the area to be zeroed by decrypting the encrypted information based on the zeroing information when the user terminal enters the mode where a RAM dump can be secured. Claim 18 A memory zeroing method according to claim 17, wherein the zeroing information comprises at least one of: first information indicating whether there is one or more areas to be zeroed in the allocated memory area; second information indicating whether to zero out the entire stack or heap of the app process; or third information indicating a list of areas to be zeroed. Claim 19 A memory zeroing method according to claim 17, further comprising: an operation to zero out the entire allocated memory area in at least one of the following cases: failure to store the zeroing information, failure to read the zeroing information, failure to encrypt information related to the area to be zeroed, or failure to decrypt the encrypted information; or at least one of the following operations to zero out the stack or heap of the app process. Claim 20 A computer program stored on a computer-readable recording medium in combination with hardware to execute the method of any one of claims 13 through 19.

Images