KR20220059866A - Secure Boot Verification Method and Secure Element for the Same - Google Patents

Abstract

Provided is a secure boot verification method for performing a secure boot by using a secure element mounted to an IoT device and verifying whether the secure boot normally progresses. The method comprises: a first loading step of loading a boot manager from an ROM; a first log recording step of recording a first log record related to the first loading step in a log record; a second loading step of loading an OS loader from the boot manager; a third loading step of loading an OS from the OS loader; and a log verification step of determining whether the secure boot normally progresses by checking the log record. Accordingly, the present invention can guarantee whether the secure boot is properly performed without separate installation of anti-malware.

Description

Secure Boot Verification Method and Secure Element for the Same

The present invention relates to a method for verifying a secure boot and a security element therefor, and more particularly, to a security for determining whether secure boot is normally performed by recording a log record during secure boot and checking the log record by a server It relates to a boot verification method and a security element therefor.

The Internet of Things (IoT) refers to a technology for connecting to the Internet by embedding sensors and communication functions in various objects, that is, a technology for connecting various Internet of Things (IoT) devices using the Internet.

Here, the Internet of Things (IoT) device may be various embedded systems such as home appliances, mobile equipment, and wearable devices. At this time, IoT devices connected to the Internet of Things need to be connected to the Internet with an IP that can identify themselves, and all these IoT devices can become targets of viruses and hacking, increasing security requirements and there is a situation.

Accordingly, the number of cases of adopting and applying a hardware-type Secure Element (SE) that protects against device data transmission and hacking at a high security level is increasing.

In this way, when a secure element is adopted, a secure boot is performed.

Meanwhile, in Secure Boot, after loading a boot manager from the boot ROM, loading an OS loader from the boot manager, and then loading an OS from the OS loader There are three main steps to loading.

When performing such a secure boot, it is almost impossible to hack the boot ROM except for physical hacking. However, when loading a boot manager, an OS loader, an OS, etc., it is possible for the hacker to skip the verification step and load the hacker's own OS.

As such, in order to prevent a hacker from bypassing the verification step, there is a method of installing and embedding Early Launch Anti-Malware (ELAM) from the boot manager. However, this also has no effect when bypassing the boot manager (Boot Manager), and since the resources and environment necessary for ELAM installation are available after the OS is all loaded, the boot manager ( There is a problem that it is difficult to install in Boot Manager) or OS Loader.

Design and implementation of a security system for safe booting and updating of low-spec IoT devices (Journal of the Information Science Society, No. 45, No. 4, 2018.4)

The present invention is to solve the above-mentioned problem, by recording a log record in the secure boot process and verifying it by the server afterward, secure boot verification that can prevent damage due to hacking The purpose is to provide a method.

The secure boot verification method according to the present invention is a secure boot verification method for performing a secure boot using a secure element mounted on an IoT device and verifying whether the secure boot has been normally performed, from a ROM to a boot manager. A first loading step of loading; a first log recording step of recording a first log record related to the first loading step in a log record; a second loading step of loading an OS loader from the boot manager; a third loading step of loading the OS from the OS loader; and a log verification step of determining whether secure boot is normally performed by checking the log record.

The secure boot verification method according to the present invention may further include a second log recording step of recording a second log record related to the second loading step in the log record.

The secure boot verification method according to the present invention may further include a third log recording step of recording a third log record related to the third loading step in the log record.

In the secure boot verification method according to the present invention, the log verification step may be a step of checking whether a verification procedure is bypassed in the secure boot process.

In the secure boot verification method according to the present invention, the log verification step is performed by a server connected to the secure element through a network, and the server does not receive a response from the secure element in the log verification step or the log record is incorrect. If there is one value, the IoT device equipped with the security element may be excluded from the network or the operation may be stopped.

In the secure boot verification method according to the present invention, the log record is accessible only through authentication made through signature verification or MAC (Message Authentication Code) verification, and the security element and the server are mutually You can perform authentication and share the MAC (Message Authentication Code) generation key.

In the secure boot verification method according to the present invention, the secure boot verification method, characterized in that the secure element is provided with a Java card.

