KR20230170308A - Embedded Apparatus, Method for Booting therein and Method for Encrypted Firmware - Google Patents

Abstract

Disclosed are an embedded apparatus, a booting method thereof, and a method for generating encrypted firmware. The embedded apparatus, according to an embodiment of the present invention, includes at least three memories of different types and a core processor. A first-type memory, a second-type memory, and a core processor comprise a falsification prevention micro-control unit. A third-type memory has firmware including an encrypted firmware integrity verification code, a boot loader, a kernel binary, and an application binary. The first-type memory can store route information for decoding a hardware integrity verification code and the firmware integrity verification code. The purpose of the present invention is to overcome the limit of a firmware security function in the embedded apparatus.

Description

Embedded device, method for booting therein and method for creating encrypted firmware {Embedded Apparatus, Method for Booting therein and Method for Encrypted Firmware}

The described embodiments relate to hardware security and firmware reverse engineering techniques.

Backdoor security problems hidden in embedded devices are becoming increasingly serious. A representative example is the discovery of backdoors in Chinese irons and electric kettles found in Russia that connect to wireless networks and spread malware and spam.

Backdoors can be inserted during the product production process or by modifying the firmware of the finished product. Therefore, if the firmware has been illegally modified, the embedded device should not operate.

Existing embedded devices often do not have firmware security functions the smaller they are, or the firmware security functions applied to some commercial products have limitations.

The described embodiments are aimed at overcoming the limitations of firmware security functions in embedded devices.

The purpose of the described embodiment is to prevent backdoor injection attacks through firmware modification in embedded devices.

An embedded device according to an embodiment includes at least three different types of memories and a core processor, wherein the first type memory, the second type memory, and the core processor are comprised of a tamper-resistant microcontrol unit, and the third type memory is comprised of a tamper-resistant microcontrol unit. , firmware including an encrypted firmware integrity verification code, a bootloader and kernel binary, and an app binary are mounted, and the first type memory may store root information for decrypting the hardware integrity verification code and the firmware integrity verification code. .

At this time, the information stored in the first type memory can be replaced by the production device and a predetermined authentication method.

At this time, as power is applied, the hardware integrity verification code executed by the core processor decrypts the firmware integrity verification code into the second type memory using the root information, and the decrypted firmware integrity verification code transfers the bootloader to the third type memory. Decrypts into memory or type 4 memory, the decrypted bootloader decrypts the kernel binary into type 3 memory or type 4 memory, and the decrypted kernel binary verifies the integrity of the app binary and stores it in type 3 memory or type 4 memory. Can be loaded into type memory.

At this time, the first type memory stores the size of the factory encryption key and firmware integrity verification code as root information, and the hardware integrity verification code decrypts the firmware integrity verification code using the size of the factory encryption key and firmware integrity verification code. can do.

At this time, the first random key and the encryption size information of the boot loader are encrypted and stored together with the firmware integrity verification code, and the decrypted firmware integrity verification code is converted into a factory encryption key by combining the first random key and the factory encryption key. An encrypted boot loader key can be generated, and the encrypted boot loader area can be decrypted using the generated boot loader key and the boot loader encryption size.

At this time, in the firmware, the second random key and the encryption size information of the kernel binary are encrypted and stored together with the bootloader, and the decrypted bootloader is a kernel encrypted with the bootloader key by combining the second random key and the factory encryption key. You can generate a binary key and decrypt the encrypted kernel binary area using the generated kernel binary key and the encryption size of the kernel binary.

At this time, in the firmware, app size information and app hash information are encrypted and stored together with the kernel binary, and the decrypted kernel binary hashes the app binary using the app size information and combines the app hash information of the hashed app binary with the app hash information. Depending on the match, the integrity of the app binary can be verified.

In a firmware booting method in an embedded device according to an embodiment, the embedded device includes at least three different types of memories and a core processor, wherein the first type memory, the second type memory, and the core processor include a tamper-resistant microcontroller. It is composed of a unit, and the third type memory is equipped with firmware including an encrypted firmware integrity verification code, a bootloader and kernel binary, and an app binary, and the first type memory is equipped with a hardware integrity verification code and a firmware integrity verification code. Storing root information for decrypting, but as power is applied, the hardware integrity verification code executed by the core processor decrypts the firmware integrity verification code in the second type memory using the root information, the decrypted firmware integrity The verification code includes steps of decrypting the bootloader in the third type memory or fourth type memory, decrypting the kernel binary in the third type memory or fourth type memory in the decrypted bootloader, and decrypting the decrypted kernel binary in the app binary. It may include verifying integrity and loading it into a third type memory or a fourth type memory.

