KR20230121382A - Semiconductor chip and software security execution method using thereof - Google Patents

Abstract

In a semiconductor chip, a process core, based on an Elliptic Curve Digital Signature Algorithm (ECDSA), a code authentication unit that cryptographically confirms and authenticates a signature of a software code executed in the process core, and the code authentication unit is symmetrical and A key management unit generating and distributing an asymmetric encryption key may be included.

Description

Semiconductor chip and software security execution method using the same

The disclosed invention relates to a semiconductor chip and a software security execution method using the same, and more particularly, to a semiconductor chip capable of preventing a malicious code from being loaded and executed at an early stage of a booting process before an operating system is loaded, and a software security execution method using the same It is about.

Securing computing devices containing thousands of connected resources is a major challenge today. To ensure system integrity and software vendor reliability, secure boot is supported on many commercial processors. However, existing secure boot solutions have been compromised by complex or light attacks.

Booting is one of the critical points in the life of a secure system where system integrity can be compromised. Many attacks compromise software while the device is powered off, for example by replacing the OS kernel image with a compromised image, making the system vulnerable. One of the principles governing secure systems is the creation of a chain of trust for every piece of software that runs, from the first boot loader to the trusted application, which must be established from a root of trust that cannot be easily tampered with. Therefore, all secure devices including laptops, desktops, smartphones and IoT devices need to implement secure boot to ensure system integrity.

More specifically, in the software-based security technology, whenever a new attack using a vulnerability such as an OS (Operation System) comes out, it is necessary to continuously update the security. Therefore, in order to prevent security attacks, the design and operation of security attack prevention at the hardware module level were proposed. As a security method at the hardware module level, ARM's TrustZone technology is used.

Hardware-based security technologies such as the TrustZone technology verify and read the integrity of the OS image at the booting stage, so the integrity of the platform can be guaranteed step-by-step from the system startup stage. This is a way for the hardware to verify the integrity of the OS and software. However, it does not verify the integrity of hardware from the point of view of software.

One aspect of the disclosed invention is to provide a semiconductor chip capable of preventing malicious code from being loaded and executed at an early stage of a booting process before an operating system is loaded, and a software security execution method using the same.

In a semiconductor chip according to an aspect of the disclosed subject matter, a process core, a code authenticator configured to authenticate a signature of a code of software executed in the process core based on an Elliptic Curve Digital Signature Algorithm (ECDSA), and the code The authentication unit may include a key management unit generating and distributing symmetric and asymmetric encryption keys.

The process core may include a ROM 160 (Readable Only Memory) loaded with a bare metal boot program.

The process core executes a Berkeley Boot Loader (BBL), wherein the BBL initializes the semiconductor chip, sets a page table and virtual memory, loads a kernel into the virtual memory, and boots the kernel. At least one of the operations may be performed.

The BBL may load the kernel to an external storage electrically connected to the process core.

The code authenticator may authenticate the signature of the code of the bare metal boot in an encryption method, and in response to the authentication of the code signature of the bare metal boot, authenticate the code signature of the BBL in an encryption method.

The process core may execute an application in response to the verification of the signature of the code of the BBL.

The semiconductor chip may further include a booting sequencer that sequences the flow of a booting process.

The booting sequencer may collect authentication results of the code verification unit and determine whether to stop the booting process.

The boot sequencer can read code from memory and calculate a hash using the SHA3 hardware block.

The key management unit may include at least one of a True Random Number Generator (TRNG), a Physical Unclonable Function (PUF) 140, a Challenges Storage, and a One-Time Programmable (OTP) memory.

The PUF 140 may include an error correction code (ECC) encoding circuit to calculate a syndrome and store it in a memory together with a challenge.

A method for executing software security using the semiconductor chip according to claim 1 according to an aspect of the disclosed invention, wherein software is executed by a process core, symmetric and asymmetric encryption keys are generated and distributed by a key management unit, and code Software security may be performed by the authentication unit to authenticate the signature of the software code using an encryption method.

According to one aspect of the disclosed invention, it is possible to provide a semiconductor chip capable of preventing malicious code from being loaded and executed at an early booting process before an operating system is loaded, and a software security execution method using the same.

