HARDWARE DEVICE AND AUTHENTICATING METHOD THEREOF

Abstract

A secure semiconductor chip is presented. The semiconductor chip is, for example, a system-on-chip. Processor cores included in the system-on-chip are connected to normal IPs through a system bus. A secure bus, which is a hidden bus physically separated from the system bus, is provided separately. The secure bus is connected to security IPs which perform security functions or handle security data. The secure semiconductor chip may perform necessary authentication by switching a normal mode to a secure mode.

Description

BACKGROUND

1. Technical Field

The present invention relates to hardware and an authentication method therefor, more particularly to a method of authenticating whether or not a hardware device such as a semiconductor chip or other electronic equipment, etc., is a genuine product and whether or not the device has been modified or damaged, etc.

2. Description of the Related Art

Software-based security techniques require continued security updates whenever there is a new attack that exploits a vulnerability in the OS (operating system), etc. Thus, to prevent security attacks, measures for preventing security attacks at the level of hardware modules have been designed and implemented. Security methods applied at the hardware module level include the TrustZone technology from ARM Ltd.

With a hardware-based security technique such as TrustZone, data is read after the integrity of the OS image is verified during the booting stage, and therefore the integrity of the platform can be ensured step-by-step from the beginning stage of the system. This involves hardware verifying the integrity of software, including the OS. However, from the perspective of the software, the technique does not verify the integrity of the hardware.

Registered U.S. Pat. No. 8,468,342 (published Jun. 18, 2013) presents a computing device that performs a safe booting by performing an OS integrity check when the system is booted.

The technological document “ARM Security Technology: Building a Secure System using TrustZone® Technology” (ARM Limited, White-Paper PRD29-GENC-009492C, April 2009) provides the hardware structure for TrustZone of ARM Ltd., as well as material regarding secure booting, etc., for implementation thereof.

SUMMARY OF THE INVENTION

An aspect of the invention is to provide a hardware device and an authentication method for authenticating a hardware device.

One aspect of the invention provides a semiconductor chip that includes: a processor core; and an authentication part configured to perform mutual authentication with an outside trusted authority to perform authentication between the semiconductor chip and the outside trusted authority.

According to an embodiment of the invention, the semiconductor chip may further include: a first group which includes elements that are connected to the processor core by way of a first bus; and a second group which includes elements that are connected to the processor core by way of a second bus and are configured to operate in a secure mode. In this case, the second group may be activated and usable only if the authentication part successfully performs the authentication. In one example which does not limit the invention, the second group may include at least one of a cryptographic IP, a secure SRAM, a secure DMA, and a boot ROM.

According to an embodiment of the invention, the semiconductor chip can further include a PUF that is configured to provide a key used by the authentication part for the mutual authentication with the outside trusted authority. According to an embodiment of the invention, the second group may process data by using a memory address different from that of the first group.

In one example which does not limit the invention in any way, the processor core may include a Core-A processor, which may be a 32-bit RISC (reduced instruction set computing) type embedded processor. In this embodiment, the second bus may include a hidden bus that is implemented by using an ASR (application specific register) of the Core-A processor as an address space for controlling elements included in the second group. In this case, the second group can use an MTA (move to ASR) command and an MFA (move from ASR) command, which are commands for processing data in relation to the ASR, in the secure mode for processing secure instructions. This can be understood as implementing a hidden bus for secure IP' s included in the second group by using the ASR interface. According to another embodiment, the processor core can be a RISC-V ISA applied CPU core.

According to an embodiment of the invention, the authentication part may be a hardware logic and is operated in an independent language different from existing computing language to perform the authentication procedure. Also, the authentication part can perform an authentication procedure configured in an independent language different from existing computing language. According to an embodiment of the invention, the authentication part may be configured with a general cell unlike an IP within the semiconductor chip or ROM, so as not to be exposed to the outside during a PnR (place and route) or receive a security attack.

Another aspect of the invention provides a hardware device in which software is embedded, where the hardware device includes: a processor core configured to operate the software; and an authentication part configured to perform mutual authentication with an outside trusted authority to perform authentication between the semiconductor chip and the outside trusted authority for operating the software by way of the hardware device. According to an embodiment of the invention, the device can further include a first bus that connects a first group to the processor core and a second bus that connects a second group to the processor core, where the first group includes elements that are configured to operate in a normal mode, and the second group includes elements that are configured to operate in a secure mode. According to an embodiment of the invention, access to the second bus may be activated such that the second group is usable only if the authentication part successfully performs the authentication.

According to an embodiment of the invention, the hardware device can further include a PUF that is configured to provide a key used by the authentication part for the mutual authentication with the outside trusted authority.

Yet another aspect of the invention provides an operation method for a semiconductor chip, where the operation method includes: performing mutual authentication with an outside trusted authority, as performed by an authentication part; and activating a secure mode of the semiconductor chip if the authentication is successful. Here, the semiconductor chip can include a first bus that connects a first group to the processor core and a second bus that connects a second group to the processor core, the first group including elements configured to operate in a normal mode, and the second group including elements configured to operate in a secure mode. In this case, the method can include activating the second group and the second bus if the authentication is successful, and deactivating the second group and the second bus and activating the first group and the first bus if the authentication is not successful. According to an embodiment of the invention, the second group may include at least one of a cryptographic IP, a secure SRAM, a secure DMA, and a boot ROM.

The present invention provides the advantage of enabling the authentication of a hardware device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a SoC device according to an embodiment of the invention.

FIG. 2 illustrates a structure for implementing a SoC according to an embodiment of the invention.

FIGS. 3A to 3F are diagrams for describing protocols and procedures for performing pre-authentication according to an embodiment of the invention.

FIG. 4 is a flow diagram for describing the flow of a secure booting according to an embodiment of the invention.

FIG. 5 is a conceptual diagram for describing the implementation of a PUF according to an embodiment of the invention.

FIG. 6 illustrates a secure SoC platform that is fundamentally protected from physical attacks according to an embodiment of the invention.

FIG. 7 and FIG. 8 are flow diagrams for performing a secure booting according to an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

Certain embodiments of the invention will be described below in more detail with reference to the accompanying drawings. However, the scope of rights is not constrained by or limited to such embodiments. In the drawings, the same reference numerals represent the same components.

While the terms used in the descriptions below are those that are typically and commonly used in the relevant field of technology, different terms can be used under different circumstances due to technological advances and/or changes, traditions, preferences of technicians, etc. Thus, the terms used in the descriptions below must not be understood to be limiting the technical spirit and are to be understood as illustrative terms.