At this time, the information stored in the first type memory can be replaced by the production device and a predetermined authentication method.

At this time, the first type memory stores the size of the factory encryption key and firmware integrity verification code as root information, and the hardware integrity verification code decrypts the firmware integrity verification code using the size of the factory encryption key and firmware integrity verification code. can do.

At this time, in the firmware, the first random key and the encryption size information of the boot loader are encrypted and stored together with the firmware integrity verification code, and in the step of decrypting the bootloader, the decrypted firmware integrity verification code is the first random key and the factory By combining the encryption keys, a bootloader key encrypted with the factory encryption key can be generated, and the encrypted bootloader area can be decrypted using the generated bootloader key and the bootloader encryption size.

At this time, in the firmware, the second random key and the encryption size information of the kernel binary are encrypted and stored together with the bootloader, and in the step of decrypting the kernel binary, the decrypted bootloader uses the second random key and the factory encryption key. By combining them, a kernel binary key encrypted with the bootloader key can be generated, and the encrypted kernel binary area can be decrypted using the generated kernel binary key and the encryption size of the kernel binary.

At this time, in the firmware, app size information and app hash information are encrypted and stored together with the kernel binary, and at the loading stage, the decrypted kernel binary hashes the app binary using the app size information, and the hashed app binary is Depending on whether it matches the app hash information, the integrity of the app binary can be verified.

The method of generating encrypted firmware according to an embodiment includes the steps of generating keys to be used for firmware encryption, encrypting the firmware integrity verification code area, bootloader area, and kernel binary area based on the generated keys, and encrypting the encryption result and app binary. It may include the step of creating firmware that includes the firmware.

At this time, the firmware is mounted on the embedded device, and the embedded device includes at least three different types of memories and a core processor, and the first type memory, the second type memory, and the core processor are composed of a tamper-resistant microcontrol unit. The third type memory is equipped with firmware, and the first type memory can store root information for decoding the hardware integrity verification code and the firmware integrity verification code.

At this time, the step of generating keys includes generating a factory key of the embedded device and two random keys, combining the first random key and the factory key to generate a bootloader key encrypted with the factory key, and It may include generating a key for the kernel binary encrypted with the bootload key by combining the second random key and the bootloader key.

At this time, the encryption step includes a kernel binary including an integrity function of the app binary area, a step of encrypting the app binary size and the app binary hash with a key for the kernel binary, a boot loader including a kernel binary area decryption function, and a second random key. and encrypting the size of the encrypted kernel binary area with a bootload key, a firmware integrity verification code including a bootloader area decryption function, a first random key, and encrypting the encrypted bootloader area size with a factory key. You can.

According to the described embodiments, the goal is to overcome the limitations of firmware security functions in embedded devices.

The purpose of the described embodiment is to prevent backdoor injection attacks through firmware modification in embedded devices.

Figure 1 is an example diagram of firmware security functions applied to some commercial products.
Figure 2 is an example of a security failure due to backdoor insertion.
Figure 3 is a schematic block diagram of an embedded device according to an embodiment.
Figure 4 is a flowchart for explaining a firmware generation method according to an embodiment.
Figure 5 is an example diagram of an embedded device loaded with encrypted firmware created according to an embodiment.
Figure 6 is a flowchart for explaining a firmware booting method in an embedded device according to an embodiment.
Figure 7 is a diagram showing the configuration of a computer system according to an embodiment.

The advantages and features of the present invention and methods for achieving them will become clear by referring to the embodiments described in detail below along with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and will be implemented in various different forms. The present embodiments only serve to ensure that the disclosure of the present invention is complete and that common knowledge in the technical field to which the present invention pertains is not limited. It is provided to fully inform those who have the scope of the invention, and the present invention is only defined by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

Although terms such as “first” or “second” are used to describe various components, these components are not limited by the above terms. The above terms may be used only to distinguish one component from another component. Accordingly, the first component mentioned below may also be the second component within the technical spirit of the present invention.

The terms used in this specification are for describing embodiments and are not intended to limit the invention. As used herein, singular forms also include plural forms, unless specifically stated otherwise in the context. As used in the specification, “comprises” or “comprising” implies that the mentioned component or step does not exclude the presence or addition of one or more other components or steps.