1 is a diagram for explaining a hardware-based secure booting architecture of a semiconductor chip according to an exemplary embodiment.
2 is a block diagram illustrating a configuration of a semiconductor chip according to an exemplary embodiment.
3 is a diagram for describing a hardware-based secure booting architecture of a semiconductor chip according to an exemplary embodiment.
4 is a conceptual diagram for explaining a conventional booting flow.
5 is a conceptual diagram illustrating a booting flow using a semiconductor chip according to an exemplary embodiment.
6 is a flowchart illustrating a software security execution method using a semiconductor chip, according to an exemplary embodiment.

Like reference numbers designate like elements throughout the specification. This specification does not describe all elements of the embodiments, and general content or overlapping content between the embodiments in the technical field to which the disclosed invention belongs is omitted. The term 'unit, module, member, or block' used in the specification may be implemented as software or hardware, and according to embodiments, a plurality of 'units, modules, members, or blocks' may be implemented as one component, It is also possible that one 'part, module, member, block' includes a plurality of components.

Throughout the specification, when a part is said to be "connected" to another part, this includes not only the case of being directly connected but also the case of being indirectly connected, and indirect connection includes being connected through a wireless communication network. do.

In addition, when a certain component is said to "include", this means that it may further include other components without excluding other components unless otherwise stated.

Throughout the specification, when a member is said to be located “on” another member, this includes not only a case where a member is in contact with another member, but also a case where another member exists between the two members.

Terms such as first and second are used to distinguish one component from another, and the components are not limited by the aforementioned terms.

Expressions in the singular number include plural expressions unless the context clearly dictates otherwise.

In each step, the identification code is used for convenience of description, and the identification code does not explain the order of each step, and each step may be performed in a different order from the specified order unless a specific order is clearly described in context. there is.

As mentioned above, among hardware-based security technologies, a technology in which hardware verifies the integrity of software through a procedure such as secure booting is common. If the OS of a smartphone or handheld device is not a flawless image, but is damaged or its security features have been tampered with by hacking, the hardware detects it at the booting stage and/or at the execution stage of a specific application. such as preventing security risks. When running a mobile banking or payment application on a smartphone with an OS modified by hackers, it is now common to verify that the OS is not hacked and the process is stopped.

Conversely, however, it has not been proposed that the OS or application software authenticate the hardware. As in these days, when the mobile OS of a smartphone, firmware of electronic equipment, embedded software, and various applications are distributed on-air, from the developer or manufacturer's point of view, the equipment to be installed and operated is genuine and tampered / damaged It is a sufficiently necessary skill to be guaranteed to be flawless. In the various embodiments presented below, the software itself is designed to prevent illegal imitation hardware, hardware whose use period has expired, hardware modified to access functions or information blocked by security in the original device, and the like. A technique for authenticating hardware is presented. Of course, since hardware includes content for authenticating software, in this respect, it may be understood as a system in which safety is guaranteed through mutual authentication of hardware and software.

In the following embodiments, a mutual authentication technology of hardware and software in a system-on-chip level device is illustratively described, but is not necessarily limited to this example. Therefore, there may be any number of similar applications without departing from the spirit of the invention, such as mutual authentication between hardware of handheld equipment and its OS or firmware, and furthermore, mutual authentication between automobiles or aircraft and their operating software.

Meanwhile, in order to help understanding of the present invention, the main concept of the present invention will be described below. In more detail, secure booting and digital signatures are described.

Regarding secure boot, every step in the boot process verifies the integrity of the next step. Secure boot can be understood by referring to the Unified Extensible Firmware Interface (UEFI) specification, starting with version 2.2. UEFI secure boot can verify the integrity of each step in the boot process by calculating hashes and comparing the result to cryptographic signatures.

You need to have access to the key database of trusted public keys at boot time to be able to verify signatures, and if secure boot fails the integrity check, booting can be aborted. If the boot process succeeds, the system can be expected with high confidence to run in a trusted state.

Additional terms and variants of Secure Boot describing the integrity checking process, such as Trusted Boot, Verified Boot, Verified Boot, Verified Boot, or Measured Boot, both in commercial products and in some research articles, have different meanings. . For example, Intel processors can support secure boot in two modes: measurement mode and verification mode. Illustratively, in both modes, the processor core's microcode may be the root of trust for the boot sequence. In measurement mode, the Trusted Platform Module (TPM) is responsible for storing and attesting measurements, while in verification mode, each component is signed by the manufacturer and these signatures can be verified before loading the component.