In the secure boot verification method according to the present invention, the secure element includes a memory unit for storing data, a communication unit for communication with the outside, a processor for performing various operations, and an encryption unit for protecting data and encrypting contents hardware part; an applet unit comprising at least one applet stored in the memory unit; an API unit comprising: a framework providing a software environment so that the applet can run; and at least one API that provides a function to run the applet; an execution environment unit including a virtual machine that analyzes and executes the bytecode of the applet; It is composed of an architecture including an operating system unit that allows the hardware unit to be used by the execution environment unit, and the applet unit may be provided with a secure boot applet for storing the log record. can

In the secure boot verification method according to the present invention, the API unit is provided as a Java Card API, and may additionally include a security protocol encryption API that provides a function so that the Secure Boot Applet can be driven. .

In the secure boot verification method according to the present invention, a verification security module constituting a library for driving the secure boot applet is mounted on the operating system unit, and the security protocol encryption API includes the verification security module can be used

In the secure boot verification method according to the present invention, the security protocol encryption API is used for certificate signature generation and verification using the verification security module, key distribution, data encryption MAC generation and verification, and integrity verification through hash algorithm It may be an API that provides a function to be used.

In the secure boot verification method according to the present invention, the secure protocol encryption API may include an API required for a handshake for distributing a certificate between the IoT device and the server.

In the secure boot verification method according to the present invention, the verification security module may be a security module verified through a Cryptographic Module Validation Program (CMVP) or a Korea Cryptographic Module Validation Program (KCMVP).

The secure element according to the present invention is a secure element that is mounted on an IoT device and proceeds with secure boot, a memory unit for storing data, a communication unit for communication with the outside, and various calculations. a hardware unit including a processor and an encryption unit for protecting data and encrypting contents; an applet unit comprising at least one applet stored in the memory unit; an API unit comprising: a framework providing a software environment so that the applet can run; and at least one API that provides a function to run the applet; an execution environment unit including a virtual machine that analyzes and executes the bytecode of the applet; It consists of an architecture including an operating system unit that allows the hardware unit to be used by the execution environment unit, and the applet unit is provided with a secure boot applet to store the log record. , by checking the log record by a server connected to the IoT device through a network, it is possible to determine whether secure boot is normally performed.

In the secure element according to the present invention, the API unit is provided as a Java Card API, and may additionally include a security protocol encryption API that provides a function so that the Secure Boot Applet can be driven.

In the security element according to the present invention, the operating system unit is equipped with a verification security module constituting a library for driving the Secure Boot Applet, and the security protocol encryption API can use the verification security module. there is.

In the security element according to the present invention, the security protocol encryption API is a function used for certificate signature generation and verification, key distribution, data encryption MAC generation and verification, and integrity verification through a hash algorithm using the verification security module It may be an API that provides

In the secure element according to the present invention, the secure protocol encryption API may include an API required for a handshake for distributing a certificate between the IoT device and the server.

In the security element according to the present invention, the verification security module may be a security module verified through a Cryptographic Module Validation Program (CMVP) or a Korea Cryptographic Module Validation Program (KCMVP).

According to the secure boot verification method and the secure element therefor according to the present invention, the secure element (SE) is a boot manager (Boot Manager), OS loader (OS Loader), OS (Operating System) in the process of secure boot (Secure Boot) Verification (Log Record) in each loading step by recording a log record related to each step of loading By making it possible to check whether the verification process has been bypassed or not, it is possible to check whether the hacker has loaded the hacker's own OS by skipping the verification process. It can guarantee whether Secure Boot) is properly performed.

1 is a conceptual diagram illustrating a secure boot verification method according to an embodiment of the present invention.
2 is a flowchart of a secure boot verification method according to an embodiment of the present invention;
Figure 3 shows the architecture (architecture) of the secure element (Secure Element, SE) according to an embodiment of the present invention.

Hereinafter, specific embodiments of the present invention will be described in detail with reference to the drawings. However, the spirit of the present invention is not limited to the presented embodiments, and those skilled in the art who understand the spirit of the present invention may add, change, delete, etc. other elements within the scope of the same spirit, and may use other degenerative inventions or the present invention. Other embodiments included within the scope of the spirit of the invention may be easily proposed, but this will also be included within the scope of the spirit of the present invention.