Furthermore, in certain cases, some of the terms used were arbitrarily chosen by the applicant, and in such cases, the detailed meanings of the terms may be disclosed in the corresponding descriptions. Thus, the terms used in the descriptions below should be understood not only by how the terms are named but by the meanings conveyed by the terms as well as the context of the overall specification.

Mutual Authentication of Hardware and Software

As mentioned above, a common technique in hardware-based security entails hardware verifying the integrity of software by a procedure such as secure booting. If it is discovered that the OS of a smart phone or handheld device does not have a faultless image but was damaged or that a security function has been modified by hacking, etc., then the hardware may discover this during the booting stage and/or during the execution of a particular application, thereby avoiding a security risk. It is now frequently observed that, if a mobile banking or payment application is executed on a smart phone on which an OS modified by a hacker is installed, the OS is checked to see whether or not it has been hacked, and the procedure is halted.

Conversely, however, there have been no cases in which the OS or application software authenticates hardware. Where various applications, ranging from the mobile OS for smart phones to firmware and embedded software of electronic devices, are installed via on-air distribution as in recent times, there is a sufficient need from the perspective of developers or manufacturers to be ensured that the device on which these are installed is a genuine product and is faultless in terms of modification/damage. In the several embodiments described below, there is presented a technology that enables software to independently authenticate hardware, for avoiding illegally copied hardware, hardware of which the contractual expiration date has been exceeded, hardware that has been modified for the purpose of accessing functions or information that were blocked in the original apparatus for security reasons, and the like. Of course, since the hardware also authenticates the software, the system may be understood as one that ensures safety by way of mutual authentication between hardware and software.

While the embodiments below are described using an example involving mutual authentication between hardware and software in a device at the system-on-chip level, the invention is not necessarily limited to such an example. The technology can be applied in a similar manner in various cases, such as for mutual authentication between hardware for handheld devices and its OS or firmware, mutual authentication between a vehicle or airplane and its operating software, etc., without departing from the spirit of the present invention.

Security Attack on System-On-Chip Software

An attack on a SoC may include physical attacks and software attacks. If a physical attack could be neutralized and the software system could be protected by a secure SoC platform, then developers can concentrate on their work without being bothered by security issues. The embodiments presented here may provide a SoC platform that operates in a safe environment by preventing security attacks on software.

As it is sometimes difficult to defend against software attacks with only a software module, it is desirable to defend against security attacks at the hardware module level. For example, an environment such as that used by TrustZone from ARM Ltd. can be used. In order to use TrustZone, a secure OS (operating system) or a secure library defined according to the TEE (trusted execution environment) standard may be required. However, the performance requirements for the TEE can be at a level that is difficult to satisfy with a small CPU core and SoC's for end nodes in the IoT (Internet of things) that use real time OS (RTOS). Certain embodiments of the invention present a SoC that is equipped with a secure ISA (instruction set architecture) capable of directly supporting a TEE instead of a secure OS or secure library, which may incur a large overhead. Certain embodiments relating to a CPU core capable of implementing such secure ISA and an operation method of the CPU core are also presented. Various embodiments of the invention are described below with reference to the drawings.

System Configuration

FIG. 1 is a block diagram of a semiconductor system-on-chip 100 according to an embodiment of the invention. The chip may include a processor core 101. The core 101 may have a first bus 111 and a second bus 121 connected separately. The first bus 111 may be provided to a first group 112, which may be a general computing group that operates in the normal mode. A ‘group’ can be understood as a set of individual computing property (or IP-intellectual property-), memory, cache, etc. In the following descriptions, elements, IP, functional elements, computing property, etc., can be used interchangeably even when there is no specific mention that this is so.

The second bus 121 may be provided to a second group 122 that includes elements that operate only in the secure mode. The second bus 121 may be physically completely separated from the first bus 111. This physical isolation allows a differentiation between a normal world 110 and a secure world 120, and this differentiation provides a SoC that is robust to security attacks against software. The physical isolation can be understood to mean that data is processed with the first group 112 of the normal world 110 having a memory address system that is completely different from that of the second group 122 of the secure world 120.

The SoC 100 can include an authentication part 102 that performs mutual authentication for the secure world 120 with an outside certificate authority (not shown) when the system is powered on and/or when there is a need for running the secure mode. The authentication part 102 can receive authentication by proving to the outside trusted authority that the SoC 100, the second group 122 and its individual IP' s, as well as the software embedded therein are proper and faultless. Also, the authentication part 102 may perform mutual authentication by ascertaining that the outside terminal with which a current transaction is being carried out is the outside trusted authority and can be trusted. Amore detailed description of the issuance protocol, by which the authentication part 102 receives and registers a public key from a pre-authentication outside trusted authority to be issued a certificate of authentication, and the hardware authentication of software, such as by replacing an existing public key with a new public key as necessary, will be provided later on with reference to FIGS. 3A to 3F.

Switching Between Normal Mode and Secure Mode

A SoC 100 according to an embodiment of the invention can have a normal mode and a secure mode. Only when the authentication by the authentication part 102 described above is successful may the second group 122 be booted and the secure world 120 associated with the trusted execution environment (TEE) be activated. Of course, in this case, the first group 112 may be booted and the normal world 110 may be activated also. However, if the authentication has not been completed, only the first group 112 associated with a rich execution environment (REE) may be booted, so that the normal world 110 may be activated, but the secure world 120 may not be activated.

Even when the secure world 120 is activated, the second group 122 may not necessarily be always operational and can be in an idle state. During computing in the REE environment, for example while an Android operating system and applications are being run, the secure mode can be activated when there is a call for processing at an increased security level, such as when a security violation occurs or when a financial payment is required. In other words, in the normal world, a REE (rich execution environment) such as Android in mobile phones may operate with typical hardware IP's in an ARM-based SoC. Then, when secure resources such as a cryptographic IP or a secure SRAM is needed, a TEE made up of a secure OS and secure hardware IP's may operate and transmit results to the REE. TrustZone of ARM Ltd. additionally provides a 1-bit bus signal to an AMBA AXI as a control signal for accessing the secure IP's of the SoC platform. It may be difficult for regular small CPU cores and SoC's at IoT (Internet of things) end nodes using RTOS (real time OS) to satisfy the performance requirements for the TEE, but certain embodiments of the invention make this possible.

Means of Authentication

