KR20200006452A - Method and apparatus for defending remote attacks of device - Google Patents

Abstract

The present invention provides a method for defending software attacks from a remote attacker by using a memory protection unit (MPU) of a lightweight Internet of things (IoT) device. According to the present invention, the method comprises: a step of setting an execution code including a boot code and a reference data region as a system MPU region in a system control region of a memory; a step of setting an access attribute to refuse modification with respect to the set MPU region after activation; a step of setting a system to restart a processing routine of an exception generated when illegal modification with respect to the system MPU region is tried by a remote attacker; and a step of activating the system MPU region. Accordingly, the method excludes inflow of an external attacker traffic into a lightweight IoT device, objectively diagnoses a situation and actively manages the situation in a network level through an external gateway with relatively higher security, removes stress for additional hardware modification for applying security technology to be economic, and can be promptly applied to a previously manufactured lightweight IoT device to provide high compatibility.

Description

METHOD AND APPARATUS FOR DEFENDING REMOTE ATTACKS OF DEVICE}

Embodiments of the present invention relate to a defense method and a defense device for remote attack of a lightweight IoT device, and a defense method and device for protecting the executable code and reference data inside the lightweight IoT device.

Internet of Things (IoT) technology can provide an environment in which devices (objects) are connected to each other through the Internet, transcending physical locations and freely exchanging data between lightweight IoT devices.

However, due to the openness, anyone can access the lightweight IoT device through the Internet. In particular, in the case of a light weight IoT device, since it operates with limited security resources and low security, it may be easily exposed to an external remote attacker.

In general, it is a form of software attack by a remote attacker, using a software vulnerability inside a target lightweight IoT device to remotely inject the attack code into the lightweight IoT device, and to take over control of the lightweight IoT device or to a lightweight IoT device. There is a form of leaking stored information to the outside.

In the case of the conventional security technology for solving the above problems, a technique for controlling access to the memory area, such as denying access to the memory area into which the attack code is inserted using hardware or software such as a memory protection unit, is proposed. have.

However, even a control program executed with a higher privilege may be a target of a remote attack, and a bypass attack pattern is released in which an attack code releases access to a protected memory area and inserts an attack code after an attack code obtains a superior execution authority. .

In other words, the control program for diagnosing and coping with the attack situation may also be exposed from external attacks, so there is a need for reliable security elements inside the lightweight IoT device.

An embodiment of the present invention aims to block a remote attacker's access to a lightweight IoT device through a self-locking technique for the memory protection unit.

A method for defending against a software attack by a remote attacker using a memory protection unit (MPU) of a lightweight IoT device according to an embodiment of the present invention includes a system for executing code and a reference data area including boot code in a system control area of a memory. Setting an access property to designate an MPU area and to reject a change to a preset MPU area after activation; Setting a system to restart the processing routine of an exception occurring when an illegal change attempt is made to the system MPU area by the remote attacker; And activating the system MPU region.

The system MPU area can be released only by restarting the system.

The system MPU region may maintain a locked state that cannot be changed or reset after the system MPU region is activated.

When the system is restarted, the method may further include transmitting a restart fact to a gateway in a boot code execution step, and determining a next operation according to a response received from the gateway.

The determining may further include continuing to execute the boot code if it is determined by the gateway that the attack is not attacked by the remote attacker.

The determining may include receiving firmware through the gateway when the response value indicates a firmware update; Verifying the received firmware; And updating the firmware.

The determining may further comprise restarting the system after the update.

The determining may include performing integrity verification for an operating system and an application to be executed when the response value indicates that no firmware update is required.

A method for defending against a software attack by the remote attacker from a software attack on a physical network including a light weight IoT device according to an embodiment of the present invention receives a system restart from the light weight IoT devices. Making; Analyzing system restart facts received from the lightweight IoT devices to determine whether the remote attacker is attacked or whether the firmware is defective; And blocking the inflow of suspicious traffic when determined as the attack situation by the remote attacker.

If it is determined that the firmware is defective, transmitting a firmware update to the lightweight IoT devices, and transmitting the firmware received from the server to the lightweight IoT devices so that the lightweight IoT devices update the firmware. can do.

The method may further include verifying firmware received from the server.