In addition, components having the same function within the scope of the same idea shown in the drawings of the embodiments will be described using the same reference numerals.

The secure boot verification method (S100) according to an embodiment of the present invention performs a secure boot using a secure element (SE, 100) mounted on an IoT device, and secure boot (Secure Boot) It may be a secure boot verification method that verifies whether or not has proceeded normally.

1 is a conceptual diagram for explaining a secure boot verification method S100 according to an embodiment of the present invention, and FIG. 2 is a flowchart of a secure boot verification method S100 according to an embodiment of the present invention.

1 and 2, the secure boot verification method (S100) according to an embodiment of the present invention includes a first loading step (S110) of loading a boot manager from a ROM, the first loading step ( A first log recording step (S120) of recording a first log record related to S110) in a log record (S120), a second loading step of loading an OS loader (OS Loader) from the boot manager (S130) ), a second log recording step (S140) of recording a second log record related to the second loading step (S120) to a log record, and loading an OS (Operating System) from the OS loader a third loading step 150, a third log recording step (S160) of recording a third log record related to the third loading step (S150) in a log record (Log Record), and the log record It may include a log verification step (S170) of determining whether secure boot has been normally performed by checking .

In this case, the first to third log records may include the date and time at which the first to third loading steps (S110, S130, S150) were made, progress contents, and the like.

On the other hand, in the log verification step (S170), the secure element 100 and the server 200 connected to the network check the log record including the first to third log records, and secure boot ( In the Secure Boot) process, it may be a step of checking whether or not the verification process is bypassed.

Through this, when the server 200 does not respond to the security elements SE and 100 in the log verification step S170 or there is an incorrect value among the first to third log records, the security element in the network It is possible to take measures such as excluding the IoT device equipped with (SE, 100) or stopping the operation.

In this case, the log records including the first to third log records may be accessible only through authentication, and such authentication is a signature verification or MAC (Message Authentication Code) verification. can be done through

To this end, the secure element (SE, 100) and the server 200 may perform mutual authentication and may share a MAC (Message Authentication Code) generation key.

Meanwhile, the secure boot verification method ( S100 ) according to an embodiment of the present invention may be performed by the secure element 100 and the server 200 provided with the secure boot applet 121 , in which case the secure element 100 . The architecture of ), as shown in FIG. 1 , includes a hardware unit 110 , an applet unit 120 , an API unit 130 , an execution environment unit 140 , and an operating system unit 150 . can

FIG. 3 shows in more detail the architecture of the secure element (SE, 100) for the secure boot verification method (S100) according to an embodiment of the present invention.

Hereinafter, the secure element (Secure Element, SE, 100) will be described in more detail with reference to FIG. 3 .

The secure element SE and 100 may be provided as a Java Card, and hereinafter, the secure element 100 provided as a Java Card will be described as a reference.

The hardware unit 110 includes a memory unit 111 for storing data, a communication unit 112 for communication with the outside, a processor 113 for performing various operations, and an encryption unit 114 for protecting data and encrypting contents. ) can be provided.

The memory unit 111 may include any one or more of a flash memory and an EEPROM, and may be used as a storage space for various data.

The communication unit 112 may follow the international standard set by the International Organization for Standardization (ISO) as ISO 7816.

Accordingly, the communication unit 112 may include eight terminals C1 to C8, where C1 is a terminal that supplies power, C2 is a terminal that receives a reset signal for initialization, and C3 is a terminal that receives a clock signal for operation. Terminal, C5 is a ground terminal, C6 is a terminal to which Single Wire Protocol (SWP) supporting short-range wireless communication (NFC) is applied, C7 may be an I/O (input/output) terminal through which data is transmitted and received, and C4 and C8 are It may be a terminal for a USB interface.

Meanwhile, the communication unit 112 may include six terminals C1 to C3 and C5 to C7 except for C4 and C8.

In addition, the communication unit 112 may communicate in various communication methods such as I2C, SPI, GPIO, etc. in addition to ISO7816, and may change packaging for communication line connection necessary for this. In this case, the communication unit 112 may be fixed to the IoT device by soldering according to the packaging change for connection of the communication line described above.

In this way, when the communication unit 112 is fixed to the IoT device by soldering, packaging such as DFN or QFN may be used.

