KR102392474B1 - Internet-of-things module - Google Patents

Abstract

The IoT module according to an embodiment of the present invention includes a memory unit having a booting area for storing booting firmware and first security information, and a security area for storing a firmware release version and second security information, and the and a processor unit configured to compare the first security information and the second security information when the booting firmware is executed, and to compare the version of the booting firmware with the firmware distribution version to determine whether to proceed with the booting process.

Description

Internet of Things Module {INTERNET-OF-THINGS MODULE}

The present invention relates to an IoT module.

Due to the characteristics of the Internet of Things that are connected to the communication network, the security performance of the IoT module is very important. However, unlike computer devices or mobile devices implemented as expensive systems, IoT modules produced to provide IoT functions to general devices or things are implemented as relatively low-cost systems, so it may be difficult to have an expensive security system. . In addition, since the manufacturer of the IoT module and the entity that produces and sells the device equipped with the IoT module to the end consumer may be different, the boot firmware stored in the IoT module may be hacked or unintentionally rolled back to the previous version. ), etc., may occur.

One of the problems to be achieved by the technical idea of the present invention is to provide an IoT module capable of securely managing firmware while implementing a secure booting function by utilizing a secure block of a memory.

The IoT module according to an embodiment of the present invention includes a memory device having a booting area for storing booting firmware and first security information, and a security area for storing a firmware release version and second security information, and the and a processor unit configured to compare the first security information and the second security information when the booting firmware is executed, and to compare the version of the booting firmware with the firmware distribution version to determine whether to proceed with the booting process.

The IoT module according to an embodiment of the present invention includes a device having a boot area for storing booting firmware required for booting, and a security area for storing a firmware distribution version for providing a rollback inspection function of the booting firmware. 1 A memory device, a second memory device having a secure boot logic to obtain the firmware distribution version by accessing the secure area, and a version of the booting firmware are compared with the firmware distribution version to determine whether to rollback the booting firmware It includes a processor unit that

The IoT module according to an embodiment of the present invention includes a memory device having a boot region for storing booting firmware, a security region separated from the boot region and storing a predetermined authentication key, and a hardware unique structure from an internal circuit structure. and a hardware-specific key generation circuit for generating a key, wherein when the booting firmware is first executed, the hardware-specific key is stored in the secure area as the authentication key through the volatile memory device, and an authentication procedure using the hardware-specific key and a processor unit configured to obtain an access right to the security area through

According to an embodiment of the present invention, firmware integrity can be secured by preventing an unintentional rollback of the firmware without a separate area such as eFuse or OTP. In addition, in the process of distributing the firmware, the public key mounted on the IoT module can be replaced with the security key of the IoT device manufacturer, who is the main producer of the IoT device equipped with the IoT module. Accordingly, it is possible to reduce the risk of hacking between IoT devices on which the same IoT module is mounted. In addition, a secure boot function may be provided by using information on the security key stored in the security area of the memory device.

Various and advantageous advantages and effects of the present invention are not limited to the above, and will be more easily understood in the course of describing specific embodiments of the present invention.

1 is a diagram schematically illustrating an IoT system that can be implemented with an IoT module according to an embodiment of the present invention.
2 is a diagram provided to explain a manufacturing process of an IoT device equipped with an IoT module according to an embodiment of the present invention.
3 to 5 are block diagrams simply illustrating an IoT module according to an embodiment of the present invention.
6 and 7 are flowcharts provided to explain the operation of the IoT module according to an embodiment of the present invention.
8 and 9 are diagrams for explaining the operation of the IoT module according to an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings.

1 is a diagram schematically illustrating an Internet of Things system according to an embodiment of the present invention.

Referring to FIG. 1 , an IoT system 1 according to an embodiment of the present invention may include an IoT network 2 for mediating communication and a plurality of IoT devices 10-40. . The IoT network 2 may provide a cloud service using the database 3 and the like while facilitating communication between the plurality of IoT devices 10 - 40 .