The remote attack defense device of a lightweight IoT device for defending against a software attack by a remote attacker according to an embodiment of the present invention is generated when an attempt is made to access a system MPU area in which at least one MPU area has an access property set to access denied. It may include a memory protection unit control unit for setting the processing routine of the exception to restart the system.

The memory protection unit controller may designate an execution code including a boot code and a reference data area as the system MPU area, and set the access attribute of the system MPU area to access denied.

The memory protection unit controller may designate a portion of the remaining regions other than the system control region as a general MPU region, and set an access attribute of the general MPU region to one of read write, read only, and deny access.

The system MPU area can be released only by restarting the system.

After the system MPU area is activated, the system MPU area may remain locked, which cannot be changed or reset.

When the system is restarted, the boot code execution step may further include a CPU for transmitting the fact of restarting to the gateway and determine the operation according to the response received from the gateway.

If the CPU determines that the gateway is not attacked by the remote attacker, the CPU continues executing the boot code, and when the response value informs the firmware update, the CPU receives the firmware received from the server through the gateway. You can update it.

According to the embodiment of the present invention, since the Internet is not connected in the boot code execution step, it is possible to exclude the external attacker traffic inflow into the lightweight IoT device.

In addition, according to an embodiment of the present invention, if a real attack suspicion occurs after the protected memory area is activated, instead of a lightweight IoT device with relatively limited security resources, a relatively secure external gateway is provided. The situation can be diagnosed more objectively and actively responded at the network level.

In addition, according to the embodiment of the present invention, by using the memory protection unit that is already mounted as a part of the chip for the light weight IoT device as it is, there is no additional hardware change burden for applying the security technology, economical, lightweight already produced As a technology that can be directly applied to IoT devices, it has the advantage of high compatibility.

1 is a block diagram illustrating a processor according to an embodiment of the present invention.
2 is a block diagram illustrating a memory according to an embodiment of the present invention.
3 illustrates a process of specifying an MPU region and defining an access attribute according to an embodiment of the present invention.
4 is a flowchart illustrating a method of setting an MPU region executed as part of a boot code according to an embodiment of the present invention.
5 is a diagram illustrating an example of code signature verification applied when remotely distributing an application through the Internet according to an embodiment of the present invention.
6 illustrates a remote attack defense process of a lightweight IoT device according to an embodiment of the present invention.
7 is a flowchart illustrating a method of determining and responding to a malicious attack in a gateway according to an embodiment of the present invention.
8 is a flowchart illustrating a remote attack defense method in a lightweight IoT device according to an embodiment of the present invention.
9 is a block diagram illustrating an example of an MPU region in a lightweight IoT device according to an embodiment of the present invention.

DETAILED DESCRIPTION Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present invention. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present invention. In the drawings, parts irrelevant to the description are omitted in order to clearly describe the present invention, and like reference numerals designate like parts throughout the specification.

Throughout the specification and claims, when a portion is said to "include" a certain component, it means that it can further include other components, without excluding other components unless specifically stated otherwise.

Now, a remote attack defense method and apparatus for a lightweight IoT device according to an embodiment of the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram illustrating a processor according to an embodiment of the present invention.

Referring to FIG. 1, the processor 100 includes a central processing unit (CPU) 101, a memory protection unit (MPU) 102, a memory bus 103, and a system controller 104. , Input / output (I / O) controller 105 and memory controller 106.

The CPU 101 communicates with the memory through the MPU 102, the memory bus 103, and the memory controller 106. That is, all the memory addresses referenced by the CPU 101 are designed to pass through the MPU 102, which governs the memory bus 103. The CPU 101 executes software with reference to the memory based on the control of the MPU 102.

MPU 102 is an internal component of processor 100 implemented for protection of memory. The MPU 102 restricts access to a specific area of the memory based on individual operations while the software stored in the memory is executed by the CPU 101, or protects the memory area from illegal access of the malicious software. Access control can be performed.

2 is a block diagram illustrating a memory according to an embodiment of the present invention.

As shown in FIG. 2, the memory 200 includes a flash memory area 205, a static random access memory (SRAM) area, a peripheral area 204 storing instructions for controlling peripheral devices, and a processor. It includes a System Control area 206 for storing instructions to control.