According to an embodiment of the invention, the semiconductor SoC 100 can further include a PUF (physical unclonable function) 103 that provides a root key used by the authentication part 102 in performing the mutual authentication with the outside trusted authority. At least one of various algorithms such as RSA, AES, etc., that use such a root key can be used in the authentication. In one example which does not limit the invention, the PUF can be included intrinsically in the semiconductor chip by using a processing tolerance in the semiconductor manufacturing process. In an example implementation, the PUF can involve vias or interlayer contacts that are laid out between conductive layers of the semiconductor, with the vias or contacts patterned normally during a process, whereby a digital value may be provided according to whether or not the conductive layers are short-circuited. A more detailed description of the implementation and role of the PUF will be provided later on with reference to FIGS. 5 and 6.

Secure Memory

According to an embodiment of the invention, a secure memory 130 may include an area utilized in the normal mode and an area utilized in the secure mode. The secure memory 130 may include, for example, a non-volatile memory (NVM). The area utilized in the secure mode can store data after encryption using the root key provided by the PUF 103 instead of storing the data as is. Therefore, even if the data of the secure memory 130 is physically extracted, the data would be meaningless if it is not directly connected with the PUF 103 and decoded.

Example System Implementation—Use of Core A Platform

FIG. 2 illustrates a structure for implementing a SoC in a Core-A environment according to an embodiment of the invention. In an example which does not limit the invention, the processor core may include a Core-A processor 201, which is a 32-bit RISC (reduced instruction set computing) type embedded processor. According to another embodiment, the processor core can also be a CPU core to which the RISC-V ISA has been applied. In the descriptions that follow, ‘processor’, ‘processor core’, ‘secure core’, ‘secure processor’, etc., should be understood as terms that can be used interchangeably. While the descriptions focus on an implementation using ‘Core-A’ as an example, it should be apparent to the person skilled in the art that different implementations are possible, such as those using a RISC-V ISA applied CPU core.

To a normal bus 210, the SRAM 211, peripheral IP's 212, and a debugging port 213, which are first group elements of the REE environment, may be connected. Also, to a secure bus 220, cryptographic IP's 221, a boot ROM 222, a secure SRAM 223, and a secure DMA 224, which are to be operated in the TEE environment, may be connected. As described above with reference to FIG. 1, an authentication part 202 and at least one PUF's 203 can be present for performing authentication. The PUF's 203 may be directly connected to the core 201 for the authentication and can also be directly connected to the AES/SEED IP and ECC/RSA IP, from among the cryptographic IP's. Furthermore, a secure NVM 230 may also be directly connected to the PUF's 203 to safely store data in an encrypted form.

A secure bus 220 according to an embodiment of the invention can be a hidden bus that is implemented by using the ASR (application specific register) of the Core-A processor as the address space for controlling the second group elements of the secure world. In this application, the second group can use a MTA (move to ASR) command and a MFA (move from ASR) command, which are data processing commands relating to the ASR, in processing secure instructions in the secure mode. This can be understood as using the ASR interface to implement a hidden bus for secure IP' s included in the second group.

According to such an implementation, a secure ISA (instruction set architecture) capable of directly supporting the TEE may be implemented instead of a secure OS or library having a large overhead. This may thus be more suitable for devices having small

CPU's compared to using TrustZone of ARM Ltd. In certain embodiments, a pre-authentication hardware may be provided, which may be an authentication part for managing the secure mode differentiated from the normal mode and for mutual authentication between hardware and software. Also, since there are provided mutual authentication hardware IP' s that use VIA-PUF (physical unclonable function), of which the reliability, stability, and randomness have been already verified, a ‘secure SoC platform’ may be provided that has a strengthened secure world. According to the presented embodiment, a secure ISA may be provided. This may be an ISA for the secure world version that is implemented separately from a regular ISA. Accessing resources within the secure world by a method based on the existing TrustZone technology of ARM Ltd. may require a secure OS or a complicated library. With the proposed embodiment, however, the resources within the secure world can be accessed immediately at the command level based on the secure ISA.

Also, by managing the secure mode with respect to the secure ISA by using a pre-authentication IP, the mutual authentication may be performed in a safe manner, and internal access by unauthorized users such as software attacks, for example, may be blocked. A secure core proposed according to the embodiment may provide a hidden channel to the secure world, and this may be physically separated from the main memory interface. Also, when software is being read, the secure DMA may be used for an automatic integrity check by the hardware, and an internal PUF may provide a key for a secure storage space or secure IP' s for authentication. A more detailed description of the above is provided as follows.

Secure ISA (Instruction Set Architecture)

In order to use resources within the secure world or call a secure function according to the existing method, it may be needed to operate a secure OS or library at the general CPU core. However, an embodiment of the invention may satisfy the requirements for the secure world and provide the characteristic functionality of the secure OS and library while providing a secure ISA having no overhead, thus functionally expanding the conventional Core-A. This makes it possible for the security system to directly access TrustZone without the help of a secure OS or library or without the difficulty of application development, as well as to reduce efforts for management. Some exemplary features of a secure ISA according to an embodiment of the invention may be as follows.

control flow integrity: the code for protecting the integrity of the control flow may be substituted by a single command for efficiency

key management: generation of random numbers and key pairs included for public key encryption

memory security level management: varying security level provided for each page and segment

security engine: ISA expansion that operates closely with secure hardware engine

secure booting/authentication: authentication for secure debugging and booting supported

secure mode management: management of microstructures for secure mode supported

register content protection: content of secure register encrypted with VIA-PUF

Performing Pre-Authentication

FIGS. 3A to 3F are diagrams for describing protocols and procedures for performing pre-authentication according to an embodiment of the invention. Referring to FIG. 3A, the hardware SoC 300 may include a portion 310 that processes authentication and operates in the secure mode. In order for a secure ISA to be used, a pre-authentication IP 302 can communicate with an outside certificate server, for example a TSM (terminal security management) system server 301 that manages the security of a terminal in a commercial network, through mutual authentication between end nodes when power is turned on or reset. As in the example implementation, which does not limit the invention, the mutual authentication can be based on a public key encryption method using a root key created by a PUF 303.

According to an embodiment of the invention, the authentication protocol in the pre-authentication IP 302 used in the mutual authentication may not be a typical language (e.g. a high-level language such as C, etc., or an assembly language for a particular core). As a dedicated language designed only for performing the authentication protocol is implemented in the pre-authentication IP 302, it may be difficult and virtually impossible to analyze. Also, the pre-authentication IP 302 may be implemented with hardware logic, to be therefore impervious to modifications (and ensuring integrity), and may be implemented as a combination of basic cells instead of having the form of a physically separate IP such as ROM, etc., to be able to blend in with other cells in a PnR (place and route) procedure for robustness against physical attacks such as reverse engineering, etc.