The processor 113 may be provided as a non-memory chip that interprets and executes bytecode itself as a machine language.

The encryption unit 114 includes Data Encryption Standard (DES), Advanced Encryption Standard (AES), Rivest Shamir Adleman (RSA), Error Corection Code (ECC), ARIA (Korean Encryption Standard), Hash-based Message Authentication Code (HMAC) may be applied.

The applet unit 120 may be provided with a plurality of applets stored in the memory unit 111 .

In this case, the plurality of applets may include a secure boot applet (Secure Boot Applet) 121 , an IoT security applet 122 , and a USIM applet 123 .

Here, the plurality of applets are service tools manufactured using the Java language, respectively, and may be implemented as a Java Card Applet, and the Secure Boot Applet 121 is a secure boot ( Applet for signature verification and integrity verification during Secure Boot), IoT security applet 123 stores and uses keys and certificates so that cryptographic operations and multiple terminals can be securely connected in the secure protocol for IoT It is an applet that builds a file system required for , and the USIM applet 124 may be an applet for user authentication on mobile networks such as 3G, LTE (4G), and 5G.

The secure boot applet 121 may store a log record for confirming whether secure boot proceeds as a normal procedure.

Here, the secure boot process includes a first loading step S110 of loading a boot manager from the ROM, and a second loading of loading an OS loader from the boot manager. It may include a step (S130), and a third loading step (S150) of loading the OS from the OS loader, the log record is the first to third loading steps (S110, S130 and S150) and each related record may be included.

In other words, the log record includes a first log record related to the first loading step (S110), a second log record related to the second loading step (S130), and the third loading step (S150). It may include a third log record related to

In this case, the first to third log records may include the date and time at which the first to third loading steps were performed, progress contents, and the like.

On the other hand, the server 200 checks the log record including the first to third log records, and whether the authentication procedure is bypassed in the secure boot process. can be checked.

Through this, when there is no response in the process of checking the log record, or there is an incorrect value among the first to third log records, the server 200 performs the security element (SE, 100) in the network. It is possible to take measures such as excluding an IoT device equipped with an IoT device from the network or stopping its operation.

At this time, the log records including the first to third log records may be accessible only through authentication, and such authentication is the signature verification or MAC (Massage Authentication Code) verification. can be done through

To this end, the secure element SE 100 and the server 200 may share a public key and a private key.

The API unit 130 is a framework 131 that provides a software environment so that the plurality of applets can be driven, and an API (Application Programming Interface, 132) that provides functions to drive the plurality of applets. can be composed of

In this case, the framework 131 may be a Java Card Framework that provides various libraries for driving the plurality of applets using Java Card technology.

Meanwhile, the API (Application Programming Interface, 132) may be provided as a general Java Card API (Java Card API, 132a), and a Secure Protocol Crypto API (API, 132b) may be additionally provided.

The Secure Protocol Crypto API (API) 132 uses a verification security module 155 to be described later to generate and verify a certificate signature, distribute a key, generate and verify data encryption MAC, and verify integrity through a hash algorithm. It may be an API that provides a function used for

Through this, the Secure Protocol Crypto API (API) 132b can provide a function for driving the Secure Boot Applet 121 and the IoT Security Applet 122 .

In addition, the Secure Protocol Crypto API (API) 132b may include an API required for a handshake for distributing a certificate between the IoT device and the server 200 .

The execution environment unit 140 may include a virtual machine 141 that analyzes and executes bytecodes of the plurality of applets 121 , 122 , and 123 .

In this case, the virtual machine (Virtual Machine, 141) may be a Java Card Virtual Machine (Java Card Virtual Machine).

Meanwhile, referring to FIG. 3 , the virtual machine 141 may include a garbage collector, an access controller, an interpreter, and an applet firewall.

The operating system unit 150 may enable the hardware unit 110 to be used by the execution environment unit 140 , and may include a command processor (Command Processor, 151), memory management (Memory Management, 152), and a communication module (Communication). Module 153 , and a verification security module 154 .

At this time, the operating system unit 150 is provided as a native chip OS to form a COS kernel (COS kernel, 150a), and accordingly, the command processor (Command Processor, 151) and memory management (Memory Management, 152) ), a communication module 153 , and a verification security module 154 may be mounted under the COS kernel 150a.