MPU area 2 (202) designated as the area to be protected by the MPU among the flash memory areas, MPU area 1 201 designated as the area to be protected by the MPU among the peripheral device areas, and MPU area designated as the area to be protected by the MPU among the system control areas. 3 203 may be set through an MPU setting related register mapped to MPU area 3 203 of the memory area. That is, the system control area includes registers for setting the operation of the processor and among the processor operation setting control operations, the registers are involved in setting of the MPU.

3 illustrates a process of specifying an MPU region and defining an access attribute according to an embodiment of the present invention.

The MPU controller 300 may be a software module mapped to MPU region 3 (203 of FIG. 2) among regions of the memory, and having register values set (or defined) for controlling the operation of the MPU. The MPU 102 may perform protection for each of the regions 205, 204, and 206 of the memory based on the register setting value defined by the MPU controller 300, which is defined by the MPU controller and the MPU controller. The operation of the MPU will be described.

As shown in FIG. 3, the MPU controller 300 may include MPU setting related registers 301, 302, and 303, may designate each MPU region, and define an access attribute for each MPU region. have.

An access property may be declared in one of read / write, read only, and no access types, and attempts to access the MPU area with privileges other than the declared property. In this case, it can be set to generate an exception, such as a system fault.

The maximum number of MPU areas that can be designated simultaneously in the MPU 102 is determined by the number of registers included in the MPU control unit 300. Accordingly, in order to secure a memory area having various attributes, system software having a high execution privilege may register MPU setting-related registers 301 of the MPU controller 300 based on a system operating policy during system operation. , 302, 303 may be reset.