The server 301 and the proposed platform 300 may each generate a signature with its own personal key and have its own public key included in the certificate. The mutual authentication may be performed by exchanging certificates and signatures. The pre-authentication IP 302 may obtain the private key from the VIA-PUF 303 and may transmit a signature generated using the key to the certificate server. Also, the received signature may be verified using the public key of the outside certificate server that was previously stored. Here, the signature algorithm may be a public key encryption algorithm and can be ECC or RSA. When the system enters the secure mode after the mutual authentication is successful, the secure core may control secure booting. Also, the debugging port can be opened only in the secure mode, so that only authenticated users are able to perform debugging. The secure mode can be permitted when the authentication is successful, and the IP resources (311, 312, etc.) of the secure world can be permitted to operate.

The shared key exchanged during the mutual authentication can be used for future security purposes as an encryption key for exchanging data or a key for a MAC (message authentication code) and used as an IV (initial vector) used in encryption or a MAC to ensure confidentiality and integrity. The protocols for mutual authentication are described below in further detail.

Pre-Authentication Protocol

The pre-authentication protocol may include an ‘issuance protocol’, regarding registering a public key and being issued a certificate of authentication before use, and a ‘reissuance and renewal protocol’, for replacing an existing public key with a new public key as necessary and reissuing a certificate of authentication for the new public key. After the issuance, the chip may start with sending a request for usage to the TSM (terminal security management) system, and if the period of validity has not expired, a usage protocol may be performed directly, whereas if the period of validity has expired, a renewal protocol may be performed on line. If it is determined by the TSM that a long time has passed since the period of validity expired or that the existing key pair of the corresponding chip is no longer valid due to an attack, etc., then the usage protocol and renewal protocol cannot be used on line and may be reissued from an issuance authority in a manner similar to that of the issuance protocol. Here, the reissuance protocol only omits the part for issuing an ID and otherwise may be practically the same as the issuance protocol. Also, since an issuance authority that is assumed to be safe would change the key and certificate, and since the existing key would no longer be valid, a signature may not be needed when transmitting a public key. In other words, in the renewal protocol, transmitting a public key newly created at the chip to the TSM may entail a transmission with a private key from before the change. The protocol of each step is described below in further detail with reference to the drawings.

Issuance Protocol

The flow shown in FIG. 3B represents the issuance protocol. Illustrated is a procedure for registering a public key from among the public key pair created at the device and being issued a certificate of authentication for the public key. The parts concerning creating and transmitting the public key pair and being issued a certificate of authentication would likewise be performed in the reissuance protocol.

First, the procedure of transmitting the chip and serial number list may be performed. A serial number list (SN-list) for valid devices may have been transmitted to the TSM from the manufacturer (3202).

{circle around (a)} Insert Chip (3201): An authentication chip or a device having the authentication chip inserted therein may be inserted into the issuing machine. Here, it is supposed that the issuing machine operated by the issuer (e.g. a bank or credit card company) is trustworthy.

{circle around (b)} Request SN: Then, the issuing machine may request and receive a SN from the chip.

{circle around (c)} Request ID: The issuing machine may request an ID for the corresponding chip from the TSM and transmit the SN received from the chip. The TSM may generate an ID (3203), check the received SN (3204), and then transmit its public key (QTSM) together with the ID to the issuing machine.

* Error Processing (when it is determined that the SN is not valid): If an invalid SN has been transmitted to the TSM, the above step can include responding with an error message (ERR_ID), disusing, and terminating, instead of transmitting the ID. Optionally, the issuing machine can again send a request to the chip for a valid SN and repeat the process from procedure {circle around (b)} onward.

{circle around (d)} Request Public Key: If there are no errors, then the issuing machine may request that the chip provide a public key and transmit the ID and public key of the TSM received from the TSM.

* Error Processing (CRC error): If there is a CRC error in the message received by the issuing machine from the TSM, then the ID request (REQ_ID, {circle around (c)}) may be sent again to receive the ID and public key of the TSM again.

{circle around (e)} Prepare Generation of Public Key: The chip may perform a CRC check (3206) and a validity check of the public key of the TSM (3207). Then, the update information (UpNumECC) that is to be used in generating the public key may be initialized (3208).

* Error Processing (CRC error): If the message received by the chip from the issuing machine includes a CRC error, then an error message (ERR_PUK) may be sent so that the ID and public key of the TSM may be received again.

* Error Processing (public key error): If the public key of the TSM (Q_TSM) received by the chip from the TSM is not valid, then an error message (ERR_PUK) may be sent as response to again request the public key of the TSM. The issuing machine may receive this and again request the ID from the TSM (REQ_ID, {circle around (c)}) to receive the ID and public key of the TSM again.

After the initialization (3208) in step 3209, the procedures in FIG. 3C may be performed. Procedures {circle around (f)} to {circle around (h)}, which are to be described in the following with reference to FIG. 3C, are parts that are common to the issuance and the reissuance and will be referred to as step 3209 when describing FIG. 3B, which relates to the issuance, and referred to as step 3508 when describing FIG. 3E, which relates to the reissuance. The procedures {circle around (f)} to {circle around (h)} described here will be referenced again for step 3508 of FIG. 3E described later on.

{circle around (f)} Generate and Transmit Public Key (3301): Based on the ID, PUF, and update information, a public key pair may be generated, from among which a public key may be transmitted to the issuing machine, and the issuing machine may transmit this to the TSM. It is supposed that this section is trustworthy, and a CRC code may be appended to preclude communication errors.

* Error Processing (CRC error): If a CRC error occurs in the message received from the chip by the issuing machine (3302), an error message (ERR_PUK) may be transmitted so that the public key of the chip may be received again. If the error is repeated, the chip can be disused (3303).

{circle around (g)} Issue Certificate of Authentication: The TSM may perform a CRC check (3304) and a validity check of the public key of the chip (3305). Then, the TSM may generate a certificate of authentication that includes the received public key by applying a signature based on its private key(3307) and may transmit the certificate to the issuing machine, and the issuing machine may transmit this to the chip. Incidentally, while the certificate of authentication is shown in FIGS. 3B to 3D as including the ID and public key of the chip and signatures therefor, the signed object and the content of the certificate can further include information such as the issuance authority, period of validity, etc., in addition to the ID and public key of the chip when necessary.

* Error Processing (CRC error): If a CRC error occurs in the message received from the issuing machine by the TSM, the TSM may respond to the issuing machine with a CRC error message (ERR_CERT) to request a retransmission.

* Error Processing (public key error): If the public key of the chip (Q_chip) received from the issuing machine by the TSM is not valid, an error message (ERR_CERT) may be sent to again request the public key of the chip. The issuing machine may receive this and transmit an error message (ERR_PUK) to the chip. If the error is repeated, the chip can be disused (3306).