The IoT devices 10 - 40 may include an IoT module having a communication function with the IoT network 2 . The IoT module may include a processor unit that performs overall control and calculation functions, a memory unit for data storage, a sensor unit that collects surrounding information, and a communication unit that communicates with the Internet of Things network (2). there is. For example, the IoT module included in the air conditioner 21 or the air purifier 22 may include a sensor that measures ambient temperature and humidity, fine dust concentration, and the like. The refrigerator 43 may include a sensor capable of measuring internal temperature and humidity.

The IoT network 2 is a kind of communication network and may mediate communication between the IoT devices 10-40. In an embodiment, the IoT network 2 may have a database 3 , in which the database 3 stores identification information of the IoT devices 10-40 registered in the IoT system 1 . can Other devices having identification information not stored in the database 3 may not operate in conjunction with the IoT system 1 . When a new device is connected to the IoT network 2 , the new device connected to the IoT network 2 is identified by comparing the identification information stored in the database 3 with the identification information of the new device connected to the IoT network 2 . It is possible to determine whether to register with the IoT system (1).

In an embodiment, a module manufacturer that produces and sells the IoT module may be different from a device manufacturer that produces and sells the IoT devices 10-40. That is, a device manufacturer may purchase an IoT module from a module manufacturer, process the purchased IoT module, and manufacture various IoT devices equipped with the IoT module. For example, in the IoT system 1 shown in FIG. 1 , device manufacturers that produce each of the IoT devices 10-40 may all be different.

Since there are various device manufacturers who purchase IoT modules and produce and sell IoT devices, and the quantity of IoT devices produced by device manufacturers is different, module manufacturers install their own security key Manufacturing Internet modules can be difficult in reality. Module manufacturers can implement security functions for booting firmware and operating system by using a common security key, but among IoT devices equipped with the same IoT module, there may be a risk of hacking using the booting firmware.

To solve this problem, a method such as eFuse that intentionally disables some circuits can be used. it may not be According to an embodiment of the present invention, secure boot and firmware rollback protection functions may be provided by using the secure area of the memory mounted in the IoT module. Accordingly, a secure boot function can be implemented without a module manufacturer applying a different security key to each device manufacturer, and an IoT module with a reduced risk of hacking can be provided.

2 is a diagram provided to explain a manufacturing process of an IoT device according to an embodiment of the present invention.

Referring to FIG. 2 , the module manufacturer 50 may sell the IoT module to a plurality of different device manufacturers 61 to 63 . The IoT modules sold by the module manufacturer 50 to the plurality of device manufacturers 61-63 may be identical to each other and may have the same booting firmware. In an embodiment, the booting firmware may be stored in the nonvolatile memory device of the IoT module in the form of a booting image. The device manufacturers 61-63 may process booting firmware stored in the IoT module by the module manufacturer 50 in the process of producing the IoT device equipped with the IoT module.

It is practically impossible for the module manufacturer 50 to differently apply a security key for providing a secure boot function according to each of the IoT devices produced by the plurality of device manufacturers 61-63. Therefore, when the same IoT module is purchased from the module manufacturer 50 and each of the plurality of device manufacturers 61-63 produces and sells IoT devices, the boot image of the IoT module mounted on the specific IoT device is displayed. There is a possibility that other IoT devices may be securely booted or the boot firmware may be rolled back. For example, the IoT module included in the device of the company B 62 or the company C 63 may be securely booted as a boot image of the IoT module included in the device of the company A 61 . Alternatively, the boot firmware of the IoT module included in the device of company B 62 or company C 63 is transferred by the boot firmware included in the boot image of the IoT module included in the device of company A 61 . Versions can be rolled back unintentionally.