In another embodiment, the secure boot mechanism's root of trust may be built into immutable hardware integrated inside a dedicated secure processor. For example, Hardware Validated Boot (HVB) is AMD's proprietary secure boot format based on trust in read only memory (ROM 160). ROM 160 may verify a secure boot key that is later used to verify larger processor firmware fetched from the system flash.

Digital signature based authentication can be used in most web browsers (for SSL) and email packages. All public-key cryptosystems have security based on certain difficult-to-solve mathematical problems. For example, RSA has security based on the difficulty of integer factorization. Similarly, elliptic curve cryptography (ECC) has a security based on the elliptic curve discrete logarithm problem (ECDLP).

The most popular signature method using an elliptic curve is the Elliptic Curve Digital Signature Algorithm (ECDSA), the most popular encryption method is the Elliptic Curve Integrated Encryption Scheme (ECIES), and the most popular key agreement method is the Elliptic Curve Diffie- Hellman (ECDH).

The NIST standard for digital signatures recommends using prime fields, or binary extended fields for elliptic curves. Binary extended fields have the advantage that no carry is involved since field addition can be done with an XOR operation. This may lead to implementations that require less capacity and have better performance.

The Standards for Efficient Cryptography Group (SECG) defines the Koblitz curve secp256k1 used in the online cryptocurrency Bitcoin. NIST curves are more widely used and are characterized as more precise than other SECG curves.

Hereinafter, the working principle and embodiments of the disclosed invention will be described with reference to the accompanying drawings.

1 is a diagram for explaining a hardware-based secure booting architecture of a semiconductor chip 100 according to an exemplary embodiment of the present disclosure.

Referring to FIG. 1 , the semiconductor chip 100 according to an exemplary embodiment of the present disclosure can understand the code authenticator 120 that checks the integrity of the trust chain starting from the first boot loader to the application. The code authentication unit 120 (Code Authentication Unit, CAU) may perform an Elliptic Curve Digital Signature Algorithm (ECDSA) and a secure hash algorithm (SHA3). ECDSA makes it easier to integrate a Physical Unclonable (PUF) 140 for asymmetric key generation and management, which can be implemented using a Key Management Unit (KMU). Also, the code verification unit 120 may use DMA (Direct Memory Access) for quick code reading and verification.

The semiconductor chip 100 according to an embodiment of the present disclosure may provide a novel lightweight architecture for secure booting that guarantees system integrity and reliability of a software supplier. In addition, the semiconductor chip 100 may perform a framework including the key management unit 130 using an optimized PUF 140 (Physical Unclonable Function). In addition, the code authentication unit 120 can be integrated into the RISC-V SoC (semiconductor chip 100).

2 is a block diagram illustrating a configuration of a semiconductor chip 100 according to an exemplary embodiment of the present disclosure.

Referring to FIG. 2 , the semiconductor chip 100 may include a process core 110, a code authenticator 120, a key management unit 130, a PUF 140, a boot sequencer 150, and a ROM 160. can

Process core 110 may be, for example, a core of a RISC-V processor. Illustratively, the processor core 110 may execute software. More specifically, the software may include a bare metal boot program and/or a Berkely Boot Loader (BBL) program.

The main boot loading procedure instructions for RISC-V are defined in the Berkeley Boot Loader (BBL), the SoC's actual boot loader. BBL can perform several functions, such as initializing all peripherals, setting up page tables and virtual memory, loading a selected kernel (Linux) into virtual memory, and finally booting the kernel.

The entire boot flow can be broken down into several steps. The semiconductor chip 100 may include a storage ROM 160 loaded with a bare metal boot (C program). This boot program may be needed to load the actual bootloader, BBL. Next, step 2 may involve copying/moving the BBL into DDR RAM. The capacity of the BBL may in fact be larger than the on-chip boot ROM 160. Accordingly, recent developments in RISC-V can employ two options available to facilitate this process. Illustratively, in SD-Boot, the BBL may load a kernel from external storage connected externally to the process core 110. Also, in Ether-boot, the bare metal bootloader can advertise its presence on the network to incoming ARP queries.