* Error Processing (CRC error): If a CRC error occurs in the message received from the TSM by the issuing machine (3308), the issuing machine may respond to the TSM with a CRC error message (ERR_CERT).

{circle around (h)} Verify Certificate of Authentication: The chip may check the CRC (3309) and ascertain that the ID and public key included in the certificate of authentication are the same as its own. Also, the signature of the certificate of authentication for the ID and public key may be checked (3310). If the signature is confirmed, the update information (UpNumECC) and the certificate of authentication received from the TSM may be stored in the non-volatile memory (3313).

* Error Processing (CRC error): If a CRC error occurs in the message received from the issuing machine by the chip (3311), the chip may respond to the issuing machine with a CRC error message (ERR_REG_CERT) to request a retransmission. An error processing occurring after a retransmission can include disuse (3312).

* Error Processing (certificate error): If a certificate error (ID, public key, signature error) occurs, the chip may send a certificate error message (ERR_REG_CERT) to the issuing machine, and the issuing machine may send this to the TSM to again request a certificate of authentication (REQ_CERT), after which the procedures may be repeated.

The above parts are the FIG. 3C parts that are common to issuance and reissuance, and the process may return to immediately before the step 3210 for storing the ID and Q_TSM in FIG. 3B, which describes issuance procedures, so that step 3210 may be performed.

When the issuance is finished, each chip may have the issued ID and initialized update information (UpNum_ECC), the public key (Q_TSM) of the TSM, and the certificate of authentication of the TSM for its own public key (the public key of the chip signed with the private key of the TSM) in the non-volatile memory. After the issuance, the TSM may retain a SN-ID-public key list for the issued chips. It is assumed that the connections between the chips and issuers (issuing machines), TSM, and manufacturers are safe. That is, it is assumed that intervention by an attacker is impossible in the issuance stage.

Renewal Protocol

When power is turned on at a chip for which issuance was finished and the chip sends a request for use to the TSM, the TSM may check the period of validity of the chip for the corresponding ID, and if the period of validity has expired, then the use of the chip may not be permitted, and a request may be sent to the chip for renewing the public key.

As the communication environment is not safe, the newly created public key of the chip may be signed with the existing private key (the private key before the renewal) and transmitted so as to ensure that the new public key is from the corresponding chip.

The protocol is described in further detail with reference to FIG. 3D.

{circle around (a)} Request Checking of Period of Validity: The ID and a random number (RN) may be transmitted to the TSM (3401).

{circle around (b)} Check Period of Validity and Request Renewal: The TSM may check the period of validity (3402). If the period of validity has expired, then a renewal may be requested. In order to prevent an attack from arbitrarily renewing a device, the ID and the received random number as well as a renewal code (RENEWAL) may be signed with the private key of the TSM and added to the renewal request message.

{circle around (c)} Renew and Transmit Public Key Pair: The chip may check the ID and signature of the received renewal request message (3403 and 3404) and then generate a new public key pair (d′_Chip, Q′_Chip) by using UpNum_ECC incremented by 1 (3405). Then, a public key from the pair together with the ID may be signed with the private key from before the renewal (d_Chip) and transmitted to the TSM (3406).

* Error Processing (ID error): If the ID received from the TSM is not its own, the chip may respond with an error message (ERR_RENEWAL). The TSM may check the ID and, if the ID is correct, may repeat the process from the renewal request message (REQ_RENEWAL) onward.

* Error Processing (signature error): If the signature received by the chip from the TSM is not valid, then the chip may respond with an error message (ERR_RENEWAL). The TSM may retransmit an existing renewal request message (REQ_RENEWAL) or repeat the process from the generating of the signature onward.

{circle around (d)} Issue Certificate of Authentication: The TSM may perform a validity check of the public key of the chip and a validity check of the signature (3407 to 3409). Also, the TSM may generate a certificate of authentication that includes the received public key by applying a signature based on its private key and transmit the certificate to the chip. When regenerating a certificate of authentication, additional information other than the public key can also be appended as described above.

* Error Processing (public key error): If the public key of the chip (Q′_Chip) received from the chip by the TSM is not valid, an error message (ERR_RENEWAL) may be sent to again request the public key of the chip. * Error Processing (signature error): If the signature of the message received from the chip by the TSM is not valid, an error message (ERR_RENEWAL) may be sent to the chip to request a retransmission. The chip may repeat the process from the generating of the signature.

{circle around (e)} Verify Certificate of Authentication: The chip may check whether or not the ID and public key included in the certificate of authentication are the same as its own (3410). Also, the signature of the certificate of authentication for the ID and the public key may be checked (3411). If the signature is confirmed, then the UpNum_ECC and the certificate of authentication received from the TSM may be stored in the non-volatile memory (3413).

* Error Processing (certificate error): In the event of a certificate error (ID, public key, signature error), a possible option can be to disuse (3412), but alternatively, the chip can send a certificate error message (ERR_REG_CERT) to the TSM to again request the certificate of authentication and repeat the procedures. When the renewal is finished, the chip may retain the UpNum_ECC incremented by 1, used in renewing the public key, and the certificate of authentication of the TSM for the newly renewed public key, in the non-volatile memory. Then, step 3414 and step 3415 may be performed to complete the renewal protocol.

Reissuance Protocol

During renewal, the new public key was signed with the existing private key to ensure that the new public key belongs to the chip. However, in cases where a long time has passed since the period of validity was expired, the existing private key may no longer be usable, and therefore, the chip may have to be reissued at the issuance authority. The details of the protocol may be as follows.

{circle around (a)} Request Checking of Period of Validity: After the card is inserted (3501), it may be unknown if the chip is in a reissued state, and thus similar to the case of renewal, a command to generate an ID and a random number (RN) (3502) and transmit them together may be transmitted to the issuing machine. The issuing machine may receive this and send a request for a reissuance command to the TSM.

{circle around (b)} Request Reissuance: In a manner similar to that of the renewal request, the TSM may apply a signature with the private key of the TSM to the ID, the received random number, and a reissuance code (ISSUE) (3503) and may add these to a reissuance request message.

{circle around (c)} Check Reissuance Request: The chip may check the CRC, ID, and signature (3504 to 3506) and increment UpNum_ECC by 1 (3507).

* Error Processing (CRC error): If the message received from the issuing machine by the chip includes a CRC error, an error message (ERR_REPUK) may be transmitted to receive the ID and signature again.