In various embodiments of the present disclosure, the IoT module may include a processor unit and a memory unit, and the memory unit may have a secure area accessible only through a predetermined authentication procedure. In the security area of the memory unit, information on a security key for secure booting, a distribution version of booting firmware, etc. may be stored together with an authentication key for confirming an access right to the security area. For example, the authentication key may be a Hardware Unique Key (HuK), and may be generated by the processor unit when the IoT module is first booted and injected into the secure area.

When the IoT module is booted, the processor unit may read the boot image stored in the boot area of the memory unit and execute the booting firmware. At the same time, the processor unit may compare the information on the version of the boot firmware and the security key stored in the boot area with the distribution version of the boot firmware and information on the security key stored in the security area, respectively. Accordingly, it is possible to provide a secure boot function capable of preventing booting by booting images and/or booting firmware copied to an illegal route, and at the same time, prevent unintentional rollback of booting firmware.

3 to 5 are block diagrams simply illustrating an IoT module according to an embodiment of the present invention.

Referring to FIG. 3 , the IoT module 70 according to an embodiment of the present invention includes a first memory unit 71 , a second memory unit 72 , a processor unit 73 , a communication unit 74 , and an interface unit 75 and the like. Each of the units 71 - 75 included in the IoT module 70 may exchange data with each other through the bus 76 .

The first memory unit 71 and the second memory unit 72 may be provided by different memory chips. The first memory unit 71 may be a non-volatile memory device, and the second memory unit 72 may be a volatile memory device. For example, the first memory unit 71 may be implemented as an embedded multi media card (eMMC) or NAND flash memory, and the second memory unit 72 may be implemented as a dynamic random access memory (DRAM). can be

The processor unit 73 may control overall operations of the IoT module 70 . When the IoT module 70 is turned on, the processor unit 73 reads the boot image stored in the first memory unit 71 directly or through the second memory unit 72, such as booting firmware and the operating system. By executing , you can proceed with the booting process. While the booting process is in progress, the processor unit 73 checks whether the booting firmware has been hacked using security information stored in the secure area of the first memory unit 71 and a firmware release version, etc. , it is possible to prevent an unintentional rollback of the booting firmware.

The communication unit 74 may provide one or more wired/wireless communication functions. For example, the communication unit 74 may provide a communication function such as a wireless LAN such as WiFi, Bluetooth, or Zigbee. The interface unit 75 may have a display interface connected to a device such as a camera or a display, and/or a wired communication interface connected to the communication unit 74 . For example, the interface unit 75 may include a Mobile Industry Processor Interface (MIPI) as a display interface, and may include I2C, UART, I2S, etc. as a wired communication interface.

Next, referring to FIG. 4 , the IoT module 100 according to an embodiment of the present invention may include a processor unit 110 , a first memory unit 120 , and a second memory unit 130 . . In an embodiment, the processor unit 110 may include a central processing unit (CPU) 111 , a hardware unique key (HuK) generation circuit 112 , a memory controller 113 , and the like, and may include a system-on-chip (System). -On-Chip, SoC) can be implemented. The first memory unit 120 may be implemented as a non-volatile memory, and may be an eMMC (Embedded Multi Media Card) or a NAND flash memory, for example.

The memory controller 113 may be a controller for setting security properties of the second memory unit 130 . For example, the memory controller 113 may include a TrustZone Protection Controller (TZPC) using a trustzone method for applying logical division by security software and general software to peripheral devices. At least a partial area of the second memory unit 130 may be allocated as a security area by the memory controller 113 .

The first memory unit 120 may include a plurality of booting areas 121 and 122 , a storage area 123 for storing general user data, and a security area 124 . The regions 121-124 may be regions defined in the manufacturing step of the first memory unit 120 . The security area 124 may store an authentication key 125 necessary for confirming an access right to the security area 124 . In an embodiment, the authentication key 125 may be a hardware-specific key generated and injected by the hardware-specific key generation circuit 112 of the processor unit 110 when the IoT module 100 is first booted. Unlike the storage area 123 for storing general data, the security area 124 may be an area accessible only when an authentication procedure through the authentication key 125 is passed. In one embodiment, the security area 124 may be a Replay Protected Memory Block (RPMB).