Programs loaded through this can choose a kernel (e.g. Linux) to be an ELF file containing a BBL. On the other hand, in the second option, the ELF file (BBL+ kernel) can be split into UDP packets before sending over the network.

Final step 3 may include starting the BBL in machine mode, setting the machine mode trap vector and proceeding with kernel execution.

The code verification unit 120, as a hardware component, may cryptographically verify and authenticate the signature of each trusted code to be executed in the processor using an elliptic curve digital signature algorithm (ECDSA). The code authentication unit 120 may verify and authenticate each software code to be executed from initial booting to an application program. These mechanisms can effectively prevent unauthorized or modified code from running on the secure SoC.

Recent RISC-V developments may use reconfigurable memory mapping (instead of a fixed memory map). Here, the address can be automatically generated according to the build command for peripheral customization. This approach can be more advantageous as it ensures correct alignment of the starting address to prevent crossing the address boundary.

The final memory map (called a configuration string, for example) is used and can be automatically linked to C-programs (and other hardware modules). Thus, hard-coded instruction ROM 160 may consist of jump instructions, reset vectors, and configuration strings. This piece of code is signed and the signature can be appended to the end of the line of code.

ROM 160 is mapped to memory address 0x10000, and the first of these addresses may indicate that data code authenticator 120 will start performing signature verification. The value obtained can match the signature appended to the end of the code. A positive match result can lead to the next boot step. Otherwise, software execution may be suspended.

The key management unit 130 may be responsible for generating and distributing symmetric and asymmetric encryption keys. It can be composed of TRNG (True Random Number Generator), PUF (140) (Physical Unclonable Function), Challenges Storage, and OTP (One-Time Programmable) memory.

The TRNG creates a random challenge for the symmetric key challenge, and the challenge can be stored with its ID in storage. A challenge may be input to the PUF 140 to search for a specific key, and a response used as the key may be output. These symmetric keys can be used in some of the SoC's internal security blocks, such as memory protection units (memory encryption and integrity) and secure debug units.

The code authentication unit 120 may use an asymmetric key required for a public key algorithm. The public key may be fused to the key management unit 130 using the OTP memory.

Physical unclonable function (PUF) 140 can extract volatile secret keys from semiconductor manufacturing variants that only exist when the chip is powered on. The first documented use of a PUF 140 generated key in a secure processor setup was in an AEGIS processor.

PUF 140 may be used to generate a symmetric key that is shared with clients via a cryptographic protocol. PUF 140 can be used as a symmetric key generator in commercial products such as Xilinx FPGAs and Intel FPGAs. In the case of a public key algorithm (PKA), the PUF 140 can be used to generate a random seed for an asymmetric (public/private) key generator inside the secure processor.

There are two main steps for PUF 140 to derive a security key from an error correcting code: key initialization and regeneration. In a first step, a syndrome may be calculated in the PUF 140 through an error correction code (ECC) encoding circuit and stored in memory in pairs with a challenge. This may be used to correct errors found in the PUF 140 response. Next, a noisy response is taken from the PUF 140 and the corresponding syndrome (for the specific challenge) can be sent to the ECC decoder. With the help of the stored syndrome, the ECC can correct errors generated in the PUF 140 response.

An error may occur in the PUF 140 due to changes in voltage and temperature. More specifically, this design can encode a 7-bit message into a 15-bit code (7-bit message with 8-bit syndrome) and use BCH as an error-correcting code that can correct up to two errors at any position.

The boot sequencer 150 may be a finite state machine (FSM) that sequences the flow of the boot process of the semiconductor chip 100 . Boot sequencer 150 may be called whenever a new phase of booting is executed. The boot sequencer 150 may communicate with the key management unit 130 and send a related key to the code authentication unit 120 . After that, the boot sequencer 150 may request the code verification unit 120 to read the corresponding code from the memory and authenticate the signature using ECDSA.

The boot sequencer 150 may collect authentication results (pass or fail) and determine whether to continue or stop the boot sequence based on this. In the current implementation, boot sequencer 150 is a hardware state machine, but in future versions it may be replaced by a small microcontroller for better programmability and patchability. However, it is not limited thereto.