* Error Processing (ID error): If the ID received from the TSM by the chip is not its own, the chip may respond with an error message (ERR_REPUK). The TSM may check the ID and, if it is correct, may repeat the procedures from the reissuance request message (REQ_REPUK) onward.

* Error Processing (signature error): If the signature received from the TSM by the chip is not valid, the chip may respond with an error message (ERR_REPUK). The TSM may retransmit the existing renewal request message (REQ_REPUK) or repeat the procedures from the generating of the signature onward.

Then, the procedures {circle around (f)} to {circle around (h)} of the issuance protocol described above with reference to FIG. 3C may be repeated here.

{circle around (d)} (procedure {circle around (f)} of issuance) Generate and Transmit Public Key (3301):

Based on the ID, PUF, and update information, a public key pair may be generated, from among which a public key may be transmitted to the issuing machine, and the issuing machine may transmit this to the TSM. It is supposed that this section is trustworthy, and a CRC code may be appended to preclude communication errors. * Error Processing (CRC error): If a CRC error occurs in the message received from the chip by the issuing machine (3302), an error message (ERR_PUK) may be transmitted so that the public key of the chip may be received again. If the error is repeated, the chip can be disused (3303).

{circle around (e)} (procedure {circle around (g)} of issuance) Issue Certificate of Authentication: The TSM may perform a CRC check (3304) and a validity check of the public key of the chip (3305).

Then, the TSM may generate a certificate of authentication that includes the received public key by applying a signature based on its private key(3307) and may transmit the certificate to the issuing machine, and the issuing machine may transmit this to the chip. Similar to the case of issuance, this case can also have various additional information (e.g. issuance authority, period of validity) included together as necessary.

* Error Processing (CRC error): If a CRC error occurs in the message received from the issuing machine by the TSM, the TSM may respond to the issuing machine with a CRC error message (ERR_CERT) to request a retransmission.

* Error Processing (public key error): If the public key of the chip (Q_Chip) received from the issuing machine by the TSM is not valid, an error message (ERR_CERT) may be sent to again request the public key of the chip. The issuing machine may receive this and transmit an error message (ERR_PUK) to the chip. If the error is repeated, the chip can be disused (3306).

* Error Processing (CRC error): If a CRC error occurs in the message received from the TSM by the issuing machine (3308), the issuing machine may respond to the TSM with a CRC error message (ERR_CERT).

{circle around (f)} (procedure {circle around (h)}of issuance) Verify Certificate of Authentication: The chip may check the CRC (3309) and ascertain that the ID and public key included in the certificate of authentication are the same as its own. Also, the signature of the certificate of authentication for the ID and public key may be checked (3310). If the signature is confirmed, the UpNum_ECC and the new certificate of authentication received from the TSM may be stored in the non-volatile memory (3313).

* Error Processing (CRC error): If a CRC error occurs in the message received from the issuing machine by the chip (3311), the chip may respond to the issuing machine with a CRC error message (ERR_REG_CERT) to request a retransmission. An error processing occurring after a retransmission can include disuse (3312).

* Error Processing (certificate error): If a certificate error (ID, public key, signature error) occurs, the chip may send a certificate error message (ERR_REG_CERT) to the issuing machine, and the issuing machine may send this to the TSM to again request a certificate of authentication (REQ_CERT), after which the procedures may be repeated. These parts correspond to procedures {circle around (f)} to {circle around (h)} of the issuance process described above with reference to FIG. 3C. After these parts are performed, the process may return again to the final step of FIG. 3E. As a result of the reissuance, UpNum_ECC incremented by 1 and the newly issued certificate of authentication (R′, S′) may be stored anew (3507). Similar to the issuance protocol, it is assumed that any intervention by an attacker is impossible in the issuance step.

Usage Protocol

The descriptions are provided with reference to FIG. 3F. The usage protocol may be a protocol for performing mutual authentication with the TSM to confer upon the core the authority needed for the secure mode. It is an example of a protocol performing the authentication process described in FIG. 3A.

{circle around (a)} Request Checking of Period of Validity: Similarly to the renewal and reissuance protocols, the ID and a random number (RN) may be generated (3601) and transferred to the TSM when the protocol begins.

{circle around (b)} Check Period of Validity and Request Session: The TSM may check the period of validity (3602). If the period of validity has not expired, a temporary key pair (a, A) may be generated with an ECDH procedure for sharing a key with the chip. Then, this may be signed with the private key of the TSM and transmitted to the chip.

{circle around (c)} Generate Shared Key: The chip may check the received ID (3603) and may check the validity of the received public key (A) and check the validity of the signature (3604 and 3605). Then, a temporary key pair (b, B) of the key may be generated with an ECDH procedure. Also, by using the temporary public key (A) received from the TSM and the temporary private key (b) generated by the chip, shared secret information (W) may be created, and this may be expanded with a key derivation function to generate shared secret keys (K1, K2, IV) (3606).

The public key generated above, the signature applied thereto with the private key of the chip, and information (C₁) encrypted with the shared secret keys for a handshake may be transmitted to the TSM (3607 to 3608).

* Error Processing (ID error): If the ID received from the TSM by the chip is not its own, an error message (ERR_SESSION) may be sent. The TSM may check the ID and, if correct, may repeat the procedures from the session request message (REQ_SESSION) onward.

* Error Processing (public key error): If the public key received from the TSM by the chip is not valid, an error message (ERR_SESSION) may be sent. The TSM may repeat the procedures from the session request message (REQ_SESSION) onward.

* Error Processing (signature error): If the signature received from the TSM by the chip is not valid, an error message (ERR_SESSION) may be sent. The TSM may generate the signature again or repeat the procedures from the session request message (REQ_SESSION) onward.

{circle around (d)} Handshake: The TSM may check the validity of the received public key (B) and the validity of the signature (3609 and 3610). Also, by using the received public key (B) of the chip and the temporary private key (a) generated at the TSM, shared secret information (W) may be created, and this may be expanded with a key derivation function to generate shared secret keys (K1, K2, IV) (3611). By using this to decrypt C₁, it may be confirmed that the chip has generated the same shared secret keys. The TSM may also transmit information (C₂) encrypted with the shared secret keys to the chip (3612).

* Error Processing (public key error): If the public key received from the chip by the TSM is not valid, an error message (ERR_HS) may be sent. The chip may repeat the procedures from the handshake request message (REQ_HS) onward.

* Error Processing (signature error): If the signature received from the chip by the TSM is not valid, an error message (ERR_HS) may be sent. The chip may generate the signature again or repeat the procedures from the handshake request message (REQ_HS) onward. If the signature error is repeated, the handshake process may be halted, and an error message (ERR_HS) for authentication failure may be sent together with an authentication failure code (ER_AUTH) to set the authentication result to failure (F_Auth=False).