The hardware-specific key generation circuit 112 may generate an authentication key from a circuit structure included in the processor unit 110 . Since the hardware-specific key may vary based on the characteristics of the circuit structure included in the processor unit 110 , the risk of hacking may be greatly reduced. The hardware-specific key may be injected into the security area 124 when the IoT module 100 is booted for the first time, and then the processor unit 110 intends to obtain an access right to the data stored in the security area 124 . It can be used in the authentication process. The IoT module 100 may be produced by a module manufacturer and sold to a device manufacturer, and the device manufacturer may produce an IoT device equipped with the IoT module 100 and sell it to an end-user. Accordingly, the first booting operation in which the hardware-specific key is injected into the secure area 124 may be a procedure executed by the module manufacturer or the device manufacturer.

Each of the boot areas 121 and 122 may store a boot loader and a boot image. For example, the booting firmware may be stored in each of the booting areas 121 and 122 in the form of a booting image. Also, at least one of the boot regions 121 and 122 may store information for providing a secure boot function as first security information. In an embodiment, the first security information may be stored in the first booting area 121 that is loaded first when the IoT module 100 is booted. For example, the first security information may include a hash value of a security key provided by a device manufacturer that manufactures an IoT device equipped with the IoT module 100 .

Meanwhile, the secure area 124 may store information for providing a secure boot function as second security information. For example, the second security information may be stored in the security area 124 when the boot firmware is stored and released in the boot areas 121 and 122 by a hardware security module (HSM) or the like. The second security information may include a hash value of a security key provided by a device manufacturer that manufactures an IoT device equipped with the IoT module 100 .

As described above, by using the IoT module 100 produced and sold by one module manufacturer, a plurality of device manufacturers can produce and sell various IoT devices. The booting firmware stored in the booting areas 121 and 122 may be overwritten by other booting firmware. Therefore, if the secure boot function is not provided, the IoT module 100 will be booted by the booting firmware copied from the outside. can

In order to solve the above problem, in an embodiment of the present invention, when the first security information stored in at least one of the boot regions 121 and 122 matches the second security information stored in the security region 124 , Only the boot process can proceed. The second security information may be a hash value of a security key stored in the security area 124 by the device manufacturer using a hardware security module or the like in the process of distributing the booting firmware, and after the booting firmware is distributed, the security area 124 ) stored in the second security information cannot be changed. Accordingly, when the IoT module 100 is booted by changing the booting firmware stored in the booting areas 121 and 122 to another firmware, the booting process may be interrupted due to a mismatch between the first security information and the second security information. As a result, it is possible to lower the risk of hacking using boot firmware copied from the outside.

Also, in an embodiment of the present invention, the version of the boot firmware stored in the boot areas 121 and 122 may be compared with the firmware distribution version stored in the secure area 124 while the booting process is in progress. The firmware distribution version may be a version of boot firmware distributed by a device manufacturer using a hardware security module or the like. When the version of the boot firmware stored in the boot areas 121 and 122 is older than the version of the firmware distribution stored in the security area 124 , the processor unit 110 may stop the booting process. Accordingly, it is possible to prevent firmware rollback by the booting firmware stored in the booting areas 121 and 122 through an illegal path.

Next, referring to FIG. 5 , the IoT module 200 may include a processor unit 210 , a first memory unit 220 , a second memory unit 230 , and the like. As described above, the first memory unit 220 may be a nonvolatile memory such as eMMC or NAND flash memory.

The processor unit 210 may include a hardware unique key generation circuit 211 . The hardware-specific key 232 generated by the hardware-specific key generation circuit 211 may be generated by reflecting the microstructure of a circuit existing inside the processor unit 210 . Accordingly, even between the IoT modules 200 manufactured by the same module manufacturer, the unique hardware key 232 may be generated differently.