3 is a diagram for explaining a hardware-based secure booting architecture of the semiconductor chip 100 according to an exemplary embodiment of the present disclosure.

Referring to FIG. 3 , the key management unit 130 may generate and distribute keys to various security blocks, such as the code authentication unit 120, security debug and memory protection devices.

The code authenticator 120 may protect hardware from attacks such as image hacking, botnet registration, and cold boot attacks. Secure booting may be implemented using a code authentication unit 120 and a boot sequencer 150 .

The secure debug 31 can protect against various hardware threats such as key extraction, illegal debugging, probing and SCA (Side Channel Attacks).

A Trusted Execution Environment (TEE) ensures an isolated execution environment for trusted applications, and this feature can be essential to protect against attacks such as software exploitation, privilege escalation, and botnet registrations. Accordingly, the rocket core 32 (Rocket Core) can provide such a TEE environment.

Trusted off-chip memory can be an essential feature to prevent Side-Channel Attacks (SCA), probing, and key extraction from main memory. Accordingly, since the memory protection unit 33 (Memory Protection Unit, MPU) is also used to load and execute a trusted application program in the TEE, the code and data of the running application program can be protected. In this white paper, two main factors, code authentication unit 120 (code authentication unit 120) and key management unit 130 (key management unit 130), play an important role in providing secure boot in secure RISC-V SoCs. Design can be key.

In the semiconductor chip 100 , a trust chain must be established at an early stage of the booting sequence 150 and may be maintained while the OS and applications are executed. The chain may begin with the first step where an immutable bootloader runs in ROM 160 (read-only memory). This bootloader can cryptographically verify the signature of the second stage bootloader in the chain, and then this subsequent bootloader can cryptographically verify the signature of the next software image, etc. At the end of the chain, trusted applications can be verified before running in the SoC's Trusted Execution Environment (TEE).

The booting process of the semiconductor chip 100 may start by executing a hard-coded command (referred to as a ROM 160 slave in uncore /src/main/scala /ROM(160).scala). The sole purpose of this instruction may be to jump on the reset vector (referred to as the reset vector). That is, according to this, it is possible to move to the beginning of the BRAM. So these hard-coded instructions can be computed based on the reset vectors specified in the configuration file (chisel code in src/main/scala/Configs.scala).