According to the exemplary embodiment of the present invention, the MPU control unit 300 may access the MPU area 1 201 and the MPU area 1 through the MPU setting related register 1 301 and the MPU setting related register 2 302 through the MPU setting related register 1 301. Access attributes for region 2 202 and MPU region 2 and MPU configuration related register 3 303 may define access attributes for MPU region 3 203 and MPU region 3. That is, the MPU controller 300 may not only access the MPU region 1 201 and the MPU region 2 202 through the MPU setting related registers 301, 302, and 303, but may also access the system control region ( In 206, the access attribute of the MPU control unit 300, which is the MPU region 3 203, may also be set. That is, the MPU control unit 300, which specifies MPU areas to be protected and manages external access attributes for the specified MPU areas, includes an MPU setting related register value in which its operation is defined inside the MPU control unit itself. An access attribute for the area 3 203 may be specified using the setting values of the register 303 related to the MPU setting. For example, the MPU controller 300 may implement a one-time set-up effect on the MPU 102 in hardware.

MPU region 3 (203), once set as a self-lock, is hardware guaranteed to be released only through a system reset. Therefore, after the MPU zone is activated by system restart, no software running inside the lightweight IoT device can change the access property of the MPU zone 3 (203) that has already been set, and any access attempting to change it with malicious intentions. Attempts result in exceptions, which are system errors.

That is, the MPU control unit 300 may set the MPU area 3 203 to reject a change to the magnetic area in the future. After the MPU area 3 203 is activated, the MPU control unit 300 may control the MPU control area through the MPU area 3 203. It is not possible to change existing settings.

In the embodiment of the present invention, the one-time set-up of the memory protection area is applied by applying the self-locking substrate for the MPU control unit 300 by the MPU control unit 300 to the chip initialization process. Provide effect. This may provide the root of trust on a MPU basis that conventional software technology does not guarantee. The highest level of reliability here is the basis for system-wide reliability as a measure of ensuring safe execution of software. Safe execution means that the program code performs all the processes in the order in which they were first installed without skipping or changing the order of execution. It also implies the integrity of the code itself.

4 is a flowchart illustrating a method of setting an MPU region executed as part of a boot code according to an embodiment of the present invention.

Referring to FIG. 4, when power is on (S401), execution of the boot code is started (S402).

The MPU control unit 300 first disables the interrupt and the exception (S403), and then sets up the interrupt and the exception handling routine (S404). It also sets up an exception handler routine for exceptions that occur when denying access to MPU areas protected by the MPU 102 in the memory area. The MPU control unit 300 according to the embodiment of the present invention sets MPU setting related registers 301, 302, and 303 so that the system is immediately restarted when an access denial exception occurs.

Next, the MPU control unit 300 designates the MPU area 1 and the MPU area 2 that need to be protected as the MPU area among the remaining memory areas except the MPU area 3 203 mapped to the MPU setting related register of the MPU control area among all the memory areas. In step S405, access attributes for the specified MPU region are set.

When the MPU area settings for MPU area 1 and MPU area 2 are both completed, the MPU control unit 300 may deny the corresponding access to the MPU area 3 203 when a change of the setting for the MPU area 3 203 is requested later. The access attribute is set (S406).

Finally, the MPU control unit 300 enables all set MPU areas (S407), and activates an interrupt to enable exception processing (S408).

From this moment, when the MPU area is activated, the MPU area remains locked, which cannot be changed or reset by any software inside the lightweight IoT device except the reboot.

As described above, according to the exemplary embodiment of the present invention, the MPU control unit 300 designates the MPU region 3 (203) as the memory protection region. Thus, the one-time setting effect on the memory protection region may be performed through the so-called self-locking. Can be secured as an enemy. In particular, the effect of a one-time setting on a denial of access or read-only type of memory can protect the system's root of trust from a security standpoint because it allows hardware-level protection of code and data from control software running with higher privileges. Can provide.

Next, an embodiment in which the MPU 102 is applied to read-only reference data protection during cryptographic verification based on the highest reliability provided through the self-lock setting according to the embodiment of the present invention will be described. Cryptographic verification here refers to cryptographic operations that are performed at the time of authentication or signature verification, and reference data is the cryptographic key information used at this time, which cannot be changed except by legal means and does not require confidentiality of the data itself. Have For example, a representative example of the reference data is a public key value or a hash value for the certificate or code signature verification of a server in a certificate-based mutual authentication process.

5 is a diagram illustrating an example of code signature verification applied when remotely distributing an application through the Internet according to an embodiment of the present invention.

Referring to FIG. 5, in general, the program and code signing information are distributed together in an application package, and the remote device that installs the application performs signature verification to determine whether the integrity of the program code as well as the authentication of the original distributor is compromised. To judge. At this time, the signature information is generated by a signature verification mechanism using an Elliptic Curve Digital Signature Algorithm (ECDSA) based on an Elliptical Curve Cryptography (ECC).

For example, the Sign Tool generates an elliptic curve cryptographic key pair consisting of a public key (Kpublic) and a private key (Kprivate), and uses the ECDSA Signature Algorithm to program the private key. Create a signature for the application. The signature thus generated is distributed along with the public key and the application code.

For example, a device that installs and executes an application can verify the integrity of the program code by using a signature and a public key distributed with the application code. In this case, the remote device needs a means for verifying ownership of the public key itself used for signature verification as well as signature verification for program code. Therefore, a read-only data protection technology is required so that the public key information owned by the distributor can be safely stored in the device in advance and referenced only during verification. Therefore, by applying the self-locking setting of the MPU control unit 300 proposed in the embodiment of the present invention to the corresponding device, the reference data stored in the MPU area is protected as read-only. In particular, software other than the original MPU configuration code that is executed as part of the boot code takes hardware-level protection to prevent changes to the reference data. At this time, read-only public key reference data is pre-stored in flash memory as their hash result value instead of the certificate or public key to minimize the storage space when the device is first released, and the hash result value is stored in the flash memory. The specific area is set as the MPU area so that the access property is set to read-only and is referred to as read-only as follows when verifying signature.

"reference data <-installed Digest of K _public

if (reference data = SHA256 (downloaded K _public ))

   authentic

else

   fake "

As illustrated in FIG. 5, in the embodiment shown in FIG. 5, the read-only reference data is secured at the hardware level through the one-time setting effect of the MPU area, but the protection scope is extended to the executable code area to protect the executable code from software attacks. The same applies to

In general, the remote attack by software is introduced to the target device through the network, and after the intrusion, the attack code is inserted through the defense equipment inside the device. Therefore, the success rate of the remote attack also depends on the strength of the internal defense base of the device to be attacked. The embodiment of the present invention provides a device self-defense description by protecting the important execution code and the reference data inside the device in the hardware level through the self-lock setting of the MPU control unit 300.

According to the defense description proposed in the embodiment of the present invention, the system is restarted by the exception handling routine when an attack attempt on the MPU region actually occurs. However, restarting alone has limitations in accurately determining or technically addressing an attack. Moreover, device-level defenses alone do not fundamentally block the path of remote attack attempts from outside the network, requiring more aggressive detection and response. In particular, the recent botnet attack is fast to target a large number of devices connected to the network, so it is difficult to respond only to individual devices.

Therefore, in the embodiment of the present invention, after activating the MPU in the form of self-locking, the device is connected to the network with the protective substrate inside the device. At this time, when a remote attack is introduced and an attempt is made to neutralize the defense, an exception occurs due to the denial of access in the MPU area. In general, the system running the MPU identifies the cause of the error condition in the exception handling routine and immediately executes the response, and then continues execution after the point where the exception occurred.

In order to solve this problem, the embodiment of the present invention can restart the system immediately without executing the final determination and response of the attack in the currently executing exception handling context and return to the initial state of the boot code before the MPU activation. have. At this time, when the system is restarted, traffic from outside the network is blocked and the system is restarted in the boot code state that enables only one-to-one communication with the gateway. Therefore, the embodiment of the present invention uses the MPU, but in the case of an infringement situation of the MPU area, a specific judgment and processing of the attack is performed through an external gateway that is a third party instead of being performed by the system software inside the device. Therefore, the restarted fact is collected from various devices not only in the device but also in the physical network including the device, and based on this, the final attack is determined and responded to. This will be described in detail with reference to FIG. 6.

6 is a flowchart illustrating a remote attack defense process of an IoT device according to an embodiment of the present invention, and FIG. 7 is a flowchart illustrating a method of determining and responding to a malicious attack in a gateway according to an embodiment of the present invention.

As shown in FIG. 6, server 603 provides remote management and services for IoT device 601. The server 603 communicates with the gateway 602 via a secure channel 605 such as VPN, TLS, or the like. The gateway 602 manages the physical network 600 that contains the IoT device 601. The devices 601 may recognize the gateway 602 as a secure entity.

As shown in FIG. 7, in the embodiment of the present invention, a remote attack by the attacker 604 is launched (S701), and the attacker 604 is connected to the IoT device 601 via the gateway 602. If an attack is attempted, the IoT device 601 generates an exception according to the MPU defense description described above, and the system is restarted (S702 and S703).

The IoT device 601 executes the boot code immediately after restarting (S704), and informs the gateway 602 of the reset event in the boot code execution step (S705).

The gateway 602 analyzes restart patterns received so far from the corresponding IoT device 601 and other IoT devices in the same network to determine whether an attack is made by the attacker 604 or whether the firmware has its own defect (S706).

If it is determined that the attack situation, the gateway 602 blocks the inflow of suspicious traffic (S710).

The gateway 602 transmits the attack situation and the traffic information to the server 603 (S711).

The embodiment of the present invention also proposes a firmware update process for securely installing the official firmware distributed by the server 603 in the IoT device 601 around the gateway 602. In the attack detection (S706) and the corresponding step (S710) according to the embodiment of the present invention described above, the restarted IoT device 601 transmits the restart situation to the gateway 602 in the boot code. Therefore, in the boot code execution step, the gateway 602 and the IoT device 601 each include a network module for one-to-one communication between the two devices, and the network module is a link-level communication that operates on media between the two devices. It can be a module that performs In this case, since the IoT device 601 can perform one-to-one communication with the gateway 602 at the link level, but the communication with the external network entity is impossible, the IoT device 601 executes the code safely in a state where external attack traffic is blocked inherently. Therefore, the IoT device 601 according to the embodiment of the present invention receives and updates the original firmware only through one-to-one communication with the gateway 602 which is secured in the boot code. In this case, the mutual authentication between the IoT device 601 and the gateway 602 and the key exchange for channel encryption follow the embodiment of the read-only reference data described with reference to FIG. 5.

The IoT device 601 notifies the gateway 602 of the system restart event every time in the boot code execution step (S705), and determines the next operation according to the response value received from the gateway 602.

If it is determined that the gateway 602 is not an attack situation, the gateway 602 transmits an OK response value to the IoT device 601 (S707).

When the IoT device 601 receives the OK response value from the gateway 602, the IoT device 601 continues to execute the remaining boot code (S708).

On the other hand, upon receiving the attack situation and traffic information from the gateway 602, the server 603 checks whether the updated firmware exists (S712), and transmits the latest version of the updated firmware to the gateway 602 (S713). .

The gateway 602 verifies the updated firmware (S714).

The situation in which the system is restarted from the point of view of the IoT device 601 may indicate tampering as a result of the integrity check of the operating system and the application image at the boot code stage, or an illegal memory access attempt is made by a remote attacker during application execution. This is the case. Therefore, the gateway 602 should receive the restart from the IoT device 601 and detect whether the attack or the firmware itself is defective.

When the verification of the updated firmware is completed in the gateway 602, the IoT device 601 is notified of the firmware update (S715).

When the IoT device 601 receives the firmware update, the IoT device 601 voluntarily restarts the system (S716) and starts executing the boot code (S717).

The IoT device 601 transmits the fact of restarting in the boot code to the gateway 602 (S718), and the gateway 602 transmits the firmware update to the IoT device 601 as a response value (S719), thereby providing the official firmware. The IoT device 601 transmits the information to the IoT device 601 so as to update itself.

The IoT device 601 performs a firmware update (S720), restarts the system (S720), and starts boot code execution (S721).

As such, when the gateway 602 receives the restart from the IoT device 601, the gateway 602 detects whether the attack or the firmware has its own defect, blocks the inflow of attack traffic in a specific countermeasure method, or sets the official firmware on the IoT device. Forward to 601 to induce the IoT device 601 to perform the update itself. In a situation where the system is restarted, the gateway 602 transfers the firmware update to the IoT device 601 on behalf of the server 603 in the process of distributing the firmware in the server 603, and the IoT device 601 voluntarily Will be restarted. Occasionally, the firmware itself may invade the MPU memory protection area by a software defect and may be suspected to attack, causing the system to restart. However, the gateway 602 quickly determines an error condition due to the firmware itself defect and causes the server 604 to determine the failure. Induce redistribution of this resolved firmware.

8 is a flowchart illustrating a remote attack defense method in an IoT device according to an embodiment of the present invention.

Referring to FIG. 8, when the initial power is applied to the IoT device 601, the boot code is executed first and basic initialization of the system is executed (S802 and S803).

The IoT device 601 sets up a corresponding network module so that one-to-one communication with the gateway 602 that currently manages the network is possible at the link level. After the initialization operation for the network module, the IoT device 601 transmits the fact that the current system is restarted to the gateway 602 and receives a response value from the gateway 602 (S804).

The IoT device 601 determines an operation to be performed later based on the received response value.

If it is determined that the firmware update is necessary based on the received response value (S805), the IoT device 601 receives the firmware from the gateway 602 and verifies whether the corresponding firmware is the official firmware distributed by the server 603. Firmware verification is in accordance with the embodiment of code signature verification described above.

When the firmware verification is successfully completed, the IoT device 601 updates the firmware by writing the firmware in an inactive memory that is an execution code area of the IoT device 601 (S806) and restarts the system (S807).

If the IoT device 601 receives a response value indicating that the firmware update process is not required from the gateway 602, the IoT device 601 performs integrity verification on an OS and an application to be executed later (S808). The specific method of integrity verification follows the same embodiment as the code signature verification described above. At this time, if tampering with respect to the image is found, the firmware update procedure is performed through the gateway 602 (S806). On the contrary, if the integrity check for the OS and APP images is successfully completed, the IoT device 601 performs MPU region setting for the MPU control unit 300 (S809). The MPU control unit 300 is set as the MPU area 710 for the critical execution code and the reference data area including the boot code, and the change in its MPU area mapped to the MPU control unit 300 is blocked at the source described with reference to FIG. 4. Set access properties according to the method.

In the last step, the operating system 706 and the application 708 are run to start the original service of the IoT device 601 (S810 and S811). At this time, since communication with the outside is possible and the services of the IoT device 601 operate in earnest, they are simultaneously exposed to a remote attacker. However, since the MPU-based defense substrate proposed in the embodiment of the present invention is already in operation, when an illegal memory access is attempted by a remote attacker, it may be processed according to the access denial setting of the corresponding protection region. In other words, if an illegal memory access is attempted by a remote attacker, an exception occurs. If an exception occurs (S812), as described above, the system is restarted and restarted from the boot code execution step (S807, S802).

As such, in the embodiment of the present invention, the system is designed to suddenly restart during execution due to a remote attack or a defect in the internal software of the device, but sometimes the operating system and the application image are received from the gateway 602 or receive a firmware update request from the boot process. Depending on the results of the integrity check, the system can be restarted in stages. Therefore, after receiving the fact that the IoT device 601 is restarted, the gateway 602 accurately determines the cause of the restart of the IoT device 601 and provides a formal firmware to the IoT device 601 when necessary.

9 is a block diagram illustrating an example of an MPU region in an IoT device according to an embodiment of the present invention.

Referring to FIG. 9, the IoT device 601 is an executable code area protected by the MPU control unit 300, a network module 903, a firmware update module and an operating system for one-to-one regional communication at the link level with the gateway 602. The module is installed to protect the boot code 902 including the application verification module, the MPU exception handling routine 901, and the module 907 that receives firmware update requests from the gateway 602 and restarts the system. The area is set as the MPU area.

In addition, since the code area of the operating system 905 and the application program 906 may be flexibly changed through a firmware update later, the embodiment of the present invention excludes the protection area, but the update is not expected. Can be included as the protection target of the MPU.

Although the embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements of those skilled in the art using the basic concepts of the present invention defined in the following claims are also provided. It belongs to the scope of rights.

Claims (18)

As a method of defending against software attacks by remote attackers using a memory protection unit (MPU) of a lightweight IoT device,
Designating an execution code including a boot code and a reference data area as a system MPU area in a system control area of a memory, and setting an access attribute to reject a change to a preset MPU area after activation;
Setting a system to restart the processing routine of an exception generated when an illegal change attempt is made to the system MPU area by the remote attacker; And
Activating the system MPU region;
Way. In claim 1,
The system MPU area is released only by restarting the system.
Way. In claim 1,
The system MPU region maintains a locked state that cannot be changed or reset after the system MPU region is activated.
Way. In claim 1,
When the system is restarted, in the boot code execution step, transmitting the restart fact to the gateway, and
Determining a next operation according to a response received from the gateway.
Way. In claim 4,
The determining may further include continuing to execute the boot code if it is determined by the gateway that the attacker is not attacked by the remote attacker.
Way. In claim 4,
The determining step
Receiving firmware through the gateway when the response value informs of a firmware update;
Verifying the received firmware; And
Updating the firmware
Way. In claim 6,
The determining step may further comprise restarting the system after the update.
Way. In claim 4,
The determining step includes performing integrity verification of the operating system and application to be executed when the response value indicates that no firmware update is required.
Way. A method for defending against software attacks by a remote attacker on a lightweight IoT device at a gateway that governs a physical network containing lightweight IoT devices,
Receiving system restart from the lightweight IoT devices;
Analyzing system restart facts received from the lightweight IoT devices to determine whether the remote attacker is attacked or whether the firmware is defective; And
Blocking the inflow of suspicious traffic when determined to be attacked by the remote attacker;
Way. In claim 9,
If it is determined that the firmware is defective, transmitting a firmware update to the lightweight IoT devices, and
Sending firmware received from a server to the lightweight IoT devices so that the lightweight IoT devices update firmware.
Way. In claim 10,
Verifying firmware received from the server;
Way. As a remote attack defense device of a lightweight IoT device to defend against software attack by a remote attacker,
And a memory protection unit controller configured to set the system to restart the processing routine of an exception occurring when attempting to access a system MPU area in which at least one MPU area has an access property set to access denied.
Remote attack defense. In claim 12,
The memory protection unit control unit designates an execution code including a boot code and a reference data area as the system MPU area, and sets the access property for the system MPU area to access denied.
Remote attack defense. In claim 12,
The memory protection unit control unit designates some of the remaining areas other than the system control area as a general MPU area, and sets an access attribute of the general MPU area to one of read write, read only, and access denied.
Remote attack defense. In claim 12,
And the system MPU zone is released only by restarting the system. In claim 12,
And after the system MPU region is activated, the system MPU region maintains a locked state that cannot be changed or reset. In claim 12,
If the system is restarted, the boot code execution step further includes a CPU for transmitting the fact that the restart to the gateway and determines the operation according to the response received from the gateway
Remote attack defense. In claim 12,
If the CPU determines that the gateway is not attacked by the remote attacker, the CPU continues executing the boot code, and when the response value informs the firmware update, the CPU receives the firmware received from the server through the gateway. Updated
Remote attack defense.

Images