* Error Processing (handshake error): If the TSM's checking of the Ci received from the chip results in failure, an error message (ERR_HS) may be sent. The procedures may be performed again from the generating of the secret keys or from the generating of C₁ onward.

{circle around (e)} Handshake 2: The chip may decrypt and check the received C₂ to confirm that the TSM has generated the same secret keys (3613).

* Error Processing (handshake error): If the chip's checking of the C₂ received from the TSM results in failure, an error message (ERR_HS) may be sent. The procedures may be performed again from the generating of the secret keys or from the generating of C₂ onward.

The signatures exchanged by each other in the procedures above can be used to authenticate each other, and the shared secret keys (K1, K2, IV) may be utilized later when communicating with the TSM as an encryption key, a key for a MAC, and an initial vector, respectively. If the authentication has been performed successfully, the authority for the secure mode may be conferred (F_Auth=True) (3614).

The above describes the specific protocols for pre-authentication, issuance, renewal, reissuance, and use. By way of these procedures, the pre-authentication authentication part may authenticate hardware ranging from the machine to the TSM.

Software Authentication of Hardware

To ensure the integrity of the platform in a TEE (trusted execution environment) such as the existing TrustZone, etc., a secure booting function may be included. This is to avoid having the system start with the OS image system itself corrupted and may entail checking the integrity of the OS image at the time of booting so that the platform may be started in a faultless state.

FIG. 4 is a flow diagram for describing the flow of such secure booting according to an embodiment of the invention. When the device is powered on (410), the SoC bootloader 420 of the ROM may first be executed and given authority. Since the bootloader is stored in the on-SoC ROM and is impervious to modifications, it may serve as the root of trust and be used as the foundation for the secure booting process. Also, the on-SoC hardware may have the public key of the TSM authentication authority in the form of an OTP, etc., that is impossible to modify. The bootloader 420 may use this public key to verify the signature of the flash device bootloader 430 and thus confirm its integrity, after which authority may be conferred on the flash device bootloader 430 to allow executions. The flash device bootloader 430, having been conferred authority, may verify the signature of the image of the secure world OS to check the integrity and execute the same (for secure booting) (440). This procedure may be repeated at a subsequent step, such that the normal world bootloader 450 is conferred authority to boot the normal world OS (460), whereby the system may be operated. Such a process of performing software authentication step by step from the root of trust at the hardware level where modification is impossible and integrity is guaranteed may be referred to as a chain of trust.

In this way, the hardware may use the chain of trust to authenticate the software that is to be executed on the hardware, and as described with reference to FIGS. 3A to 3F, the software may also authenticate the hardware, resulting in mutual authentication.

Increasing Security using a PUF A PUF (physical unclonable function) according to an embodiment of the invention can generate a true random bit unique to the chip by using process variation resulting from the semiconductor manufacturing procedure. Since the process variation resulting from the semiconductor manufacturing procedure is different for each chip, the PUF can be utilized as a unique ID of the chip in mass production of chips, and this can provide a root key that may be utilized in encryption/decryption, memory protection, electronic signature, etc.

The value of such PUF is not easily leaked to the outside and thus can provide the highest level of security as a root of trust. Currently, there are standardization and commercialization efforts under way for using the PUF for security purposes in various applications including military weapons such as intercontinental ballistic missiles (ICBM), etc., vehicle security systems (HSM), AP's for smart phones, smart cards, and others.

FIG. 5 is a conceptual diagram for describing the implementation of a PUF according to an embodiment of the invention. It should be noted that this is merely an example implementation and that the invention is not limited thereto. According to an embodiment of the invention, the PUF may have a via (or interlayer contact) array that is manufactured by designing the via holes to have sizes smaller than the via hole size specified in common design rules (in the illustrated example, the size is 250 nm*250 nm). In this case, open and shorted via holes are randomly distributed in the via hole array, and this setup can provide digital values that are random and substantially invariant over time. A VIA PUF manufactured according to the embodiment presented above has passed various tests based on the JEDEC standard as applied by official assessment agencies, proving its reliability, and has also passed the randomness test applied with the true random number testing suite based on the NIST standard of SP 800-90B.

Description of Additional Embodiment

FIG. 6 illustrates a secure SoC platform that is fundamentally protected from physical attacks according to an embodiment of the invention.

A hidden bus 620 may be provided for the secure world in addition to the normal bus 610 that performs computing in the REE environment connected to the secure core 601. When the SRAM 611 or the peripheral IP' s 612 require activating the secure mode during operation, secure IP' s 621 can be operated at the command level via a secure ISA.

According to an embodiment of the invention, the secure core 601 may partition the memory area into a code area and a data area. While the partitioned memory area can be that of the normal world, it can also be of the secure world in another embodiment. The secure core 601 can include a memory protection unit (MPU) that prohibits writing in the code area and prohibits execution in the data area. Here, the code area and the data area can be configured by secure instructions that are processed using commands associated with the ASR of the Core-A processor. Furthermore, the system area can also be configured in addition to the code area and the data area.

	TABLE 1
	Mode
	Area	U/N	U/S	P/N	P/S
	Code Area	RX	RX	RWX	RWX
	Data Area	RW	RW	RW	RW
	System Area	—	—	RWX	RWX

In the table above, mode “U” represents a user mode, and “P” represents a privilege mode. Also, “N” represents the normal mode, and “S” represents the secure mode. The actions permitted for each code area are listed. For example, in the user mode and normal mode, reading marked as R and execution marked as X are permitted, but writing W is not permitted.

According to an embodiment of the invention, the processor core can include a hardware-based shadow stack that makes a backup of the return address included in the code sequence. In this case, the shadow stack can be located in the same or a separately added memory as the stack residing in the existing memory or in a separately added register, etc. The shadow stack may not use a bus, may not be accessed by the OS or software, and may be automatically executed when a command related to a memory stack is executed by the added hardware-based control circuit, thereby dually managing the return address. Due to the dual management of the return address using a shadow stack, any changes made by a software attack to the return address stored in the stack residing in the existing memory can be detected. Since the shadow stack may be controlled only with a hardware circuit and cannot be accessed by software, any attack attempting to change the contents stored in the shadow stack can be fundamentally avoided. The shadow stack described above is an example of dually managing the return address, and the invention is not limited to a particular exemplary implementation as long as the stack enables dual management by periodically backing up the return address.

Operation during System Booting