The initial reset vector can be understood as a function make Boot ROM (chisel code located in src/main/scala/Low RISC Chip. there is. In order to achieve a secure boot flow in the semiconductor chip 100, the framework proposed by the present invention may establish a chain of trust by executing a code authentication procedure between boot loading steps. This authentication can be performed through the proposed code verification unit 120 integrating the signature verification procedure.

4 and 5 are conceptual views illustrating a conventional booting flow and a conceptual diagram illustrating a booting flow using the semiconductor chip 100 according to an exemplary embodiment of the present disclosure.

More specifically, referring to FIG. 4 , an existing flow using SHA3 and a software-based implementation of ECDSA (eg Sanctum) can be understood. Software can run on a process core, such as a RISCV core.

Meanwhile, referring to FIG. 5 , it can be understood that secure booting may be implemented by further using hardware units (code authenticator 120 and boot sequencer 150) using the semiconductor chip 100. .

Hardware secure booting through the semiconductor chip 100 according to an exemplary embodiment of the present disclosure may provide better performance and energy efficiency than software secure booting.

The semiconductor chip 100 according to an embodiment of the present disclosure may perform a secure boot framework implemented in a RISC-V lightweight SoC. The framework may use optimized Elliptic Curve Digital Signature Algorithm (ECDSA), Secure Hash Algorithm 3 (SHA3) hashing algorithm, Physical Unclonable Function (PUF) 140, and Direct Memory Access (DMA).

Secure boot is designed to prevent malicious code from loading and running early in the boot process, before the operating system loads. This is to prevent malicious software from "installing a boot kit and maintaining control of the computer to hide its existence."

Secure boot can establish a trust relationship between the UEFI BIOS and the eventually running software (e.g. bootloader, OS, UEFI drivers and utilities). After enabling and configuring secure boot, only software or firmware signed with an approved key can run.

It also prevents attackers from changing kernel cmd line parameters. However, this approach can be easily circumvented on most computers by installing a new bootloader. The bootloader executed by the semiconductor chip 100 according to an exemplary embodiment of the present disclosure may not need to comply with restrictions originally imposed by the bootloader. As a result, bootloader replacement may not be necessary in many cases. GRUB and other bootloaders are fully configurable via separate configuration files that can be edited to bypass security restrictions such as passwords.

6 is a flowchart illustrating a software security execution method using the semiconductor chip 100 according to an exemplary embodiment.

The software security execution method using the semiconductor chip 100 shown in FIG. 6 can be performed by the semiconductor chip 100 described above. Therefore, even if the contents are omitted below, the description of the semiconductor chip 100 can be equally applied to the description of the software security execution method using the semiconductor chip 100 .

Referring to FIG. 6 , the semiconductor chip 100 may execute software (S100).

Also, the semiconductor chip 100 may generate and distribute symmetric and asymmetric encryption keys (S200).

In addition, the semiconductor chip 100 may authenticate the signature of the software code using an encryption method (S300).

Meanwhile, the disclosed embodiments may be implemented in the form of a recording medium storing instructions executable by a computer. Instructions may be stored in the form of program codes, and when executed by a processor, create program modules to perform operations of the disclosed embodiments. The recording medium may be implemented as a computer-readable recording medium.

Computer-readable recording media include all types of recording media in which instructions that can be decoded by a computer are stored. For example, there may be a ROM 160 (Read Only Memory), RAM (Random Access Memory), magnetic tape, magnetic disk, flash memory, optical data storage device, and the like.

As above, the disclosed embodiments have been described with reference to the accompanying drawings. Those skilled in the art to which the present invention pertains will understand that the present invention can be implemented in a form different from the disclosed embodiments without changing the technical spirit or essential features of the present invention. The disclosed embodiments are illustrative and should not be construed as limiting.

100: semiconductor chip
110: process core 120: code authentication unit
130: key management unit 140: PUF (140)
150: boot sequencer 160: ROM (160)

Claims (13)

In the semiconductor chip,
process core;
a code verification unit that cryptographically authenticates a signature of a code of software executed in the process core based on ECDSA (Elliptic Curve Digital Signature Algorithm); and
and a key management unit generating and distributing symmetric and asymmetric encryption keys to the code authentication unit. According to claim 1,
The process core,
A semiconductor chip including a ROM 160 (Readable Only Memory) loaded with a bare metal boot program. According to claim 2,
The process core,
A Berkeley Boot Loader (BBL) is executed, and the BBL performs at least one of initializing the semiconductor chip, setting a page table and virtual memory, and loading a kernel into the virtual memory and booting the kernel. A semiconductor chip that performs According to claim 3,
The BBL is a semiconductor chip that loads the kernel to an external storage electrically connected to the process core. According to claim 4,
The code authentication unit,
A semiconductor chip that authenticates the signature of the code of the bare metal boot by a cryptographic method, and authenticates the signature of the code of the BBL by a cryptographic method in response to the authentication of the signature of the code of the bare metal boot. According to claim 5,
The process core,
A semiconductor chip that executes an application in response to authentication of the signature of the code of the BBL. According to claim 6,
The semiconductor chip,
A semiconductor chip that further includes a boot sequencer that sequences the flow of a boot process. According to claim 7,
The boot sequencer,
A semiconductor chip that collects authentication results of the code authentication unit and determines whether to stop the booting process. According to claim 8,
The boot sequencer,
A semiconductor chip that reads code from memory and uses the SHA3 hardware block to calculate a hash. According to claim 9,
The key management unit,
A semiconductor chip including at least one of a True Random Number Generator (TRNG), a Physical Unclonable Function (PUF), a Challenges Storage, and a One-Time Programmable (OTP) memory. According to claim 10,
The PUF 140,
A semiconductor chip that includes an error correction code (ECC) encoding circuit to calculate a syndrome and store it in a memory together with a challenge. A method for executing software security using the semiconductor chip according to claim 1,
run the software by the process core,
Generates and distributes symmetric and asymmetric encryption keys by the key management unit,
A software security execution method in which a code signature of the software is authenticated by a code authentication unit in a cryptographic manner. A computer-readable recording medium on which a program capable of executing the software security execution method of claim 12 is recorded.

Images