The hardware unique key 232 may be injected into the security area 224 of the first memory unit 220 through the security area 231 of the second memory unit 230 when the IoT module 200 is initially booted. there is. As described above, the security area 231 of the second memory unit 230 may be an area allocated by the memory controller included in the processor unit 210 . In one embodiment, since the IoT module 200 is generally sold to a device manufacturer in a state in which booting firmware is stored, the initial booting operation may be performed by the module manufacturer rather than the device manufacturer. After the hardware-specific key 232 is injected into the security area 224 of the first memory unit 220 , it may be used as the authentication key 229 for determining the access right to the security area 224 .

Meanwhile, before the module manufacturer sells the IoT module 200 to the device manufacturer, the information of the booting firmware mounted in the booting areas 221 and 222 and the information of the common key are stored in the security of the first memory area 220 . may be stored in area 224 . The common key may be uniformly injected into the IoT module 200 produced by the module manufacturer, and a hash value of the common key may be stored in the security area 224 of the first memory area 220 . Meanwhile, the boot firmware information stored in the security area 224 may include version information of the boot firmware provided by the module manufacturer. The security area 224 may be RPMB, and may be an area accessible only through an authentication procedure using the authentication key 229 injected by the processor unit 210 at the time of initial booting.

The common key injected into the IoT module 200 injected by the module manufacturer may be replaced with a security key unique to the device manufacturer that manufactures the IoT device equipped with the IoT module 200 . In an embodiment, the device manufacturer may inject a unique security key into the first memory unit 220 during the development/production process of the IoT device, and is stored in the booting areas 221 and 222 by the module manufacturer. It can process boot firmware and operating system. The boot firmware and the operating system may be stored as boot images in the boot regions 221 and 222 .

Meanwhile, the device manufacturer may proceed with a firmware distribution procedure using a hardware security module or the like before selling the IoT device. For example, in the firmware distribution procedure, information on a device manufacturer's unique security key may be stored in the boot areas 221 and 222 and the security area 224 as first security information and second security information, respectively. In addition, the version of the booting firmware stored in the boot areas 221 and 222 in the firmware distribution procedure may be stored in the security area 224 as the firmware distribution version.

Since the second security information and the firmware distribution version are stored in the security area 224 , they cannot be changed or deleted without an authentication procedure using the hardware unique key 232 stored as the authentication key 229 . Accordingly, the IoT module 200 mounted in the IoT device sold to the end consumer converts the second security information 228 stored in the security area 229 to the first security information stored in the booting areas 221 and 222 . By comparing with 226 , it may be determined whether the booting firmware 225 stored in the booting areas 221 and 222 is corrupted. If the first security information 226 does not match the second security information 228 , the processor unit 210 may abort the booting process in progress.

In addition, the IoT module 200 compares the firmware distribution version 227 stored in the security area 224 with the firmware version of the boot image 225 stored in the boot areas 221 and 222 to determine whether the boot firmware is rolled back. can determine whether Even when the first security information 226 and the second security information 228 match, if the firmware version of the boot image stored in the boot regions 221 and 222 is lower than the firmware distribution version stored in the security region 224 , , the boot process can be interrupted to prevent rollback of the boot firmware. As a result, the IoT module 200 according to an embodiment of the present invention can provide a secure boot function that prevents booting by unauthorized booting firmware, and can also prevent unintentional rollback of booting firmware. .

6 and 7 are flowcharts provided to explain the operation of the IoT module according to an embodiment of the present invention.

Referring first to FIG. 6 , the operation of the IoT module according to an embodiment of the present invention may start by checking whether the processor unit is booted for the first time after the IoT module is powered on ( S10 ). For example, the processor unit may check whether the first boot is performed according to whether a hardware-specific key is injected into a memory unit including a non-volatile memory device such as a NAND flash memory or an eMMC. If it is confirmed in step S10 that it is the first boot, the processor unit may generate a unique hardware key and inject it into the memory unit.