FIG. 7 and FIG. 8 are flow diagrams for describing the operation of a SoC according to an embodiment of the invention. According to an embodiment of the invention, a procedure of receiving authentication by a certificate server may be performed when the device is powered on (710). Here, the details of how a hardware-based authentication part, i.e. the pre-authentication IP, may communicate with an outside certificate server for mutual authentication between end nodes are as described above with reference to FIG. 3A, and a description of how a PUF may be used in this process is provided above with reference to FIG. 5.

If the authentication is successful in step 720, then the secure ISA may be made available (730), and access to the debugging port may be permitted and the secure world OS may be booted (740). Then, normal mode booting may be performed to render the system operable (750).

However, if the authentication fails in step 720, then in step 810 of FIG. 8, the secure world may be made inaccessible. Only the normal world may be booted, so that computing operations only in the REE environment are permitted. The relevant procedures are as described above with reference to FIG. 1, FIG. 2, FIG. 4, etc.

The device described above can be implemented as one or more hardware components for a memory, one or more software components for controlling the memory, and/or one or more combinations of hardware components and software components. For example, the device and components in the embodiments described above can be implemented by using one or more general purpose computer or special purpose computer, which may include, for example, a processor, a controller, an ALU (arithmetic logic unit), a digital signal processor, a microcomputer, a FPA (field programmable array), a PLU (programmable logic unit), a microprocessor, or any other device capable of executing and responding to instructions.

The software can include a computer program, code, instructions, or a combination of one or more of the above to configure a processing device to operate as desired or command a processing device independently or collectively. The software and/or data can be permanently or temporarily embodied as a type of machinery, component, physical device, virtual equipment, computer storage medium or device, or transmitted signal wave to be interpreted by a processing device or to provide instructions or data to a processing device. The software can also be distributed over computer systems connected over a network and can be stored or executed in a distributed manner. The software and data can be stored on one or more computer-readable recorded medium.

A method of controlling memory operation according to an embodiment of the invention can be implemented in the form of program instructions that may be performed using various computer means and can be recorded in a computer-readable medium. Such a computer-readable medium can include program instructions, data files, data structures, etc., alone or in combination. The program instructions recorded on the medium can be designed and configured specifically for the embodiment or can be a type known to and used by the skilled person in the field of computer software. A computer-readable medium may include a hardware device that is specially configured to store and execute program instructions. Some examples may include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROM's and DVD's, magneto-optical media such as floptical disks, and hardware devices such as ROM, RAM, flash memory, etc. Examples of the program of instructions may include not only machine language codes produced by a compiler but also high-level language codes that can be executed by a computer through the use of an interpreter, etc. The hardware mentioned above can be made to operate as one or more software modules that perform the actions of the embodiments, and vice versa.

While the embodiments of the invention are described above with reference to a limited number of drawings, a person having ordinary skill in the relevant field of technology would be able to derive various modifications and alterations from the disclosure provided above. A satisfactory result may be achieved, for example, by performing the procedures described above in an order different from that of a method described above and/or by coupling or combining components of the above-mentioned systems, structures, devices, circuits, etc., in a form different from that described above or replacing or substituting certain components with other components or equivalents. Therefore, other implementations, other embodiments, and equivalents of the claims set forth below are encompassed within the scope of claims.

Claims

1. A semiconductor chip comprising: a processor core; andan authentication part configured to perform mutual authentication with an outside trusted authority to perform authentication between the semiconductor chip and the outside trusted authority.

2. The semiconductor chip of claim 1, further comprising: a first group comprising elements connected to the processor core by a first bus; anda second group comprising elements connected to the processor core by a second bus and configured to operate in a secure mode.

3. The semiconductor chip of claim 2, wherein the second group is activated to be usable only if the authentication part successfully performs the authentication.

4. The semiconductor chip of claim 2, wherein the second group includes at least one of a cryptographic IP, a secure SRAM, a secure DMA, and a boot ROM.

5. The semiconductor chip of claim 1, further comprising: a PUF configured to provide a key used by the authentication part for the mutual authentication with the outside trusted authority.

6. The semiconductor chip of claim 2, wherein the second group processes data by using a memory address different from that of the first group.

7. The semiconductor chip of claim 2, wherein the processor core comprises a Core-A processor, the Core-A processor being a 32-bit RISC (reduced instruction set computing) type embedded processor.

8. The semiconductor chip of claim 7, wherein the second bus comprises a hidden bus implemented by using an ASR (application specific register) of the Core-A processor as an address space for controlling elements included in the second group.

9. The semiconductor chip of claim 8, wherein the second group uses an MTA (move to ASR) command and an MFA (move from ASR) command in the secure mode for processing secure instructions, the MTA command and the MFA command being commands for processing data in relation to the ASR.

10. The semiconductor chip of claim 1, wherein the authentication part is a hardware logic and is operated in an independent language different from existing computing language to perform the authentication procedure.

11. The semiconductor chip of claim 10, wherein the authentication part performs an authentication procedure configured in an independent language different from existing computing language.

12. The semiconductor chip of claim 11, wherein the authentication part is configured with a general cell unlike an IP within the semiconductor chip or ROM.

13. A hardware device having software embedded therein, the hardware device comprising: a processor core configured to operate the software; andan authentication part configured to perform mutual authentication with an outside trusted authority to perform authentication between the semiconductor chip and the outside trusted authority for operating the software by the hardware device.

14. The hardware device of claim 13, wherein the semiconductor chip further comprises: a first bus connecting a first group to the processor core, the first group comprising elements configured to operate in a normal mode; anda second bus connecting a second group to the processor core, the second group comprising elements configured to operate in a secure mode.

15. The hardware device of claim 14, wherein access to the second bus is activated such that the second group is usable only if the authentication part successfully performs the authentication.

16. The hardware device of claim 13, further comprising: a PUF configured to provide a key used by the authentication part for the mutual authentication with the outside trusted authority.

17. An operation method for a semiconductor chip, the operation method comprising: performing mutual authentication with an outside trusted authority, the performing of the mutual authentication performed by an authentication part; andactivating a secure mode of the semiconductor chip if the authentication is successful.

18. The operation method of claim 17, wherein the semiconductor chip further comprises a first bus connecting a first group to the processor core and a second bus connecting a second group to the processor core, the first group comprising elements configured to operate in a normal mode, the second group comprising elements configured to operate in a secure mode, and the method comprises: activating the second group and the second bus if the authentication is successful, and deactivating the second group and the second bus and activating the first group and the first bus if the authentication is not successful.

19. The operation method of claim 18, wherein the second group includes at least one of a cryptographic IP, a secure SRAM, a secure DMA, and a boot ROM.