Unless otherwise defined, all terms used in this specification can be interpreted as meanings commonly understood by those skilled in the art to which the present invention pertains. Additionally, terms defined in commonly used dictionaries are not interpreted ideally or excessively unless clearly specifically defined.

Below, an embedded device according to an embodiment, a booting method in the device, and an encryption firmware generation method are described in detail with reference to FIGS. 1 to 7.

Figure 1 is an example of a firmware security function applied to some commercial products, and Figure 2 is an example of a security failure due to backdoor insertion.

Referring to FIG. 1, the kernel binary (20) and the application binary (30) are packed in the firmware (1).

At this time, packing means encrypting or compressing the original data.

When power is applied to an embedded device equipped with such firmware (1), it is executed starting from the bootloader (10). The bootloader 10 verifies the integrity of the kernel binary 20 through an integrity verification code.

At this time, if verification succeeds, the packed kernel binary 20 can be unpacked. For reference, depending on the implementation method, unpacking may be performed first and then integrity verification may be performed.

On the other hand, if the integrity verification fails, the bootloader 10 determines that the firmware has been manipulated and stops the booting process.

However, the firmware security function described above has the following problems.

As shown in Figure 2, an attacker can unpack firmware extracted from the device or firmware provided by the device manufacturer and insert a backdoor into the unpacked firmware kernel binary 20 or app binary 30.

At this time, the inserted backdoor is manipulated to bypass the integrity verification code portion of the bootloader 10 and the kernel binary 20. Then, the firmware with the backdoor inserted is repackaged and inserted into the device.

In this state, when the embedded device is started, the integrity verification code is bypassed (jumped) and boots normally, and the backdoor can be executed.

Therefore, in the embodiment, as described above, in order to prevent backdoor injection attacks through firmware modification in embedded devices, a firmware configuration using a tamper-proof micro control unit (MCU) is proposed. .

Figure 3 is a schematic block diagram of an embedded device according to an embodiment.

Referring to FIG. 3, the embedded device 100 according to an embodiment may include a core processor 111 and at least three different types of memories 121, 122, 123, and 124.

At this time, for example, the core processor 111 may be ARM, etc., an example of the first type memory (T1_Memory) 121 may be a ROM (Read-Only Memory) series, and the second type memory (T2_Memory) 122 ) may be a NOR flash series, the third type memory (T3_Memory) 123 may be a NAND flash series, and the fourth type memory (T4_Memory) 124 may be a RAM (Random Access Memory) series. However, this is only an example, and the present invention is not limited thereto.

Depending on the embodiment, the first type memory 121, the second type memory 122, and the core processor 111 may be configured as a tamper-proof microcontrol unit (tamper-proof MCU) 110. As a result, the tamper-resistant microcontrol unit 110 can prevent tampering through physical disassembly and reassembly of lasers, etc.

The third type memory 123 is loaded with encrypted firmware 130 created according to the embodiment. At this time, the firmware 130 includes an encrypted firmware integrity verification code (IFC) area 131, an encrypted boot loader (BL) area 132, and an encrypted kernel binary (Kernal). It may include a Binary, KERN_BIN) area (133) and an Application Binary (APP_BIN) (134).

The first type memory 121 may store an in-hardware integrity verification code (IHC) and root information for decoding the firmware integrity verification code (IFC) area 131.

That is, the root information may include the factory encryption key (K_F) required to decrypt the firmware integrity verification code (IFC) and the encrypted size (E_IFC_Size) of the firmware integrity verification code (IFC).

At this time, the information stored in the first type memory 121 can be replaced by the production device and a predetermined authentication method. Therefore, the root information for decrypting the hardware integrity verification code (IHC) and the firmware integrity verification code (IFC) area 131 can be leaked to the outside or replaced by an unauthorized device. does not exist.

Depending on the embodiment, decryption and integrity verification may be performed in the following order: hardware integrity verification code (IHC), firmware integrity verification code (IFC), bootloader (BL), kernel binary (KERN_BIN), and app binary (APP_BIN).

That is, as power is applied, the hardware integrity verification code (IHC) executed by the core processor 111 uses the root information to inject the firmware integrity verification code (IFC) area 131 into the second type memory 122. Decrypt. Then, the decrypted firmware integrity verification code (IFC) decrypts the bootloader (BL) area 132 into the third type memory 123 or the fourth type memory 124. Next, the decrypted bootloader (BL) decrypts the kernel binary (KERN_BIN) area 133 into the third type memory 123 or the fourth type memory 124, and the decrypted kernel binary (KERN_BIN) is stored in the app binary. The integrity of the (APP_BIN) area 134 can be verified and loaded into the third type memory 123 or the fourth type memory 124.