In the booting process that is performed after checking whether the booting is the first time, the processor unit may check whether the booting firmware is contaminated (S20). For example, the memory unit may have a plurality of booting areas, and at least one of the booting areas may store booting firmware in the form of a booting image. Also, according to an embodiment of the present invention, the boot regions may include first security information for determining whether the booting firmware is contaminated. The first security information may be a hash value of a security key injected into boot regions together with boot firmware.

The processor unit may check whether the booting firmware is contaminated by comparing the first security information read from the booting areas with the second security information stored in the security area of the memory unit. The security area of the memory unit may be an area accessible only through a separate authentication procedure. Therefore, the second security information stored in the security area, unlike the first security information stored in the boot areas, is a thing equipped with an IoT module After the Internet device is sold to an end consumer, it cannot be changed and/or deleted. For example, the second security information may be injected into the security area by a device manufacturer that manufactures an IoT device.

If it is determined that the booting firmware is not corrupted, the processor unit may check whether the booting firmware is rolled back (S30). The processor unit may determine whether to rollback the booting firmware by comparing the firmware distribution version stored in the secure area of the memory unit with the version of the booting firmware executed by the booting image.

The firmware distribution version stored in the secure area may correspond to the version of the boot firmware finally distributed by the device manufacturer before the IoT device is sold to the end consumer. Therefore, if the firmware distribution version is newer than the version of the boot firmware loaded from the boot area, the processor unit may stop the booting process to prevent rollback of the boot firmware.

Next, a booting process of the IoT module according to an embodiment of the present invention will be described in more detail with reference to FIG. 7 . Referring to FIG. 7 , the method of operating the IoT module according to an embodiment of the present invention may start with the processor unit acquiring a booting image and first security information stored in a booting area of the memory unit ( S11 ). The memory unit having the boot area may be implemented as a nonvolatile memory device, and the first security information may include a hash value of a predetermined security key, and the like.

The processor unit may obtain a booting image and first security information by directly accessing the booting area of the memory unit or accessing the booting area through a volatile memory device or the like. The booting firmware may be executed by the booting image. Meanwhile, the processor unit may generate a hardware-specific key by using a hardware-specific key generation circuit built into the processor unit (S12). The hardware-specific key is a key generated based on the microstructure of a circuit present in the processor unit, and may have different values even in IoT modules manufactured by one module manufacturer.

The processor unit may determine whether there is a hardware-specific key already injected into the memory unit ( S13 ). As a result of the determination in step S13, if there is no hardware-specific key already injected into the memory unit, the processor unit may determine that the IoT module is booted for the first time. On the other hand, if the hardware-specific key exists in the memory unit as a result of the determination in step S13, it may be determined that the IoT module has been booted before.

If it is determined in step S13 that the IoT module is booted for the first time, the processor unit may inject a hardware-specific key into the security area of the memory unit as an authentication key (S14). In addition, the version of the booting firmware executed by the boot image obtained in step S11 is stored in the secure area as the firmware distribution version, while the first security information obtained in step S11 may be stored in the secure area as second security information. (S15). Thereafter, the processor unit may load the next booting image from the booting areas and execute the booting firmware and/or the operating system, thereby proceeding the booting process ( S40 ).

In general, the first booting of the IoT module may be performed by a module manufacturer that produces and sells the IoT module. Accordingly, the firmware distribution version stored in the security area of the memory unit in step S15 may be the version of the boot firmware processed by the module manufacturer and stored in the boot area. In addition, the second security information stored in the security area of the memory unit in step S15 may be a hash value of a common key commonly injected into IoT modules produced and sold by the module manufacturer.