The COS kernel (COS Kernel, 150a) can be accessed only through the API 132 of the API unit 130, and the verification security module 154 is mounted under the COS kernel (COS Kernel, 150a). Therefore, stronger security can be achieved.

In other words, it is possible to access the verification security module 154 through the secure protocol encryption API (Secure Protocol Crypto API, 132b) additionally provided in the API unit 130, and the secure boot applet (Secure Boot). Since the Applet 121 and the IoT security applet 122 are driven by utilizing the Secure Protocol Crypto API 132, the Secure Boot Applet 121 and the IoT security applet 122 ), it is possible to support various functions necessary for actual IoT security by utilizing the verification security module 154 .

More specifically, the IoT security applet 122 is driven in the security protocol encryption API (Secure Protocol Crypto API, 132) environment and utilizes the verification security module 154 to perform various IoT security protocols (Secure Protocol). A file system required for storage and use of keys and certificates can be built so that cryptographic operations and multiple terminals can be securely connected, and the issuance, deletion, and access rights of keys and certificates are managed. can do. In addition, the IoT security applet 122 can also manage the life cycle of the IoT device.

In addition, the hash algorithm and signature verification algorithm used in the secure boot by the secure boot applet 121 may use the verification security module 154 .

Meanwhile, the verification security module 154 may be a security module verified through a Cryptographic Module Validation Program (CMVP) or a Korea Cryptographic Module Validation Program (KCMVP).

As described above, according to the secure boot verification method ( S100 ) and the secure element 100 for the same according to an embodiment of the present invention, the secure elements ( SE and 100 ) are the boot managers in the secure boot process. (Boot Manager), OS Loader (OS Loader), OS (Operating System) to record a log record related to each step of loading, and then check the log record (Log Record) by the server 200 This allows the hacker to skip the Verification process and check whether the Verification process has been bypassed at each loading stage by determining whether the Secure Boot has been performed normally. It is possible to check whether the OS of the OS is loaded or not, so it is possible to guarantee whether Secure Boot has been properly performed without additionally installing Anti-Malware.

In addition, the secure element (Secure Element, SE, 100) is a communication unit 112 conforming to ISO 7816, a SIM applet that enables user authentication on a wireless network (USIM Applet, 123), and the SIM applet (USIM Applet) It has an API unit 130 and an execution environment unit 140 to drive the , and not only enables user authentication on a wireless network, which is a function of a general USIM, but also uses a secure boot applet (Secure Boot Applet, 121). Secure Boot) is possible, so a high level of security can be maintained.

In addition, the secure element (SE, 100) according to an embodiment of the present invention is equipped with a verification security module 154 under the COS kernel (COS Kernel, 150a), and stores the key (Key) at the hardware level. In addition, secure protocol encryption operations such as TLS (Transport Layer Security) are performed to achieve a strong level of security protocol because the key is not exposed.

In the above, an embodiment of the present invention has been described in detail, but the scope of the present invention is not limited thereto, and various modifications and variations are possible within the scope without departing from the technical spirit of the present invention described in the claims. It will be apparent to those of ordinary skill in the art.

100: secure element according to an embodiment of the present invention
110: hardware unit 111: memory unit
112: communication unit 113: processor
114: encryption unit 120: applet unit
121: secure boot applet 122: IoT security applet
123: USIM applet 130: API part
131: framework 132: API
132a: Java Card API 132b: Security Protocol Encryption API
140: execution environment unit 141: virtual machine
150: operating system unit 150a: COS kernel
151: command processor 152: memory management
153: communication module 154: verification security module
S100: Secure boot verification method according to an embodiment of the present invention
S110: first loading step S120: first log recording step
S130: second loading step S140: second log recording step
S150: third loading step S160: third log recording step
S170: log verification step

Claims (19)