At this time, if the third type memory 123 has available space and is an executable memory, decoding of the bootloader (BL) area 132 and the kernel binary (KERN_BIN) area 133, and the app binary (APP_BIN) area ( Loading 134) may be performed in free space under the app binary (APP_BIN) area 134 of the third type memory 123 without using the fourth type memory 124.

As described above, the embodiment has the advantage that the existing firmware can be used as is and only the firmware part can be replaced through the IHC-IFC structure.

Firmware mounted on the above-described embedded device may be encrypted and created by the manufacturer.

Figure 4 is a flowchart for explaining a firmware generation method according to an embodiment.

Referring to FIG. 4, the firmware generation method according to the embodiment largely includes generating keys to be used for firmware encryption (S210 to S230), and based on the generated keys, the firmware integrity verification code area, bootloader area, and kernel binary area. It may include a step of encrypting (S240 to S250) and a step of generating firmware including the encryption result and app binary (S270).

Specifically, in the steps of generating keys (S210 to S230), the manufacturer generates a factory crypto key (K_F) and two random keys (K_R1, K_R2) for each serial number of the embedded device. Do it (S210).

Then, the manufacturer combines the first random key (K_R1) and the factory key (K_F) to generate a bootloader crypto key (K_B) encrypted with the factory key (K_F) ( S220).

Then, the manufacturer combines the second random key (K_R2) and the boot loader key (K_B) to create a kernel binary crypto key (K_K) encrypted with the boot loader key (K_B). Create (S230).

Next, in the encryption step (S240~S250), the production device (Manufacturer) generates the app binary (APP_BIN), the kernel binary (KERN_BIN) including the area integrity verification function, the size of the app binary (APP_Size), and the app binary hash (APP_Hash). ) is encrypted with the key (K_K) for the kernel binary (S240).

Then, the manufacturing device (Manufacturer) combines the bootloader (BL) with the kernel binary (KERN_BIN) area decryption function, the second random key (K_R2), and the encrypted kernel binary size (E_KERN_Size) into the key for the bootloader (K_B). Encrypt with (S250)

Then, the manufacturer sends the firmware integrity verification code (IFC) containing the bootloader (BL) area decryption function, the first random key (K_R1), and the encrypted bootloader area size (E_BL_Size) to the factory key ( Encrypt with K_F) (260).

Finally, the manufacturer creates firmware by combining the encrypted result and app binary (S270).

Figure 5 is an example diagram of an embedded device loaded with encrypted firmware created according to an embodiment.

Referring to FIG. 5, the manufacturer mounts the firmware generated by the method described with reference to FIG. 4 into the third type memory 123 of the embedded device, and implements a hardware integrity verification code (IHC) and a firmware integrity verification code ( Information (K_F, E_IFC_Size) required for decoding IFC is stored in the first type memory 121.

As described above, the information stored in the first type memory 121 is not leaked to the outside and can only be replaced using a special authentication method between the production device and the embedded device.

Figure 6 is a flowchart for explaining a firmware booting method in an embedded device according to an embodiment.

Referring to FIGS. 5 and 6 , as power is applied to the embedded device, the core processor 111 executes the hardware integrity verification code (IHC) stored in the first type memory 121 (S310).

The executed hardware integrity verification code (IHC) decrypts the firmware integrity verification code area 131 in the second type memory 122 using the root information (S320).

At this time, referring to FIG. 5, the hardware integrity verification code (IHC) can decrypt the firmware integrity verification code (IFC) area using the factory encryption key (K_F) and the size (E_IFC_Size) of the firmware integrity verification code.

The decrypted firmware integrity verification code decrypts the bootloader area 132 in the third type memory 123 or the fourth type memory 124 (S330).

At this time, referring to FIG. 5, the first random key (K_R1) and the encryption size information (E_BL_Size) of the boot loader may be encrypted and stored together with the firmware integrity verification code (IFC) in the firmware 130.

Therefore, in the step of decrypting the bootloader (S330), the decrypted firmware integrity verification code (IFC) is encrypted with the factory encryption key (K_F) by combining the first random key (K_R1) and the factory encryption key (K_F). A boot loader key (K_B) can be generated, and the encrypted boot loader area 132 can be decrypted using the generated boot loader key (K_B) and the boot loader encryption size (E_BL_Size).

The decrypted bootloader decrypts the kernel binary area 133 in the third type memory 123 or the fourth type memory 124 (S340).

At this time, referring to FIG. 5, the second random key (K_R2) and the encryption size information (E_KERN_Size) of the kernel binary may be encrypted and stored together with the bootloader.

Therefore, in the step of decrypting the kernel binary (S340), the decrypted bootloader combines the second random key (K_R2) and the factory encryption key (K_F) and encrypts the kernel binary key (K_K) with the bootloader key (K_B). ) can be generated, and the encrypted kernel binary area 133 can be decrypted using the generated kernel binary key (K_K) and the encryption size (E_KERN_Size) of the kernel binary.