The firmware distribution version stored in the security area of the memory unit in step S15 may then be updated to a new version by a device manufacturer that purchases an IoT module and produces an IoT device. Device manufacturers can process the boot firmware and operating system stored in the boot area in the process of producing IoT devices. A device manufacturer may proceed with a firmware distribution procedure using a hardware security module or the like before selling an IoT device to an end consumer.

In the firmware distribution procedure, the device manufacturer may store the finally processed boot firmware in boot areas of the memory unit. Also, a hash value of a device manufacturer's unique security key may be stored in boot areas as first security information. At the same time, the version of the boot firmware stored in the boot areas may be stored in the security area of the memory unit as the firmware distribution version, and the hash value of the device manufacturer's unique security key is stored as the second security information in the security area of the memory unit can be

The security area of the memory unit in which the firmware distribution version and the second security information are stored may be an area that cannot be accessed without passing through a predetermined instruction set, for example, RPMB. Accordingly, the firmware distribution version and the second security information stored in the security area before the device manufacturer sells the IoT device to the end consumer may not be changed and/or deleted in the subsequent distribution process.

If it is determined in step S13 that the IoT module is not initially booted, the processor unit may read the firmware distribution version and the second security information stored in the security area of the memory unit (S21). The processor unit may compare the second security information read in step S21 with the first security information read in step S11 (S22). If the first security information and the second security information match each other in step S22, the processor unit may determine that the boot image acquired in the boot area is not contaminated. On the other hand, if it is determined in step S22 that the first security information and the second security information do not match each other, the processor unit may determine that the booting image stored in the booting area is corrupted and stop the booting process ( S50 ).

If it is determined in step S22 that the first security information and the second security information match each other, the processor unit determines whether the version of the boot firmware executed by the boot image obtained in step S11 is greater than or equal to the firmware distribution version read in step S21 can be determined (S31). If it is determined in step S31 that the version of the boot firmware executed by the boot image obtained in step S11 is smaller than the firmware distribution version read in step S21, the processor unit may determine that there is a risk of booting firmware rollback. Accordingly, the processor unit may stop the booting process ( S50 ).

On the other hand, if it is determined in step S31 that the version of the booting firmware executed by the booting image is greater than or equal to the firmware distribution version, the processor unit may determine that there is no risk of booting firmware rollback. Therefore, if the firmware distribution version is smaller than the version of the boot firmware executed by the boot image, the firmware distribution version stored in the secure area may be updated to the version of the boot firmware executed by the boot image ( S32 ). Thereafter, the processor unit may load boot images sequentially from the boot areas and execute the next booting firmware and/or an operating system (OS), etc. (S33), thereby proceeding the booting process (S40).

As described with reference to FIG. 7 , in the present invention, the first security information read from the boot regions of the memory unit is compared with the second security information stored in the security region of the memory unit to determine whether the boot image stored in the boot region is contaminated. can determine whether Also, even if the first security information and the second security information match, the booting process can be continued only when the version of the boot firmware executed by the boot image is equal to or greater than the firmware distribution version stored in the security area. . Therefore, it is possible to prevent rollback of the boot firmware unintentionally by the user.

8 and 9 are diagrams for explaining the operation of the IoT module according to an embodiment of the present invention.

Referring first to FIG. 8 , in the IoT module 300 according to an embodiment of the present invention, the security area 310 of the memory unit may store the second security information 311 and the firmware distribution version 312 . The second security information 311 may be a hash value of a common key, and the common key may be a key stored in the security area 310 of the memory by a module manufacturer that produces and/or sells the IoT module 300 . The firmware distribution version 312 may be a version of the boot firmware stored in the boot area of the memory unit by the module manufacturer.

The embodiment shown in FIG. 8 may show a process of distributing firmware together with IoT device production after a device manufacturer purchases an IoT module and undergoes development work. Referring to FIG. 8 , the device manufacturer mounts a new version of booting firmware on the IoT module 300 , while using the hardware security module 400 to use the second security information 311 stored in the security area 310 . ) may be changed to the unique second security information 311 of the IoT device on which the IoT module 300 is mounted. Accordingly, as shown in FIG. 8 , the second security information 311 stored in the security area 310 of the memory may be changed and the firmware distribution version 312 may be increased.