A secure boot verification method for performing a secure boot using a secure element mounted on an IoT device and verifying whether the secure boot has proceeded normally,
a first loading step of loading a boot manager from the ROM;
a first log recording step of recording a first log record related to the first loading step in a log record;
a second loading step of loading an OS loader from the boot manager;
a third loading step of loading the OS from the OS loader; and
and a log verification step of determining whether secure boot has been normally performed by checking the log record.
According to claim 1,
and a second log recording step of recording a second log record related to the second loading step in the log record.
3. The method of claim 2,
The method of claim 1, further comprising: a third log recording step of recording a third log record related to the third loading step in the log record.
According to claim 1,
The log verification step is a step of checking whether a verification procedure is bypassed during a secure boot process.
According to claim 1,
The log verification step is performed by a server connected to the secure element and a network,
Secure boot, characterized in that the server excludes the IoT device equipped with the secure element from the network or stops the operation if there is no response from the secure element in the log verification step or there is an incorrect value in the log record Verification method.
According to claim 1,
The log record is accessible only through authentication made through signature verification or MAC (Message Authentication Code) verification,
The secure boot verification method, characterized in that the secure element and the server perform mutual authentication and share a MAC (Message Authentication Code) generation key.
According to claim 1,
The secure boot verification method, characterized in that the secure element is provided with a Java card.
8. The method of claim 7,
The security element is
a hardware unit including a memory unit for storing data, a communication unit for communication with the outside, a processor for performing various operations, and an encryption unit for protecting data and encrypting contents;
an applet unit comprising at least one applet stored in the memory unit;
an API unit comprising: a framework providing a software environment so that the applet can run; and at least one API that provides a function to run the applet;
an execution environment unit including a virtual machine that analyzes and executes the bytecode of the applet;
It consists of an architecture including; an operating system unit that allows the hardware unit to be used by the execution environment unit;
The secure boot verification method, characterized in that the applet unit is provided with a secure boot applet (Secure Boot Applet) for storing the log record (Log Record).
9. The method of claim 8,
The API unit is provided as a Java Card API, and the secure boot verification method, characterized in that it additionally comprises a security protocol encryption API that provides a function so that the secure boot applet can be driven.
10. The method of claim 9,
The operating system unit is equipped with a verification security module constituting a library for driving the secure boot applet,
The secure boot verification method, characterized in that the security protocol encryption API uses the verification security module.
11. The method of claim 10,
The security protocol encryption API is an API that provides functions used for certificate signature generation and verification, key distribution, data encryption MAC generation and verification, and integrity verification through a hash algorithm using the verification security module. How to verify secure boot.
12. The method of claim 11,
The security protocol encryption API includes an API required for a handshake for distributing a certificate between the IoT device and the server.
11. The method of claim 10,
The secure boot verification method, characterized in that the verification security module is a security module verified through a Cryptographic Module Validation Program (CMVP) or a Korea Cryptographic Module Validation Program (KCMVP).
In a secure element that is mounted on an IoT device and proceeds with secure boot,
a hardware unit including a memory unit for storing data, a communication unit for communication with the outside, a processor for performing various operations, and an encryption unit for protecting data and encrypting contents;
an applet unit comprising at least one applet stored in the memory unit;
an API unit comprising: a framework providing a software environment so that the applet can run; and at least one API that provides a function to run the applet;
an execution environment unit including a virtual machine that analyzes and executes the bytecode of the applet;
It consists of an architecture including; an operating system unit that allows the hardware unit to be used by the execution environment unit;
The applet unit is provided with a secure boot applet to store the log record (Log Record),
A security element, characterized in that by checking the log record by a server connected to the IoT device through a network, it is determined whether a secure boot is normally performed.
15. The method of claim 14,
The API unit is provided as a Java Card API, the secure element characterized in that it additionally comprises a security protocol encryption API that provides a function so that the secure boot applet (Secure Boot Applet) can be driven.
16. The method of claim 15,
The operating system unit is equipped with a verification security module constituting a library for driving the secure boot applet,
wherein the security protocol encryption API uses the verification security module.
17. The method of claim 16,
The security protocol encryption API is an API that provides functions used for certificate signature generation and verification, key distribution, data encryption MAC generation and verification, and integrity verification through a hash algorithm using the verification security module. security element to do.
18. The method of claim 17,
The secure protocol encryption API includes an API required for a handshake for distributing a certificate between the IoT device and the server.
17. The method of claim 16,
The verification security module is a security element, characterized in that the security module verified through CMVP (Cryptographic Module Validation Program) or KCMVP (Korea Cryptographic Module Validation Program).

Images