The decrypted kernel binary verifies the integrity of the app binary 134 and is loaded into the third type memory 123 or fourth type memory 124 (S350).

At this time, referring to FIG. 5, app size information (APP_Size) and app hash information (APP_Hash) may be encrypted and stored together with the kernel binary in the firmware 130.

Therefore, in the loading step (S350), the decrypted kernel binary hashes the app binary using app size information (APP_Size), and determines the integrity of the app binary depending on whether the hashed app binary matches the app hash information. can be verified. The verified app binary may be loaded into the third type memory 123 or the fourth type memory 124.

Figure 7 is a diagram showing the configuration of a computer system according to an embodiment.

Embedded devices and firmware generation devices according to embodiments may be implemented in a computer system 1000 such as a computer-readable recording medium.

Computer system 1000 may include one or more processors 1010, memory 1030, user interface input device 1040, user interface output device 1050, and storage 1060 that communicate with each other via bus 1020. You can. Additionally, the computer system 1000 may further include a network interface 1070 connected to the network 1080. The processor 1010 may be a central processing unit or a semiconductor device that executes programs or processing instructions stored in the memory 1030 or storage 1060. The memory 1030 and storage 1060 may be storage media including at least one of volatile media, non-volatile media, removable media, non-removable media, communication media, and information transfer media. For example, memory 1030 may include ROM 1031 or RAM 1032.

Although embodiments of the present invention have been described above with reference to the attached drawings, those skilled in the art will understand that the present invention can be implemented in other specific forms without changing the technical idea or essential features. You will understand that it exists. Therefore, the embodiments described above should be understood in all respects as illustrative and not restrictive.

100: Embedded device
110: Tamper-resistant microcontrol unit
121~124: 1st type memory ~ 4th type memory
130: firmware
131: Firmware integrity verification code area 132: Bootloader area
133: Kernel binary area 134: App binary area

Claims (17)