Next, referring to FIG. 9 , even after the IoT device equipped with the IoT module 300 is sold to an end consumer, the booting firmware may be updated according to various needs. Referring to FIG. 9 , when booting firmware is updated, the firmware distribution version 312 stored in the secure area 310 may increase. Before overwriting the firmware distribution version 312 according to the firmware update, a procedure of comparing the hash value of the security key stored in the boot area with the second security information 311 stored in the security area 310 and the boot firmware stored in the boot area A procedure of comparing the version of ? with the firmware distribution version 312 stored in the secure area 310 may be executed in the firmware update process. For example, in the embodiment shown in FIG. 9 , when the version of the updated boot firmware is lower than 0.9 or the hash value of the security key stored in the boot area together with the boot firmware is different from the second security information 311 , Firmware update may not be executed.

The present invention is not limited by the above-described embodiments and the accompanying drawings, but is intended to be limited by the appended claims. Therefore, various types of substitution, modification and change will be possible by those skilled in the art within the scope not departing from the technical spirit of the present invention described in the claims, and it is also said that it falls within the scope of the present invention. something to do.

100, 200, 300: IoT module
110, 210: processor
120, 220: first memory unit
130, 230: second memory unit

Claims (20)

a memory unit having a boot area storing boot firmware and first security information, and a security area storing a firmware release version and second security information; and
A processor unit that performs a booting process using the booting firmware, compares the firmware distribution version with a version of the booting firmware, and compares the first security information with the second security information to determine whether to proceed with the booting process ; including,
The processor unit includes a hardware unique key generation circuit that generates a hardware unique key determined from a structure of a circuit included in the processor unit at the first execution of the booting firmware,
The processor unit stores the hardware-specific key in the security area, and the IoT module uses the hardware-specific key as a security key for determining an access right to the security area.
The method of claim 1,
When it is determined that the booting firmware is first executed, the processor unit changes the firmware distribution version of the security area to the version of the booting firmware of the booting area.
3. The method of claim 2,
The processor unit is an IoT module that determines that the booting firmware is initially executed when the booting firmware is executed and the hardware unique key is not stored in the secure area.
3. The method of claim 2,
The processor unit is an IoT module using the hardware-specific key as an authentication means for data transmission/reception with the security area.
According to claim 1,
The processor unit is configured to stop the booting process when the first security information and the second security information are different from each other.
According to claim 1,
The processor unit is configured to stop the booting process when the version of the booting firmware is older than the firmware distribution version.
According to claim 1,
The processor unit is configured to update the firmware distribution version to the boot firmware version when the version of the booting firmware is newer than the firmware distribution version.
According to claim 1,
The second security information is an IoT module including a public key injected by a device manufacturer that manufactures an IoT device on which the IoT module is mounted.
According to claim 1,
The first security information includes a hash value of a security key stored in the booting area together with the booting firmware,
The second security information is an IoT module including a hash value of a public key.
According to claim 1,
a dynamic memory unit including secure boot logic to obtain the firmware distribution version and the second authentication information from the secure area and compare them with the version of the booting firmware and the first authentication information, respectively, in a secure mode; IoT module further comprising a.
11. The method of claim 10,
wherein the processor unit includes a dynamic memory controller for controlling the dynamic memory unit in the security mode.
12. The method of claim 11,
The dynamic memory controller is an IoT module including a TrustZone Protection Controller (TZPC).
11. The method of claim 10,
The processor unit is configured to store, in the secure area through the secure boot logic, a hardware unique key generated based on a structure of a circuit included in the processor unit when the booting firmware is first executed.

delete delete delete delete delete delete delete

Images