Comprising at least three different types of memories and a core processor,
The first type memory, the second type memory and the core processor are composed of a tamper-resistant microcontrol unit,
The third type of memory is,
It is equipped with firmware that includes encrypted firmware integrity verification code, bootloader and kernel binaries, and app binaries.
The first type memory is,
An embedded device that stores root information for decrypting hardware integrity verification code and firmware integrity verification code. The method of claim 1, wherein the first type memory is:
An embedded device in which stored information is replaced by a production device and a predetermined authentication method. According to claim 1,
As power is applied, the hardware integrity verification code executed by the core processor decrypts the firmware integrity verification code into the second type memory using the root information,
The decrypted firmware integrity verification code decrypts the bootloader into third type memory or fourth type memory,
The decrypted bootloader decrypts the kernel binary into third type memory or fourth type memory,
An embedded device that verifies the integrity of the app binary and loads the decrypted kernel binary into type 3 memory or type 4 memory. The method of claim 3, wherein the first type memory is:
Stores the size of the factory encryption key and firmware integrity verification code as root information,
The hardware integrity verification code is:
An embedded device that decrypts the firmware integrity verification code using the factory encryption key and the size of the firmware integrity verification code. The method of claim 3, wherein the firmware includes:
The first random key and the encryption size information of the boot loader are encrypted and stored together with the firmware integrity verification code,
The decrypted firmware integrity verification code is,
An embedded device that combines the first random key and the factory encryption key to generate a bootloader key encrypted with the factory encryption key, and decrypts the encrypted bootloader area using the generated bootloader key and the bootloader encryption size. . The method of claim 3, wherein the firmware includes:
The second random key and the encryption size information of the kernel binary are encrypted and stored together with the bootloader,
The decrypted bootloader is,
An embedded device that generates a kernel binary key encrypted with a bootloader key by combining a second random key and a factory encryption key, and decrypts the encrypted kernel binary area using the generated kernel binary key and the encryption size of the kernel binary. The method of claim 3, wherein the firmware includes:
App size information and app hash information are encrypted and stored together with the kernel binary,
The decrypted kernel binary is:
An embedded device that hashes the app binary using app size information and verifies the integrity of the app binary based on whether the hashed app binary matches the app hash information. In the firmware booting method in an embedded device,
Embedded devices,
Comprising at least three different types of memories and a core processor,
The first type memory, the second type memory and the core processor are composed of a tamper-resistant microcontrol unit,
The third type of memory is,
It is equipped with firmware that includes encrypted firmware integrity verification code, bootloader and kernel binaries, and app binaries.
The first type memory is,
Stores root information to decrypt the hardware integrity verification code and firmware integrity verification code,
As power is applied, the hardware integrity verification code executed by the core processor decrypts the firmware integrity verification code in the second type memory using the root information;
The decrypted firmware integrity verification code includes decoding a bootloader in a third type memory or a fourth type memory;
Decrypting the kernel binary in the decrypted bootloader into a third type memory or a fourth type memory; and
A method of booting firmware in an embedded device, comprising the step of verifying the integrity of the app binary and loading the decrypted kernel binary into a third type memory or a fourth type memory. The method of claim 8, wherein the first type memory is:
A firmware booting method in an embedded device in which information stored by the production device and a predetermined authentication method is replaced. The method of claim 8, wherein the first type memory is:
Stores the size of the factory encryption key and firmware integrity verification code as root information,
The hardware integrity verification code is a firmware boot method in an embedded device that decrypts the firmware integrity verification code using the factory encryption key and the size of the firmware integrity verification code. The method of claim 8, wherein the firmware includes:
The first random key and the encryption size information of the boot loader are encrypted and stored together with the firmware integrity verification code,
In the step of decrypting the bootloader,
The decrypted firmware integrity verification code generates a bootloader key encrypted with the factory encryption key by combining the first random key and the factory encryption key, and encrypts the bootloader using the key of the generated bootloader and the encryption size of the bootloader. A firmware boot method in an embedded device that decrypts the area of . The method of claim 8, wherein the firmware includes:
The second random key and the encryption size information of the kernel binary are encrypted and stored together with the bootloader,
In the step of decrypting the kernel binary,
The decrypted bootloader generates a kernel binary key encrypted with the bootloader key by combining the second random key and the factory encryption key, and decrypts the encrypted kernel binary area using the generated kernel binary key and the encryption size of the kernel binary. How to boot firmware in embedded devices. The method of claim 8, wherein the firmware includes:
App size information and app hash information are encrypted and stored together with the kernel binary,
At the loading stage,
A firmware booting method in an embedded device in which the decrypted kernel binary hashes the app binary using app size information, and verifies the integrity of the app binary based on whether the hashed app binary matches the app hash information. generating keys to be used for firmware encryption;
Encrypting the firmware integrity verification code area, bootloader area, and kernel binary area based on the generated keys; and
A method of generating cryptographic firmware, comprising generating firmware containing cryptographic results and app binaries. The method of claim 14, wherein the firmware is:
It is mounted on an embedded device,
Embedded devices,
Comprising at least three different types of memories and a core processor,
The first type memory, the second type memory and the core processor are composed of a tamper-resistant microcontrol unit,
The third type of memory is,
Firmware is installed,
The first type memory is,
A method of creating encrypted firmware that stores root information for decrypting the hardware integrity verification code and firmware integrity verification code. 15. The method of claim 14, wherein generating keys comprises:
generating a factory key of the embedded device and two random keys;
Combining the first random key and the factory key to generate a key for the bootloader encrypted with the factory key;
A method of generating encrypted firmware, comprising generating a key for a kernel binary encrypted with a bootload key by combining a second random key and a bootloader key. The method of claim 14, wherein the encrypting step includes:
Encrypting the kernel binary containing the integrity function of the app binary area, the app binary size, and the app binary hash with a key for the kernel binary;
Encrypting a boot loader including a kernel binary area decryption function, a second random key, and the size of the encrypted kernel binary area with a boot load key; and
A method of generating encrypted firmware, comprising encrypting a firmware integrity verification code with a bootloader area decryption function, a first random key, and an encrypted bootloader area size with a factory key.

Images