WO2017138799A1 - 하드웨어 디바이스 및 그 인증 방법 - Google Patents

하드웨어 디바이스 및 그 인증 방법 Download PDF

Info

Publication number
WO2017138799A1
WO2017138799A1 PCT/KR2017/001560 KR2017001560W WO2017138799A1 WO 2017138799 A1 WO2017138799 A1 WO 2017138799A1 KR 2017001560 W KR2017001560 W KR 2017001560W WO 2017138799 A1 WO2017138799 A1 WO 2017138799A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
group
secure
semiconductor chip
bus
Prior art date
Application number
PCT/KR2017/001560
Other languages
English (en)
French (fr)
Inventor
김동규
김지훈
Original Assignee
한양대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한양대학교 산학협력단 filed Critical 한양대학교 산학협력단
Priority to CN201780010962.7A priority Critical patent/CN108604275A/zh
Priority to US16/075,951 priority patent/US20190253417A1/en
Priority claimed from KR1020170019497A external-priority patent/KR20170095163A/ko
Publication of WO2017138799A1 publication Critical patent/WO2017138799A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • It relates to hardware and its authentication method, and more particularly to a method of authenticating whether a hardware device such as a semiconductor chip or electronic equipment is genuine, not tampered with or damaged.
  • Hardware-based security technologies such as TrustZone technology, verify and read the integrity of the OS image at boot time, ensuring that the platform integrity is staff-by-staff from system startup. This is how hardware verifies the integrity of software, including the operating system. However, it does not verify the integrity of the hardware at the software point of view.
  • An object of the present invention is to provide a hardware device and a method for authenticating the hardware device.
  • a semiconductor chip comprising: a processor core; And an authentication unit performing mutual authentication with an external trust authority to perform authentication between the semiconductor chip and the external trust authority.
  • a semiconductor chip may include: a first group including elements connected to the processor core via a first bus; And a second group coupled to the processor core via a second bus, the second group including elements operating in a secure mode.
  • the authentication unit activates the use of the second group only when the authentication succeeds.
  • the second group includes at least one of Cryptographic IP, secure SRAM, secure DMA, and boot ROM.
  • the semiconductor chip may further include a PUF that provides a key used by the authentication unit to perform the mutual authentication with the external trust authority.
  • the second group processes data using a memory address different from that of the first group.
  • the processor core includes a Core-A processor, which is an embedded processor of the 32-bit Reduced Instruction Set Computing (RISC) type.
  • the second bus includes a hidden bus implemented using the Application Specific Register (ASR) of the Core-A processor as an address space for controlling elements included in the second group.
  • ASR Application Specific Register
  • the second group may use a Move to ASR (MTA) command and a Move from ASR (MFA) command, which are data processing commands for the ASR, in the secure mode.
  • MTA Move to ASR
  • MFA Move from ASR
  • the processor core may be a RISC V ISA applied CPU core.
  • the authentication unit is hardware logic and is driven in a different language from the existing computing language to perform the authentication procedure.
  • the authentication unit may perform an authentication procedure that is configured in a unique language different from the existing computing language.
  • the authentication unit is configured as a general cell so that the authentication unit is not exposed to the outside or securely attacked during a place and route (PnR).
  • a hardware device embedded in the software comprising: a processor core for driving the software; And an authentication unit configured to perform mutual authentication with an external trust authority to perform the authentication between the semiconductor chip and the external trust authority to drive the software through the hardware device.
  • the apparatus comprises: a first bus connecting a first group comprising elements operating in a normal mode to the processor core; And a second bus connecting the processor core to a second group including elements operating in a secure mode.
  • access to the second bus is activated so that the second group is available only when the authenticator succeeds in the authentication.
  • the apparatus may further include a PUF providing a key used by the authentication unit to perform the mutual authentication with the external trust authority.
  • a method of operating a semiconductor chip comprising: authenticating, by an authenticator, mutual authentication with an external trust authority; And activating a security mode of the semiconductor chip if the authentication succeeds.
  • the semiconductor chip may include a first bus connecting a first group including elements operating in a normal mode to the processor core; And a second bus connecting the processor core to a second group including elements operating in a secure mode.
  • the method activates the second group and the second bus if the authentication succeeds, deactivates the second group and the second bus if the authentication fails and the first group and The first bus may be activated.
  • the second group includes at least one of Cryptographic IP, secure SRAM, secure DMA, and boot ROM.
  • a hardware device can be authenticated.
  • FIG. 1 is a block diagram of an SoC device according to an embodiment.
  • FIG. 2 illustrates a structure of implementing an SoC according to an embodiment.
  • 3A to 3F illustrate a process and a protocol for performing pre-authentication according to an embodiment.
  • FIG. 4 is a flowchart illustrating a flow of secure booting according to an embodiment.
  • FIG. 5 is a schematic diagram illustrating an implementation of a PUF according to an embodiment.
  • FIG. 6 illustrates a secure SoC platform that is inherently protected from physical attack in accordance with one embodiment.
  • FIG. 7 through 8 are flowcharts of performing a secure boot, according to an exemplary embodiment.
  • the hardware-based security technology such as secure booting
  • secure booting is a technology in which hardware verifies software integrity. If the operating system of the smartphone or handheld device is found to be a corrupted image or a security function tampered with, such as a hack, instead of a flawless image, the hardware will detect it at the boot stage and / or at the enforcement stage of a particular application. To prevent security risks.
  • a mobile banking or payment application on a smartphone with an OS tampered with by a hacker, it is now common to verify that the OS is not a hacked OS and stop the process.
  • a hardware and software mutual authentication technique is described as an example in a system on a chip level device, but is not necessarily limited to this example.
  • mutual authentication of hardware and OS or firmware of handheld equipment and further mutual authentication of automobiles, aircraft and its operating software.
  • SoCs attacks on SoCs include physical attacks and software attacks. If physical attacks are neutralized and the software system is protected by a secure SoC platform, developers can focus on their work without worrying about security issues.
  • the embodiments presented herein provide a SoC platform that operates in a secure environment by preventing security attacks on software.
  • the chip includes a processor core 101.
  • the first bus 111 and the second bus 121 are separately connected to the core 101.
  • the first bus 111 is provided to the first group 112, which is a general purpose computing group operating in normal mode.
  • a 'group' can be understood as a collection of individual computing assets (IP), memory, cache, etc.
  • IP computing assets
  • the second bus 121 is provided to a second group 122 that includes elements that operate only in secure mode.
  • the second bus 121 is physically completely separated from the first bus 111. This physical isolation can make a distinction between normal world (110) and secure world (120), which provides a SoC that is robust against security attacks on software. Physical isolation may also be understood that the first group 112 of normal world 110 processes data with a completely different memory address scheme than the second group 122 of secure world 120.
  • the SoC 100 includes an authentication unit 102 that performs mutual authentication with an external certification authority (not shown) for the secure world 120 when a secure mode needs to be executed at system power-on and / or as needed. May be included.
  • the authenticator 102 may prove to the external certification authority that the SoC 100, the second group 122, and their respective IPs, and further the software embedded therein, are legitimate and intact.
  • the authenticator 102 also mutually authenticates that the external certification authority that the external terminal that is the subject of the current transaction is trusted is correct.
  • the authentication unit 102 receives and registers a public key from a pre-authentication external certification authority, and sees FIG. 3 for hardware authentication of the software such as an issuing protocol for obtaining a certificate and replacing an existing public key with a new public key as necessary. It will be described later in detail.
  • the SoC 100 may have a normal mode and a secure mode. Only when the authentication of the authentication unit 102 described above is successful, the second group 122 is booted and the secure world 120 associated with a trusted execution environment (TEE) is activated. Of course, in this case, the first group 112 is also booted and the normal world 110 is activated. However, if the authentication is not performed, only the first group 112 associated with a Rich Execution Environment (REE) is booted so that the normal world 110 is activated but the secure world 120 is not activated.
  • TEE trusted execution environment
  • the second group 122 may not always operate and may be in a standby state.
  • the security mode when there is a call to which an elevated security handling must be handled for computing a REE environment, such as while an Android operating system and an application are running, for example, an event of secure violation or a financial settlement is required. Can be performed.
  • Rich Execution Environment like Android on mobile phones, runs on ARM-based SoCs along with common hardware IPs.
  • a secure resource such as Cryptographic IP or secure SRAM, is required, a TEE of the secure OS and the secure hardware IP is activated to send the result to the REE.
  • ARM's TrustZone is a control signal for accessing the SoC platform's secure IP, providing an additional 1-bit bus signal to AMBA AXI.
  • IoT Internet of Things
  • RTOS Real Time OS
  • the semiconductor SoC 100 may include a physical unclonable function (PUF) 103 that provides a root key used by the authenticator 102 to perform mutual authentication with the external trust authority. It may further include. At least one of various authentication algorithms such as RSA and AES using such a source key may be used for the authentication.
  • PUF may be included intrinsic into the semiconductor chip using process variations in the semiconductor manufacturing process. In one exemplary implementation, the PUF may be to provide a digital value depending on whether vias or inter-layer contacts that are layered between the conductive layers of the semiconductor are normally patterned in the process to short between the conductive layers. . The implementation and role of the PUF will be described later in more detail with reference to FIGS. 5 and 6.
  • the secure memory 130 includes an area utilized in a normal mode and an area utilized in a security mode.
  • Secure memory 130 illustratively includes non-volatile memory (NVM).
  • NVM non-volatile memory
  • the area utilized in the security mode may be encrypted and stored using the source key provided by the PUF 103 without storing the data as it is. Therefore, even if the data of the secure memory 130 is physically extracted, this is meaningless unless it is directly wired with the PUF 103 and decrypted.
  • the processor core includes a Core-A processor 201, which is an embedded processor of the 32-bit Reduced Instruction Set Computing (RISC) type.
  • the processor core may be a CPU core to which RISC V ISA is applied.
  • RISC Reduced Instruction Set Computing
  • the terms 'processor', 'processor core', 'secure core', 'secure processor' and the like should be understood as terms that may be interchanged with each other in some cases.
  • the description using 'Core-A' is mainly described. However, it is obvious to those skilled in the art that other types of implementations, such as CPU cores using RISC V ISA, are possible.
  • the first group elements of the REE environment, the SRAM 211, the Peripheral IPs 212, and the debugging port 213 are connected to the general bus 210.
  • the secure bus 220 is connected to Cryptographic IPs 221, a boot ROM 222, a secure SRAM 223, and a secure DMA 224 that must operate in a TEE environment.
  • an authentication unit 202 and at least one PUF 203 may exist to perform authentication.
  • the PUFs 203 are directly connected to the core 201 for authentication, and may also be directly connected to AES / SEED IP and ECC / RSA IP among Cryptographic IPs.
  • the secure NVM 230 is also directly connected to the PUF 203 so that data can be encrypted and stored securely.
  • the secure bus 220 may be a hidden bus implemented by using an application specific register (ASR) of the Core-A processor as an address space for controlling second group elements of the secure world.
  • ASR application specific register
  • the second group may use a Move to ASR (MTA) instruction and a Move from ASR (MFA) instruction, which are data processing instructions for the ASR, in the secure mode for secure instruction processing.
  • MTA Move to ASR
  • MFA Move from ASR
  • This may also be understood to implement a hidden bus for secure IPs included in the second group using the ASR interface.
  • a secure ISA (Secure Instruction Set Architecture) is implemented that can directly support TEE instead of a secure OS or a library with a large overhead. This makes it suitable for devices with small CPUs compared to using ARM's TrustZone.
  • pre-authentication hardware which is an authenticator, is provided for security mode management and hardware and software mutual authentication that are distinct from the normal mode.
  • cross-authentication hardware IPs using VIA-Physical Unclonable Function (VIA-PUF) have already been verified for reliability, stability, and randomness, providing a secure SoC platform with an enhanced secure world.
  • a security ISA is presented. Unlike normal ISA, it is a secure world version of ISA. In order to access resources in the secure world in accordance with existing ARM TrustZone technology, a secure OS or complex libraries are required. However, in the proposed embodiment, the resources in the secure world can be directly accessed at the instruction level based on the security ISA.
  • secure mode management for secure ISA using Pre-authentication IP enables secure mutual authentication and prevents unauthorized access to internal users, such as software attacks.
  • the proposed security core provides a hidden passage to the secure world, which is physically separate from the main memory interface.
  • secure DMA is used to automatically check the integrity of the hardware when loading software.
  • the internal PUF provides a key for secure storage or secure IPs for authentication.
  • a secure OS or library is required to run on a general purpose CPU core.
  • the embodiment presents a security ISA without the overhead while providing the requirements of the secure world and the features of the secure OS and libraries, which extends the core-A functionally. This allows the security system to directly access TrustZone without the aid of a secure OS or library, or the difficulty of developing applications, and reduces administrative effort.
  • Exemplary features of a security ISA in accordance with an embodiment are as follows.
  • Control flow integrity replace code that protects the control flow integrity with a single command for efficiency
  • Key management includes generation of random numbers and key pairs for public key cryptography
  • Memory security level management Provides various security levels for each page and segment
  • Security Engine ISA extensions that work closely with the security hardware engine.
  • Security Mode Management Supports microstructure management for security mode
  • Register Content Protection Encrypt the contents of the secure register with VIA-PUF
  • 3A to 3F illustrate a process and a protocol for performing pre-authentication according to an embodiment.
  • the security ISA can be used by the Terminal Security Management (TSM) system, which manages the security of an external certificate server, such as a terminal in a commercial network, through end-to-end mutual authentication when the pre-authentication IP (301) is powered on or reset.
  • TSM Terminal Security Management
  • mutual authentication may be by public key cryptography using a source key generated by the PUF 303.
  • the authentication protocol in the pre-authentication IP 301 used for mutual authentication is not a general language (for example, a high-level language such as C or an assembly language for a specific core). Since the pre-authentication IP 301 is implemented in a dedicated language designed only for the performance of the authentication protocol, the analysis is difficult and practically impossible. In addition, since the pre-authentication IP 301 is implemented as hardware logic, not only can not be modified (guaranteed integrity), but also a combination of basic cells, not physically separated IP types such as ROM, can be implemented in a place and route (PnR) process. It can be blended with other cells, making it robust against physical attacks such as reverse engineering.
  • PnR place and route
  • the server 301 and the proposed platform 300 generate a signature with their own private key, and their public key is included in the certificate.
  • Mutual authentication is performed by exchanging a signature with a certificate.
  • the pre-authentication IP 302 obtains the private key from the VIA-PUF 303 and passes the generated signature to the certificate server.
  • the received signature is verified with the public key of the stored external certificate server.
  • the signature algorithm is a public key cryptographic algorithm and may be ECC or RSA.
  • the system enters secure mode and the secure core controls secure booting.
  • the debugging port opens only in secure mode so that only authorized users can debug. If authentication succeeds, the secure mode may be granted, and IP resources 311 and 312 of the secure world may operate.
  • the shared key exchanged in mutual authentication is used as an encryption key or a message authentication code (MAC) key, and an IV (Initial Vector) used for encryption or MAC for future security purposes. Can be used for securing.
  • MAC message authentication code
  • IV Initial Vector
  • Pre-authentication protocol is a 'issuance protocol' that registers a public key and issues a certificate before use, and a 'reissue and renewal' that can replace an existing public key with a new public key and reissue a certificate for a new public key as needed.
  • TSM terminal security management
  • the issuing authority may not Must be reissued in such a way.
  • the reissuance protocol is almost identical to the issuance protocol except for the issue of the ID.
  • the existing key is no longer valid, so no signature is required when the public key is delivered.
  • the update protocol when a chip newly generated public key is delivered to TSM, it is signed with the private key before change. The protocol of each step is demonstrated in detail, referring drawings.
  • the flow shown in FIG. 3B presents an issuance protocol.
  • Public key pair generation, transfer and certificate issuance will be performed in the reissue protocol.
  • a serial number list (SN-list) for valid devices is passed from the manufacturer to the TSM (3202).
  • a Chip Insertion 3201 An authentication chip or a device in which an authentication chip is inserted is inserted into the issuing device. At this time, the issuing device operated by the issuer (for example, a bank or credit card company) is considered to be trusted.
  • the issuer for example, a bank or credit card company
  • B SN request The issuing device then sends a request for SN to the chip.
  • the issuing device sends the SN received from the chip, requesting the ID for the chip from TSM.
  • the TSM generates an ID 3203, and transmits its public key (Q TSM ) to the issuing device along with the ID after confirming the received SN 3204.
  • Error handling (if it is determined to be an invalid SN): If an invalid SN is passed to the TSM, instead of passing an ID in this step, it may respond with an error message (ERR_ID), discard and exit. There is (3205). Optionally, the issuing device may request the chip again for a valid SN and may repeat from b.
  • D Public key request If there is no error, the issuing device sends the ID received from the TSM and the TSM public key while requesting the public key from the chip.
  • CRC error Error handling
  • the chip performs CRC check 3206 and TSM public key check 3207.
  • the update information UpNumECC to be used for generating the public key is initialized (3208).
  • Error handling public key error: If the chip's public key (Q TSM ) received from TSM is invalid, the chip responds with an error message (ERR_PUK) and re-requests the TSM's public key.
  • the issuing device receives the ID and requests the ID from the TSM again (REQ_ID, ⁇ ) to receive the ID and the public key of the TSM again.
  • step 3209 is performed in step 3209 after the initialization 3208.
  • 3 to 3 which will be described with reference to FIG. 3C, are common to issuance and reissuance, and are referred to as step 3209 in FIG. 3B regarding issuance, and step 3508 in FIG. 3E regarding reissue.
  • step 3508 of FIG. 3C is performed in step 3209 after the initialization 3208.
  • F Public key generation and delivery (3301): Creates a public key pair based on ID, PUF, and update information, of which the public key is transmitted to the issuing device, and the issuing device sends it to the TSM. This section is considered to be reliable and is appended with a CRC code to rule out communication errors.
  • CRC error Error handling
  • TSM performs CRC check (3304) and chip public key validation (3305).
  • the received public key generates a certificate signed with its own private key (3307) and delivers it to the issuing device, which then delivers it to the chip.
  • the certificate shown in FIGS. 3B to 3D includes only the ID and the public key of the chip and a signature thereof, but if necessary, in addition to the ID and the public key of the certificate and the contents of the certificate, the issuer, validity period, etc. Additional information may be further included.
  • CRC error Error handling
  • Error handling public key error: If the chip's public key (Q Chip ) received from the issuing machine is not valid, the TSM responds with an error message (ERR_CERT) to request the chip's public key again. The issuing device receives this and sends an error message (ERR_PUK) to the chip. In case of error repetition, the chip can be discarded 3306.
  • CRC error Error handling
  • the chip checks the CRC (3309) and verifies that the ID and public key included in the certificate are the same as its own. The signature of the certificate for the ID and the public key is verified (3310). If the signature is verified, the update information UpNumECC and the certificate received from the TSM are stored in the nonvolatile memory (3313).
  • CRC error Error processing
  • each chip signs the chip's public key with the issued ID, updated renewal information (UpNum ECC ), TSM's public key (Q TSM ), and TSM's certificate for its public key (TSM's private key).
  • UpNum ECC updated renewal information
  • Q TSM TSM's public key
  • TSM's certificate for its public key TSM's private key.
  • the TSM maintains a list of SN-ID-public keys for the issued chips. It is assumed that the connection between the chip and the issuer, TSM and manufacturer is secure. In other words, it is assumed that an attacker's intervention is impossible at the issuing stage.
  • the chip When the chip is powered on and the chip requests the TSM to use it, if the TSM checks the validity of the chip of the corresponding ID and the validity period remains, the chip is disabled and the chip is requested to renew the public key. . Since it is an insecure communication environment, when a public key of a newly created chip is delivered, it is signed with an existing private key (prior to update) to guarantee that it is a new public key from the chip. The detailed protocol will be described with reference to FIG. 3D.
  • a Validity Period Confirmation Request ID and a random number (RN) are transmitted to the TSM (3401).
  • TSM confirms the validity period (3402). If no validity period remains, request an update.
  • the ID, the random number received, and the renewal code (RENEWAL) are signed with the TSM's private key and added to the renewal request message so that an attacker cannot arbitrarily update the device.
  • the chip checks the ID and signature of the received update request message (3403 and 3404), and then newly renews the public key pair (d ' Chip , Q' Chip ) by using the incremented UpNum ECC . Create (3405).
  • the public key is signed together with the ID as a private key (d chip ) before updating to the TSM (3406).
  • ID error The chip responds with an error message (ERR_RENEWAL) if the ID received from TSM is not its own. TSM checks the ID and repeats from the update request message (REQ_RENEWAL) if correct.
  • Error handling (signature error): If the chip received a signature from TSM that is not valid, it responds with an error message (ERR_RENEWAL). TSM retransmits the existing update request message (REQ_RENEWAL) or repeats from signature generation.
  • TSM checks the validity of the chip's public key and signature (3407 to 3409). And it generates a certificate signed with its own private key on the received public key and delivers it to the chip. As described above, when regenerating the certificate, additional information may be attached together with the public key.
  • Error handling public key error: If the chip's public key (Q ' Chip ) received from the chip is invalid, the TSM responds with an error message (ERR_RENEWAL) to request the chip's public key again. Error): If the TSM does not have a valid signature on the message received from the chip, the TSM responds with an error message (ERR_RENEWAL) to request retransmission. The chip repeats from signature generation.
  • the chip checks whether the ID and public key included in the certificate are the same as its own (3410). The signature of the certificate for the ID and the public key is verified (3411). If the signature is verified, the certificate received from UpNum ECC and TSM is stored in nonvolatile memory (3413).
  • the new public key Upon renewal, the new public key is signed with the existing private key to ensure that the new public key is on the chip. However, if the expiration date is long past, the existing private key can no longer be used and the issuer must reissue the chip.
  • the detailed protocol is as follows.
  • a Validity Period Confirmation Request After inserting the card 3501, the chip does not know whether it is in a reissued state. Similarly to the update, an ID and a random number (RN) are generated (3502) and transmitted to the issuing device. The issuing device receives this and requests the TSM for a replacement order.
  • RN random number
  • Resend Request TSM adds the ID, random number received, and the reissue code (ISSUE) to TSM's private key (3503) in a resend request message in a manner similar to the update request.
  • C Reissue Request Confirmation The chip verifies the CRC, ID, and signature (3504 to 3506) and increases the UpNum ECC by one (3507).
  • ID error The chip responds with an error message (ERR_REPUK) if the ID received from TSM is not its own. TSM checks the ID and if it is correct repeats the reissue request message (REQ_REPUK).
  • Error handling (signature error): The chip responds with an error message (ERR_REPUK) if the signature received from TSM is invalid. TSM retransmits the existing update request message (REQ_REPUK) or repeats from signature generation.
  • ERP_REPUK error message
  • REQ_REPUK existing update request message
  • D (issuance of f) public key generation and transfer (3301): Create a public key pair based on the ID, PUF, update information of which the public key is delivered to the issuing device, and the issuing device sends it to the TSM. This section is considered to be reliable and is appended with a CRC code to rule out communication errors.
  • CRC error Error handling
  • TSM performs CRC check (3304) and chip public key validation (3305).
  • the received public key generates a certificate signed with its own private key (3307) and delivers it to the issuing device, which then delivers it to the chip.
  • various additional information (such as issuer and expiration date) may be added as needed.
  • Error handling (CRC error) Issued when CRC error occurs in a message received by TSM from the issuing device. The device requests the chip to retransmit in response to a CRC error message (ERR_CERT).
  • Error handling public key error: If the chip's public key (Q Chip ) received from the issuing machine is not valid, the TSM responds with an error message (ERR_CERT) to request the chip's public key again. The issuing device receives this and sends an error message (ERR_PUK) to the chip. In case of error repetition, the chip can be discarded 3306.
  • CRC error Error handling
  • Certificate Verification The chip checks the CRC (3309) and verifies that the ID and public key included in the certificate are the same as its own. The signature of the certificate for the ID and the public key is verified (3310). If the signature is verified, the new certificate received from UpNum ECC and TSM is stored in nonvolatile memory (3313).
  • CRC error Error processing
  • the protocol used is a protocol that grants the core to secure mode by performing mutual authentication with TSM.
  • a Validity Period Confirmation Request In the same way as the renewal and reissue protocol, an ID and a random number (RN) are generated 3601 and transmitted to the TSM, and the protocol starts.
  • RN random number
  • TSM confirms validity period (3602). If the validity period is left, a temporary key pair (a, A) is generated as an ECDH process for sharing a key with a chip. It is then signed with the TSM's private key and delivered to the chip.
  • the chip verifies the received ID (3603), verifies the validity of the received public key (A), and the signature (3604 and 3605).
  • the ECDH process generates a temporary key pair (b, B) of the chip.
  • a temporary public key (A) received from the TSM and the temporary private key (b) generated by the chip to create a shared secret information (W) and extends it to a key derivation function (K1, K2, IV) (3606).
  • K1, K2, IV key derivation function
  • ID Error If the chip receives an ID from TSM that is not its own, it responds with an error message (ERR_SESSION). TSM checks the ID and repeats the session request message (REQ_SESSION) if correct.
  • Error handling public key error: If the chip has not a valid public key received from TSM, it responds with an error message (ERR_SESSION). TSM repeats from the session request message (REQ_SESSION).
  • Error handling (signature error): The chip responds with an error message (ERR_SESSION) if the signature received from TSM is invalid. TSM either generates the signature again or repeats the session request message (REQ_SESSION).
  • TSM checks the validity of the received public key (B) and the validity of the signature (3609 and 3610).
  • the shared secret information (W) is created by using the received chip's public key (B) and the temporary private key (a) generated by the TSM, and then expanded into a key derivation function to share the shared secret key (K1, K2, IV) is generated (3611). By decrypting C 1 using this, it is confirmed that the chip has generated the same shared secret keys.
  • the TSM also transmits the information C 2 encrypted with the shared secret key to the chip (3612).
  • Error handling public key error: The TSM responds with an error message (ERR_HS) if the public key received from the chip is invalid. The chip repeats from the hand shake request message (REQ_HS).
  • ERP_HS error message
  • REQ_HS hand shake request message
  • E Hand shake2 The chip confirms that the TSM also generated the same shared secret keys by decrypting the received C 2 (3613).
  • TEE Trusted Execution Environment
  • TrustZone secure booting function is included. This is to prevent the system from starting because the OS image itself is contaminated. It is a technology that allows the platform to start in a flawless state by checking and executing the integrity of the OS image at boot time.
  • FIG. 4 is a flowchart illustrating a flow of secure booting according to an embodiment.
  • the SoC bootloader 420 of the ROM is first run and privileged. Since the bootloader is stored in the on-SoC ROM and cannot be modified, it is the basis of the secure booting procedure as a root of trust.
  • On-SoC hardware also has a TSM certificate authority's public key in the form of an OTP that cannot be modified.
  • the boot loader 420 uses this public key to verify the integrity of the flash device bootloader 430 to verify its integrity, and then grants permission to the flash device boot loader 430 to execute. To be able.
  • the flash device bootloader 430 which has received the right, verifies the integrity by verifying the signature of the image of the secure world OS and executes it (secure boot) (440). While repeating this process from behind, the normal world bootloader 450 is authorized to boot the normal world OS (460) and the system is driven. This process of moving forward while performing software authentication step-by-step from a hardware-level source of trust that cannot be modified to ensure integrity is called a trust chain.
  • the hardware authenticates the software to be performed in the hardware in a trust chain, and as described with reference to FIGS. 3A to 3F, the software also authenticates the hardware to perform mutual authentication.
  • PUF Physical Unclonable Function
  • PUF Physical Unclonable Function
  • This PUF is hard to leak out of the chip, so it can provide the highest security level as root-of-trust.
  • military weapons such as intercontinental ballistic missiles (ICBM), vehicle security systems (HSM), APs of smart phones, and smart cards are being standardized and commercialized to use PUF for security.
  • the PUF has a via (or inter-layer contact) array fabricated by designing via holes smaller than the via hole size defined by conventional design rules (250 nm * 250 nm in the illustrated example). In this case, open and short are randomly distributed in the via hole array, which can provide a random and substantially invariant over time digital value.
  • the VIA PUF prepared according to the presented example was verified by Reliability by passing various tests according to the JEDEC standard at the accredited evaluation institution, and the randomness passed the true random number testing suite of NIST standard SP 800-90B.
  • FIG. 6 illustrates a secure SoC platform that is inherently protected from physical attack in accordance with one embodiment.
  • a hidden bus 620 for the secure world is provided.
  • the secure IPs 621 may operate at the command level through the secure ISA.
  • the security core 601 divides a memory area into a code area and a data area.
  • the divided memory region may be of a normal world, but in another embodiment, may be of a secure world.
  • the security core 601 may include a memory protection unit (MPU) that prohibits writing in the code area and prohibits execution in the data area.
  • MPU memory protection unit
  • the code area and the data area may be set by a security command processed using a command for the ASR of the Core-A processor.
  • a system area may be set in addition to the code area and the data area.
  • Zone ⁇ mode U / N U / S P / N P / S Code area
  • RX RX RWX RWX Data area RW RW RW RW System area - - RWX RWX
  • mode "U” means User mode and "P” means Privilege mode.
  • N means Normal mode and "S” means Secure mode. Allowed operations are shown for each code area. For example, in user mode and normal mode, R is read and X is execute (eXecution), but W is not allowed.
  • the processor core may include a hardware-based shadow stack that backs up a return address included in a code sequence.
  • the shadow stack may be located in the same or separate added memory, or separate added register, and the like apart from the stack residing on the existing memory.
  • the shadow stack does not use a bus, is not accessed by an OS or software, and is automatically performed when a memory stack related command is executed by an added hardware-based control circuit, thereby dually managing the return address.
  • a software attack can detect that the return address stored in the stack residing on the existing memory is changed. Because the shadow stack is controlled only by hardware circuitry and not accessible by software, it can also fundamentally block attacks that attempt to alter the contents of the shadow stack.
  • the shadow stack described above is an exemplary configuration in which the return address is dually managed, and a stack in which the return address is periodically backed up and dually managed is not limited to the specific exemplary implementation.
  • FIG. 7 through 8 are flowcharts illustrating an operation of a SoC according to an exemplary embodiment.
  • a procedure 710 for authenticating from a certificate server at device power-on is performed.
  • the content of the hardware-based authentication unit pre-authentication IP communicating with the external certificate server through end-to-end mutual authentication is the same as described above with reference to FIG. 3A, and the use of the PUF in this process has been described with reference to FIG. 5.
  • step 720 If authentication is successful at step 720, Secure ISA is managed to be available (730), the debugging port is accessible and the secure world OS is booted (740). The system is then driven through normal mode booting (750).
  • step 720 the secure world becomes inaccessible in step 810 of FIG. Only the normal world can boot, allowing only computing running in the REE environment. This process is as described above with reference to FIGS. 1, 2, 4, and the like.
  • the device described above may be implemented as a hardware component of a memory, a memory as a control software component, and / or a combination of hardware components and software components.
  • the devices and components described in the embodiments may be, for example, processors, controllers, arithmetic logic units (ALUs), digital signal processors, microcomputers, field programmable arrays (FPAs), It may be implemented using one or more general purpose or special purpose computers, such as a programmable logic unit (PLU), microprocessor, or any other device capable of executing and responding to instructions.
  • ALUs arithmetic logic units
  • FPAs field programmable arrays
  • PLU programmable logic unit
  • microprocessor or any other device capable of executing and responding to instructions.
  • the software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device.
  • Software and / or data may be any type of machine, component, physical device, virtual equipment, computer storage medium or device in order to be interpreted by or to provide instructions or data to the processing device. Or may be permanently or temporarily embodied in a signal wave to be transmitted.
  • the software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner.
  • Software and data may be stored on one or more computer readable recording media.
  • Memory operation control method is implemented in the form of program instructions that can be executed by various computer means may be recorded on a computer readable medium.
  • the computer readable medium may include program instructions, data files, data structures, etc. alone or in combination.
  • the program instructions recorded on the media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks.
  • Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.
  • the hardware device described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

Abstract

보안 반도체 칩이 제시된다. 반도체 칩은 이를 테면 시스템 온 칩이다. 시스템 온 칩에 포함되는 프로세서 코어에는 시스템 버스를 통해 통상의 IP들이 연결되어 동작한다. 상기 시스템 버스와 물리적으로 구분되는 히든 버스인 보안 버스가 별도로 제공된다. 보안 버스에는 보안 기능을 수행하거나 보안 데이터를 취급하는 보안 IP들이 연결된다. 보안 반도체 칩은 일반 모드와 보안 모드를 바꾸어 가며 필요한 인증을 수행할 수 있다.

Description

하드웨어 디바이스 및 그 인증 방법
하드웨어 및 그 인증 방법에 연관되며, 보다 특정하게는 반도체 칩이나 전자 장비 등의 하드웨어 디바이스가 정품인지, 변조되거나 손상되지 않았는지 등을 인증하는 방법에 연관된다.
소프트웨어 기반 보안 기술에서는 OS(Operation System) 등의 취약점을 이용한 공격이 새로 나올 때마다 이에 대해 지속적으로 보안 업데이트를 해야 했다. 따라서 보안 공격을 방지하기 위해서 하드웨어 모듈 차원의 보안 공격 방지 설계와 운용이 제시되었다. 이러한 하드웨어 모듈 차원의 보안 방법으로, ARM 사의 TrustZone 기술이 사용되고 있다.
TrustZone 기술과 같은 하드웨어 기반 보안 기술에서는 부팅 단계에서 OS 이미지의 무결성을 검증 후 읽어 들이기 때문에 플랫폼의 무결성을 시스템 시작 단계에서부터 스탭 바이 스탭으로 보장할 수 있게 된다. 이는 하드웨어가 OS를 비롯한 소프트웨어의 무결성을 검증하는 방식이다. 그러나, 소프트웨어의 시점에서 하드웨어의 무결성을 검증하는 것은 아니다.
미국 등록 특허공보 US8,468,342호 (공고일 2013년6월18일)에는 시스템 부팅 시 OS 무결성 체크를 수행하여 안전한 부팅을 수행하는 컴퓨팅 장치가 제시되었다.
기술문헌 "ARM Security Technology: Building a Secure System using TrustZone® Technology" (ARM Limited, White-Paper PRD29-GENC-009492C, April 2009)은 ARM사의 TrustZone 하드웨어 구조, 그리고 그 운용에 있어서의 Secure booting 등을 제시한다.
본 발명은 하드웨어 디바이스의 인증을 위한 하드웨어 디바이스 및 그 인증 방법을 제공하기 위한 것이다.
일측에 따르면, 반도체 칩에 있어서, 프로세서 코어; 및 외부 신뢰 기관과 상호 인증을 수행하여 상기 반도체 칩 및 상기 외부 신뢰 기관 사이의 인증을 수행하는 인증부를 포함하는 반도체 칩이 제공된다.
일실시예에 따르면 반도체 칩은, 상기 프로세서 코어에 제1 버스를 통해 연결되는 엘리먼트들을 포함하는 제1 그룹; 및 상기 프로세서 코어에 제2 버스를 통해 연결되며 보안 모드에서 동작하는 엘리먼트들을 포함하는 제2 그룹을 더 포함한다. 이 경우, 상기 인증부가 상기 인증에 성공한 경우에만 상기 제2 그룹을 사용 가능하도록 활성화 한다. 예시적으로, 그러나 한정되지 않게, 상기 제2 그룹은 Cryptographic IP, secure SRAM, secure DMA 및 boot ROM 중 적어도 하나를 포함한다.
일실시예에 따르면 반도체 칩은, 상기 인증부가 상기 외부 신뢰 기관과 상기 상호 인증을 수행하는 데에 이용되는 키를 제공하는 PUF를 더 포함할 수 있다. 일실시예에 따르면 상기 제2 그룹은 상기 제1 그룹과 상이한 메모리 어드레스를 이용하여 데이터를 처리한다.
예시적으로, 그러나 한정되지 않게, 상기 프로세서 코어는 32 비트 RISC(Reduced Instruction Set Computing) 타입의 임베디드 프로세서인 Core-A 프로세서를 포함한다. 이 실시예에서, 상기 제2 버스는 상기 Core-A 프로세서의 ASR (Application Specific Register)을 상기 제2 그룹에 포함되는 엘리먼트를 제어하는 주소 공간으로 사용하여 구현되는 히든 버스(hidden bus)를 포함한다. 이 경우, 상기 제2 그룹은 상기 보안 모드에서 상기 ASR에 대한 데이터 처리 명령인 MTA(Move to ASR) 명령과 MFA(Move from ASR) 명령어를 보안 명령어(secure instruction) 처리에 이용할 수 있다. 이는 ASR 인터페이스를 이용하여 상기 제2 그룹에 포함되는 보안(secure) IP들을 위한 히든 버스를 구현하는 것으로 이해될 수 있다. 다른 일실시예에 따르면 상기 프로세서 코어는 RISC V ISA 적용 CPU core일 수도 있다.
일실시예에 따르면 상기 인증부는 하드웨어 로직이며, 기존의 컴퓨팅 언어와 상이한 독자 언어로 구동되어 상기 인증 절차를 수행한다. 또한, 상기 인증부는 기존의 컴퓨팅 언어와 상이한 독자 언어로 구성되는 인증 절차를 수행할 수 있다. 일실시예에 따르면 상기 인증부는 ROM이나 상기 반도체 칩 내의 IP와 다르게 일반 셀로 구성되어 PnR(Place and Route) 시 외부에 노출되거나 보안적으로 공격받지 않는다.
다른 일측에 따르면, 소프트웨어를 임베드한 하드웨어 장치에 있어서, 상기 소프트웨어를 구동하는 프로세서 코어; 및 상기 하드웨어 장치를 통해 상기 소프트웨어를 구동하기 위해 외부 신뢰 기관과 상호 인증을 수행하여 상기 반도체 칩 및 상기 외부 신뢰 기관 사이의 인증을 수행하는 인증부를 포함하는 장치가 제공된다. 일실시예에 따르면 상기 장치는 상기 프로세서 코어에 노말 모드에서 동작하는 엘리먼트들을 포함하는 제1 그룹을 연결하는 제1 버스; 및 상기 프로세서 코어에 보안 모드에서 동작하는 엘리먼트들을 포함하는 제2 그룹을 연결하는 제2 버스를 더 포함할 수 있다. 일실시예에 따르면 상기 인증부가 상기 인증에 성공한 경우에만 상기 제2 그룹을 사용 가능하도록 제2 버스로의 접근이 활성화된다.
일실시예에 따르면 상기 장치는 상기 인증부가 상기 외부 신뢰 기관과 상기 상호 인증을 수행하는 데에 이용되는 키를 제공하는 PUF를 더 포함할 수 있다.
또 다른 일측에 따르면, 반도체 칩의 동작 방법에 있어서, 인증부가 외부 신뢰 기관과 상호 인증을 수행하는 단계; 및 상기 인증이 성공하는 경우에 상기 반도체 칩의 보안 모드를 활성화하는 단계를 포함하는 방법이 제공된다. 여기서 상기 반도체 칩은 상기 프로세서 코어에 노말 모드에서 동작하는 엘리먼트들을 포함하는 제1 그룹을 연결하는 제1 버스; 및 상기 프로세서 코어에 보안 모드에서 동작하는 엘리먼트들을 포함하는 제2 그룹을 연결하는 제2 버스를 포함하는 것일 수 있다. 이 경우, 상기 방법은 상기 인증이 성공하는 경우에 상기 제2 그룹 및 상기 제2 버스를 활성화 하고, 상기 인증이 실패하는 경우에 상기 제2 그룹 및 상기 제2 버스를 비활성화 하고 상기 제1 그룹 및 상기 제1 버스를 활성화 할 수 있다. 일실시예에 따르면 상기 제2 그룹은 Cryptographic IP, secure SRAM, secure DMA 및 boot ROM 중 적어도 하나를 포함한다.
본 발명에 따르면, 하드웨어 디바이스를 인증할 수 있다.
도 1은 일실시예에 따른 SoC 장치의 블록도이다.
도 2는 일실시예에 따른 SoC를 구현한 구조를 도시한다.
도 3a 내지 3f는 일실시예에 따라 Pre-authentication이 수행되는 과정과 프로토콜을 설명하기 위한 도면이다.
도 4는 일실시예에 따르면 보안 부팅(secure booting)의 흐름을 설명하기 위한 흐름도이다.
도 5는 일실시예에 따른 PUF의 구현을 설명하기 위한 개요도이다.
도 6은 일실시예에 따라 물리적 공격으로부터 근본적으로 보호되는 보안 SoC 플랫폼을 도시한다.
도 7 내지 도 8은 일실시예에 따라 시큐어 부팅을 수행하는 흐름도이다.
이하에서, 실시예들을 첨부된 도면을 참조하여 상세하게 설명한다. 그러나, 권리범위는 이러한 실시예들에 의해 제한되거나 한정되는 것은 아니다. 각 도면에 제시된 동일한 참조 부호는 동일한 부재를 나타낸다.
아래 설명에서 사용되는 용어는, 연관되는 기술 분야에서 일반적이고 보편적인 것으로 선택되었으나, 기술의 발달 및/또는 변화, 관례, 기술자의 선호 등에 따라 다른 용어가 있을 수 있다. 따라서, 아래 설명에서 사용되는 용어는 기술적 사상을 한정하는 것으로 이해되어서는 안 되며, 실시예들을 설명하기 위한 예시적 용어로 이해되어야 한다.
또한 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 설명 부분에서 상세한 그 의미를 기재할 것이다. 따라서 아래 설명에서 사용되는 용어는 단순한 용어의 명칭이 아닌 그 용어가 가지는 의미와 명세서 전반에 걸친 내용을 토대로 이해되어야 한다.
하드웨어와 소프트웨어의 상호 인증
위에서 언급한 바와 같이 하드웨어 기반의 보안 기술 중 secure booting과 같은 절차로 하드웨어가 소프트웨어의 무결성을 검증하는 기술이 보편적이다. 만약 스마트폰이나 핸드헬드 디바이스의 OS가 무결한 이미지가 아니라 손상되거나 해킹 등으로 보안 기능이 변조된 것이 발견되는 경우, 하드웨어가 이를 부팅 단계에서 발견하거나, 및/또는 특정 어플리케이션의 시행 단계에서 발견하여 보안 위험을 막는 것 등이다. 해커에 의해 변조된 OS가 설치된 스마트폰에서 모바일 뱅킹이나 패이먼트 어플리케이션을 실행할 때 해킹된 OS가 아닌지 검증하여 절차 진행이 중지되는 것과 같은 일은 이제 흔하다.
그런데 반대로 OS나 어플리케이션 소프트웨어가 하드웨어를 인증하는 것은 제시된 바 없다. 요즈음과 같이 스마트폰의 모바일 OS부터, 전자 장비의 펌웨어, 임베디드 소프트웨어 및 각종 어플리케이션이 온-에어 배포(distribution on air)되는 경우, 개발자 또는 매뉴팩처 입장에서 이들이 설치되어 운용될 장비가 정품이고 변조/손상되지 않은 무결한 것임을 보장받는 것은 충분히 필요한 기술이다. 이하에서 제시되는 여러 실시예들에서는, 불법 모조 하드웨어, 계약에 의한 사용 기간이 만료된 하드웨어, 원래의 기기에서는 보안에 의해 막혀 있는 기능이나 정보에 접근하기 위해 변조된 하드웨어 등을 방지하기 위해 소프트웨어 스스로 하드웨어를 인증하는 기술이 제시된다. 물론 하드웨어가 소프트웨어를 인증하는 내용을 함께 포함하므로, 이러한 면에서는 하드웨어와 소프트웨어의 상호 인증을 통한 안전성이 보장되는 시스템으로 이해되어도 좋다.
이하의 실시예에서는 시스템 온 칩 레벨의 장치에서 하드웨어와 소프트웨어의 상호 인증 기술이 예시적으로 설명되나, 반드시 이러한 예에 국한되는 것은 아니다. 따라서 핸드 핼드 장비의 하드웨어와 그 OS 또는 펌웨어의 상호 인증, 나아가 자동차나 항공기와 그 운영 소프트웨어의 상호 인증 등 발명의 사상을 벗어나지 않는 범위에서의 유사한 응용은 얼마든지 있을 수 있다.
시스템 온 칩의 소프트웨어에 대한 보안 공격
SoC에 대한 공격은 물리적 공격과 소프트웨어 공격을 포함한다. 물리적 공격이 무력화되고 소프트웨어 시스템이 보안 SoC 플랫폼에 의해 보호된다면, 개발자들은 보안 이슈들에 대하여 신경 쓸 필요 없이 자신의 일에만 집중할 수 있다. 여기서 제시되는 실시예들은 소프트웨어에 대한 보안 공격을 방지하여 안전한 환경에서 운영되는 SoC 플랫폼을 제공한다.
소프트웨어 공격은 소프트웨어 모듈만으로는 방어하기가 어려운 경우가 있어서, 하드웨어 모듈 차원에서 소프트웨어 보안 공격을 방어하는 것이 바람직하다. 예시적으로 ARM 사의 TrustZone과 같은 환경이 될 수 있다. TrustZone을 이용하기 위해서는 TEE(Trusted Execution Environment) 표준에 의해 정의된 보안 OS(Operation System)나 보안 라이브러리가 필요하다. 그러나 TEE의 성능 요구사항은 작은 CPU 코어와 실시간 OS(Real Time OS: RTOS)가 사용되는 IoT(Internet of Things)의 말단 SoC들이 충족하기 어려운 수준일 수 있다. 실시예들에 따르면 큰 오버헤드를 야기하는 secure OS나 보안 라이브러리 대신, 직접 TEE를 지원할 수 있는 보안 ISA(Instruction Set Architecture)를 갖춘 SoC가 제시된다. 그리고 이러한 보안 ISA를 수행할 수 있는 CPU 코어 및 그 동작 방법의 실시예들이 제시된다. 도면을 참고하여 다양한 실시예들을 설명하기로 한다.
시스템의 구성
도 1은 일실시예에 따른 반도체 시스템 온 칩(100)의 블록도이다. 칩은 프로세서 코어(101)을 포함한다. 코어(101)에는 제1 버스(111)와 제2 버스(121)이 별도로 연결된다. 제1 버스(111)는 일반 모드(normal mode)에서 동작하는 범용 컴퓨팅 그룹인 제1 그룹(112)에 제공된다. '그룹'은 개별 컴퓨팅 자산(intellectual property: IP)나 메모리, 캐시 등의 집합으로 이해될 수 있다. 이하에서 별다른 언급이 없더라도 엘리먼트, IP, 기능 요소, 컴퓨팅 자산 등은 혼용되어 사용될 수 있다.
제2 버스(121)은 보안 모드(secure mode)에서만 동작하는 엘리먼트들을 포함하는 제2 그룹(122)에 제공된다. 제2 버스(121)는 제1 버스(111)와는 물리적으로 완전히 분리되어 있다. 이러한 물리적 고립이 normal world(110)와 secure world(120)의 구분을 만들 수 있으며, 이 구분이 소프트웨어에 대한 보안 공격에 강인한 SoC를 제공한다. 물리적인 고립은 normal world(110)의 제1 그룹(112)이 secure world(120)의 제2 그룹(122)와는 완전히 다른 메모리 어드레스 체계를 가지고 데이터를 처리한다는 것으로도 이해될 수 있다.
SoC(100)에는 시스템 파워-온 시 및/또는 필요에 의해 보안 모드가 실행될 필요가 있을 때 secure world(120)에 대해 외부 인증 기관(미도시)과 상호 인증을 수행하는 인증부(102)가 포함될 수 있다. 인증부(102)는 외부 인증 기관에 대해 이 SoC(100), 제2 그룹(122) 및 그 개별 IP들, 나아가 이에 임베드된 소프트웨어가 정당한 것이며 무결한 것임을 입증하여 인증을 받을 수 있다. 또한 인증부(102)는 현재 트랜잭션의 대상이 되는 외부 터미널이 신뢰할 수 있는 상기 외부 인증 기관이 맞다는 점을 상호 인증하기도 한다. 인증부(102)가 Pre-authentication 외부 인증 기관으로부터 공개키를 받아 등록하고 인증서를 발급받는 발급 프로토콜과 필요에 따라 기존의 공개키를 새 공개키로 교체하는 등 소프트웨어의 하드웨어 인증에 대해서는 도 3을 참조하여 상세히 후술한다.
일반 모드와 보안 모드의 전환
일실시예에 따른 SoC(100)는 일반 모드(normal mode)와 보안 모드(secure mode)를 가질 수 있다. 상술한 인증부(102)의 인증이 성공하는 경우에만 제2 그룹(122)이 부팅되고 신뢰 수행환경(Trusted Execution Environment, TEE))에 연관되는 secure world(120)가 활성화된다. 물론 이 경우에는 제1 그룹(112)도 부팅되고 normal world(110)가 활성화 된다. 그러나 상기 인증이 안 되는 경우에는, 일반 수행 환경(Rich Execution Environment, REE)에 연관되는 제1 그룹(112)만 부팅되어 normal world(110)는 활성화되지만 secure world(120)가 활성화되지 않는다.
secure world(120)가 활성화된 경우라도 제2 그룹(122)이 항시 동작하는 것은 아닐 수 있으며 대기상태에 있을 수 있다. REE 환경의 컴퓨팅, 이를테면 안드로이드 운영체제와 어플리케이션이 실행되는 중에, 보안 위반 이벤트(event of secure violation)가 발생하거나 또는 금용 결제가 필요한 등의 이유로 상승된 보안 취급이 처리되어야 하는 호출이 있는 경우 상기 보안 모드가 수행될 수 있다. 다시 말해, Normal world에서는 모바일 폰의 안드로이드와 같은 REE(Rich Execution Environment)가 일반적인 하드웨어 IP들과 함께 ARM 기반의 SoC에서 동작한다. 그러다가 보안 자원, 이를테면 Cryptographic IP나 secure SRAM이 필요할 때에는 보안 OS와 보안 하드웨어 IP로 이루어진 TEE가 동작하여 REE에게 결과를 전송한다. ARM 사의 TrustZone은 SoC 플랫폼의 보안 IP에 접근하기 위한 제어 신호로, AMBA AXI에 1 비트 버스 신호를 추가로 제공한다. 그러나 보통의 작은 CPU 코어와 RTOS(Real Time OS)가 사용되는 IoT(Internet of Things) 말단 SoC에서 TEE에서의 성능 요구사항들을 충족시키기는 어려울 수 있는데 실시예들에 따르면 이것이 가능하다.
인증의 수단
일실시예에 따르면 반도체 SoC(100)는 인증부(102)가 상기 외부 신뢰 기관과 상호 인증을 수행하는 데에 이용되는 근원 키(root key)를 제공하는 PUF(Physical unclonable function)(103)를 더 포함할 수 있다. 이러한 근원 키를 이용한 RSA, AES 등의 다양한 인증 알고리즘 중 적어도 하나가 상기 인증에 사용될 수 있다. 예시적으로, 그러나 한정되지 않게, PUF는 반도체 제조 공정상의 공정 편차를 이용하여 상기 반도체 칩 내에 내재적으로(intrinsic) 포함될 수 있다. 하나의 예시적인 구현에서, 상기 PUF는 반도체의 전도성 레이어 간에 래이이웃 된 비아(via)나 인터-레이어 컨택이 공정에서 정상적으로 패터닝 되어 상기 전도성 레이어 사이를 단락하는지에 따라 디지털 값을 제공하는 것일 수 있다. PUF의 구현과 역할에 대해서는 도 5와 6을 참조하여 보다 상세히 후술한다.
시큐어 메모리
일실시예에 따르면 시큐어 메모리(130)는 일반 모드에서 활용하는 영역과 보안 모드에서 활용하는 영역을 포함한다. 시큐어 메모리(130)는 예시적으로 비휘발성 메모리(NVM)을 포함한다. 보안 모드에서 활용하는 영역은 데이터를 그대로 저장하지 않고 PUF(103)이 제공하는 근원 키를 이용하여 암호화 해서 저장할 수 있다. 따라서 물리적으로 시큐어 메모리(130)의 데이터가 추출되더라도 PUF(103)과 직접 연결(direct wired)되어 복호화되지 않으면 이는 의미 없다.
예시적 시스템 구현 - Core A 플랫폼의 이용
도 2는 일실시예에 따른 SoC를 Core-A 환경에서 구현한 구조를 도시한다. 예시적으로, 그러나 한정되지 않게, 상기 프로세서 코어는 32 비트 RISC(Reduced Instruction Set Computing) 타입의 임베디드 프로세서인 Core-A 프로세서(201)를 포함한다. 다른 일실시예에 따르면 상기 프로세서 코어는 RISC V ISA를 적용한 CPU core일 수도 있다. 이하에서 '프로세서', '프로세서 코어', '시큐어 코어', '시큐어 프로세서' 등은 경우에 따라 상호간에 바뀌어 쓰일 수 있는 용어들로 이해되어야 한다. 예시적인 구현으로 'Core-A'를 이용한 구현에 대해 주로 설명하지만 RISC V ISA를 적용한 CPU 코어 등 다른 타입의 구현이 얼마든지 가능함은 이 분야의 기술자에게 자명하다.
일반 버스(210)에 REE 환경의 제1 그룹 엘리먼트들인 SRAM(211), Peripheral IP들(212), 디버깅 포트(213)가 연결되어 있다. 그리고 보안 버스(220)에 TEE 환경에서 동작해야 하는 Cryptographic IP들(221), boot ROM(222), secure SRAM(223) 및 secure DMA(224)가 연결되어 있다. 도 1을 참조하여 설명한 바와 같이, 인증부(202) 및 적어도 하나의 PUF들(203)이 존재하여 인증을 수행할 수 있다. PUF들(203)은 인증을 위해 코어(201)에 직접 연결되어 있으며, 또한 Cryptographic IP 중 AES/SEED IP, ECC/RSA IP에 직접 연결되어 있을 수 있다. 나아가 시큐어 NVM(230)도 PUF(203)에 직접 연결되어 있어 데이터를 암호화하여 안전하게 저장하는 것이 가능하다.
일실시예에 따른 보안 버스(220)는 상기 Core-A 프로세서의 ASR (Application Specific Register)을 상기 secure world의 제2 그룹 엘리먼트들의 제어를 위한 주소 공간으로 사용하여 구현되는 히든 버스일 수 있다. 이 응용에서, 상기 제2 그룹은 상기 보안 모드에서 상기 ASR에 대한 데이터 처리 명령인 MTA(Move to ASR) 명령과 MFA(Move from ASR) 명령어를 보안 명령어(secure instruction) 처리에 이용할 수 있다. 이는 ASR 인터페이스를 이용하여 상기 제2 그룹에 포함되는 보안(secure) IP들을 위한 히든 버스를 구현하는 것으로도 이해될 수 있다.
이러한 구현에 따르면, 큰 오버헤드를 갖는 secure OS나 라이브러리 대신 직접 TEE를 지원할 수 있는 보안 ISA(secure Instruction Set Architecture)가 구현된다. 따라서 ARM의 TrustZone을 이용하는 것에 비해 작은 CPU를 갖는 디바이스들에 적합하다. 실시예들에 따르면 일반 모드와 구분되는 보안 모드 관리 및 하드웨어와 소프트웨어 상호 인증을 위해 인증부인 pre-authentication 하드웨어가 제공된다. 또한 신뢰성, 안정성, 랜덤성이 이미 검증된 VIA-PUF(Physical Unclonable Function)을 이용한 상호 인증 하드웨어 IP들이 제공되므로, 강화된 secure world를 갖는 '보안 SoC 플랫폼'이 제공된다. 제시된 실시예에 따르면, 보안 ISA가 제시된다. 일반적인 ISA와 달리 별도로 구현되는 secure world 버전의 ISA이다. 기존의 ARM사 TrustZone 기술에 따른 방법으로 secure world 내 자원을 접근하기 위해서는 보안 OS나 복잡한 라이브러리가 필요하다. 그러나 제안하는 실시예에서는 보안 ISA에 기반하여 secure world 내 자원을 명령어(instruction) 수준에서 바로 접근할 수 있다.
또한, Pre-authentication IP를 사용하여 보안 ISA에 대한 보안 모드 관리를 함으로써 안전한 상호 인증을 수행하고 비인가된 사용자의 내부 접근, 이를테면 소프트웨어 공격을 막는다. 실시예에 따라 제안되는 보안 코어는 secure world에 대한 숨겨진 통로를 제공하며, 이는 주 메모리 인터페이스와 물리적으로 분리되어 있다. 또한 소프트웨어를 읽어들일 때 secure DMA를 이용하여 하드웨어에 의해 자동으로 무결성이 확인되도록 하며, 인증을 위해서 내부 PUF가 보안 저장 공간이나 보안 IP들을 위한 키를 제공한다. 각각을 보다 상세히 설명한다.
보안 ISA (Instruction Set Architecture)
기존의 방법에 따라 secure world 내에서 자원을 사용하거나 보안 함수를 호출하기 위해서는 보안 OS나 라이브러리가 범용 CPU core에서 동작하기 위해 필요하다. 그러나 실시예에 따르면 secure world에서의 요구사항과 secure OS 및 라이브러리의 특징적 기능을 제공하면서도 오버헤드가 없는 보안 ISA가 제시되며 이는 종전의 Core-A를 기능적으로 확장한다. 이는 보안 시스템이 보안 OS나 라이브러리의 도움 또는 어플리케이션 개발의 어려움 없이 TrustZone을 직접 접근할 수 있도록 해주며 관리를 위한 노력도 줄어들 수 있다. 실시예에 따른 보안 ISA의 예시적 특징은 다음과 같다.
- 제어 흐름 무결성: 효율을 위해 하나의 명령어로 제어 흐름의 무결성을 보호하는 코드 대체
- 키 관리: 공개키 암호를 위한 랜덤 수 및 키 쌍 생성 포함
- 메모리 보안 레벨 관리: 각 페이지와 세그먼트별로 다양한 보안 레벨 제공
- 보안 엔진: 보안 하드웨어 엔진과 밀접하게 동작하는 ISA 확장
- Secure Booting / 인증: 보안 디버깅과 부팅을 위한 인증 지원
- 보안 모드 관리: 보안 모드를 위한 마이크로구조의 관리 지원
- 레지스터 내용 보호: VIA-PUF로 보안 레지스터의 내용 암호화
Pre-authentication 수행
도 3a 내지 3f는 일실시예에 따라 Pre-authentication이 수행되는 과정과 프로토콜을 설명하기 위한 도면이다. 도 3a를 참조하면 하드웨어 SoC(300) 내에는 인증을 처리하고 보안 모드에서 동작하는 부분(310)이 존재한다. 보안 ISA가 사용될 수 있기 위해서는 pre-authentication IP(301)가 전원이 켜졌을 때나 리셋된 이후 말단간 상호인증을 통해 외부 인증서 서버, 이를테면 상업 네트워크에서 터미널의 보안을 관리하는 TSM (Terminal Security Management) System 서버(301)와 통신할 수 있다. 도시된 바와 같이 예시적으로, 그러나 한정되지 않게 이러한 상호 인증은 PUF(303)가 만들어 내는 근원 키를 이용한 공개키 암호화 방식에 의할 수 있다.
일실시예에 따르면 상기 상호 인증에 사용되는 pre-authentication IP(301) 내 인증 프로토콜은 일반적인 언어(예를 들어, C 등의 고급 언어나, 특정 Core용 어셈블리어)가 아니다. Pre-authentication IP(301) 내에서는 인증 프로토콜의 수행만을 위해 설계한 전용 언어로 구현되어 있기 때문에 분석이 어렵고 실질적으로 분석이 불가능하다. 또한 pre-authentication IP(301)가 하드웨어 로직으로 구현됨으로써 수정이 불가능(무결성 보장)할 뿐만 아니라 ROM 등의 물리적으로 분리된 IP 형태가 아닌 기본 셀들의 조합으로 구현함으로써 PnR(Place and Route) 과정에서 다른 셀들과 섞이게 하는 것이 가능해 역공학 등의 물리적 공격으로부터도 강인하다.
서버(301)와 제안한 플랫폼(300)은 각자의 개인키로 서명을 생성하고 인증서 내에는 자신의 공개키가 포함되어 있다. 상호 인증은 인증서와 서명을 교환함으로써 수행된다. Pre-authentication IP(302)는 VIA-PUF(303)로부터 개인키를 얻고 이를 이용해 생성한 서명을 인증서 서버에게 전달한다. 그리고 저장하고 있던 외부 인증서 서버의 공개키로 수신한 서명을 검증한다. 이 때 서명 알고리즘은 공개키 암호 알고리즘으로 ECC나 RSA일 수 있다. 성공적인 상호인증으로 시스템이 보안 모드에 진입하면 보안 코어가 secure booting을 제어한다. 또한 디버깅 포트는 오직 보안 모드일 때에만 열려, 인증된 사용자만 디버깅을 수행할 수 있게 된다. 인증이 성공하는 경우에는 보안 모드가 허가될 수 있으며, secure world의 IP 자원들(311 및 312 등)이 동작할 수 있다.
한편, 상호 인증에서 교환했던 공유 키는 향후 보안 목적으로 데이터를 주고 받을 때 암호화 키나 MAC(Message Authentication Code)용 키, 그리고 암호화 또는 MAC에 사용되는 IV(Initial Vector)로 사용하여 통신 시 기밀성 및 무결성 확보에 사용될 수 있다. 이하에서는 상호 인증을 위한 자세한 프로토콜을 설명한다.
Pre-authentication 프로토콜
Pre-authentication 프로토콜은 사용에 앞서 공개키를 등록하고 인증서를 발급받는 '발급 프로토콜'과 필요에 따라 기존의 공개키를 새 공개키로 교체하고 새 공개키에 대한 인증서를 재발급할 수 있는 '재발급 및 갱신 프로토콜'을 포함하고 있다. 발급 이후 칩은 TSM (Terminal Security Management) System 에게 사용을 요청하는 것으로 시작하며, 유효 기간이 남은 경우 그대로 사용 프로토콜이, 유효 기간이 만료된 경우 갱신 프로토콜이 온라인상에서 수행된다. 만약 유효 기간이 만료된지 오랜 시간 지났거나 해당 칩의 기존 키 쌍이 공격 등으로 인해 더 이상 유효하지 않다고 TSM에서 판단된 경우 온라인상에서의 사용 프로토콜과 갱신 프로토콜은 사용할 수 없으며, 발급 기관에서 발급 프로토콜과 비슷한 방식으로 재발급을 받아야 한다. 이 때 재발급 프로토콜은 ID 발급 부분만 생략되므로 이를 제외하면 발급 프로토콜과 거의 동일하다. 그리고 안전하다고 가정된 발급기관에서 키와 인증서를 변경할 뿐만 아니라 기존 키는 더 이상 유효하지 않으므로 공개키 전달 시 서명이 필요 없다. 다시 말해 갱신 프로토콜에선 칩에서 새로 생성한 공개키를 TSM에게 전달할 때 변경 전 개인키로 서명하여 전달한다. 각 단계의 프로토콜을 도면을 참조하면서 상세히 설명한다.
발급 프로토콜
도 3b에서 제시된 흐름은 발급 프로토콜을 제시한다. 기기에서 생성한 공개키 쌍 중 공개키를 등록하고 공개키에 대한 인증서를 발급 받는 과정이다. 공개키 쌍 생성 및 전달, 인증서 발급 부분은 재발급 프로토콜에서도 동일하게 수행될 것이다.
먼저 칩 및 일련번호 목록 전달과정이 수행된다. 유효한 기기들에 대한 일련번호 목록(SN-list)은 제조자로부터 TSM에게로 전달되어 있다(3202).
ⓐ 칩 삽입(3201) : 발급기기에 인증 칩 또는 인증 칩이 삽입된 기기가 삽입된다. 이 때 발급자(예를 들어 은행 또는 신용카드회사)가 구동하는 발급기기는 신뢰되는 것으로 간주한다.
ⓑ SN 요청 : 그러면 발급기기는 칩에게 SN을 요청하여 전달받는다.
ⓒ ID 요청 : 발급기기는 TSM에게 해당 칩에 대한 ID를 요청하면서 칩으로부터 받은 SN을 전달한다. TSM은 ID를 생성(3203)하고, 전달 받은 SN 확인(3204) 후 자신의 공개키(QTSM)를 ID와 함께 발급기기에 전달한다.
* 오류 처리(유효하지 않은 SN으로 판단되는 경우) : TSM에게 유효하지 않은 SN이 전달된 경우라면, 상기 단계에서 ID를 전달하는 대신 오류 메시지(ERR_ID)로 응답하고 폐기(Disuse)하고 종료할 수 있다(3205). 선택적으로 발급기기는 칩에게 유효한 SN을 달라고 다시 요청할 수 있고 ⓑ 과정부터가 반복될 수 있다.
ⓓ 공개키 요청 : 오류가 없다면 발급기기는 칩에게 공개키를 요청하면서 TSM으로부터 받은 ID, TSM의 공개키를 전달한다.
* 오류 처리(CRC 오류) : 발급기기가 TSM으로 받은 메시지에 CRC 오류가 있을 경우 ID 요청(REQ_ID, ⓒ)을 다시 하여 ID, TSM의 공개키를 다시 받는다.
ⓔ 공개키 생성 준비 : 칩은 CRC 검사(3206), TSM의 공개키의 유효성 검사(3207)를 수행한다. 그리고 공개키 생성에 사용될 갱신 정보(UpNumECC)를 초기화한다(3208).
* 오류 처리(CRC오류) : 칩이 발급기기로부터 받은 메시지에 CRC 오류가 있을 경우 오류 메시지(ERR_PUK)을 송신하여 ID, TSM의 공개키를 다시 받는다.
* 오류 처리(공개키 오류) : 칩이 TSM으로부터 받은 TSM의 공개키(QTSM)가 유효하지 않을 경우 오류 메시지(ERR_PUK)로 응답하여 TSM의 공개키를 재요청한다. 발급기기는 이를 수신하여 TSM에게 ID를 요청(REQ_ID, ⓒ)을 다시하여 ID, TSM의 공개키를 다시 받는다.
상기 초기화(3208) 후 단계(3209)에서 도 3c가 수행된다. 도 3c를 참조하여 설명될 ⓕ 내지 ⓗ는 발급과 재발급에 공통되는 부분으로, 발급에 관한 도 3b에서는 단계(3209)로, 재발급에 관한 도 3e에서는 단계(3508)로 지칭된다. 후술할 도 3e의 단계(3508) 과정에서 여기의 ⓕ 내지 ⓗ가 다시 참조된다.
ⓕ 공개키 생성 및 전달(3301) : ID, PUF, 갱신 정보를 바탕으로 공개키 쌍을 생성하여 그 중 공개키는 발급기기로 전달하고 발급기기는 이를 TSM으로 전달한다. 이 구간은 신뢰되는 것으로 간주하며 통신상의 오류를 배제할 수 있도록 CRC 코드를 덧붙인다.
* 오류 처리(CRC 오류) : 발급기기가 칩으로부터 받은 메시지에서 CRC 오류 발생 시(3302) 오류 메시지(ERR_PUK)를 송신하여 칩의 공개키를 다시 전송 받는다. 오류 반복 시 칩을 폐기(Disuse)(3303) 시킬 수 있다.
ⓖ 인증서 발급 : TSM은 CRC 검사(3304), 칩의 공개키의 유효성 검사(3305)를 수행한다. 그리고 수신한 공개키에 자신의 개인키로 서명한 인증서를 생성(3307)하여 발급기기로 전달하고 발급기기는 이를 칩에게 전달한다. 참고로 도 3b 내지 3d에 표시된 인증서에는 칩의 ID와 공개키, 그리고 이들에 대한 서명만 포함되어 있지만, 필요한 경우 서명하는 대상 및 인증서 내용에 ID 및 칩의 공개키 외에도 발급 기관, 유효 기간 등의 추가 정보가 더 포함될 수 있다.
* 오류 처리(CRC 오류) : TSM이 발급기기로부터 받은 메시지에서 CRC 오류 발생 시 발급기기는 칩에게 CRC 오류 메시지(ERR_CERT)로 응답하여 재전송을 요청한다.
* 오류 처리(공개키 오류) : TSM이 발급기기로부터 받은 칩의 공개키(QChip)가 유효하지 않을 경우 오류 메시지(ERR_CERT)로 응답하여 칩의 공개키를 재요청한다. 발급기기는 이를 받아 오류 메시지(ERR_PUK)를 칩에게 전달한다. 오류 반복 시 칩을 폐기(Disuse)(3306) 시킬 수 있다.
* 오류 처리(CRC 오류) : 발급기기가 TSM으로부터 받은 메시지에서 CRC 오류 발생 시(3308) 발급기기는 TSM에게 인증서 요청 메시지(REQ_CERT)를 다시 전송한다.
ⓗ 인증서 검증 : 칩은 CRC를 검사하고(3309) 인증서에 포함된 ID와 공개키가 자신의 것과 동일한지 확인한다. 그리고 ID와 공개키에 대한 인증서의 서명을 확인한다(3310). 서명이 확인되면 갱신 정보(UpNumECC)와 TSM으로부터 받았던 인증서를 비휘발성 메모리에 저장한다(3313).
* 오류 처리(CRC 오류) : 칩이 발급기기로부터 받은 메시지에서 CRC 오류 발생 시(3311) 칩은 발급기기에 CRC 오류 메시지(ERR_REG_CERT)로 응답하여 재전송을 요청한다. 재전송 후 에러처리이면 폐기(3312) 가능하다.
* 오류 처리(인증서 오류) : 인증서 오류(ID, 공개키, 서명 오류) 발생 시 칩은 인증서 오류 메시지(ERR_REG_CERT)를 발급기기에게 보내고 발급기기는 TSM에게 보내 인증서를 재요청(REQ_CERT)하고 이 후 과정을 반복한다.
이상이 발급과 재발급에 공통되는 도 3c 부분이며, 다시 발급 과정인 도 3b의 ID, QTSM를 저장하는 단계(3210) 직전으로 돌아가서 단계(3210)이 수행된다.
발급이 끝나면 각 칩은 발급받은 ID와 초기화한 갱신 정보(UpNumECC), TSM의 공개키(QTSM), 그리고 자신의 공개키에 대한 TSM의 인증서(TSM의 개인키로 칩의 공개키를 서명한 것)를 비휘발성 메모리에 가지고 있게 된다. 발급 후 TSM은 발급된 칩들에 대한 SN-ID-공개키 목록을 보유하게 된다. 칩과 발급자(발급기기), TSM, 제조사 간의 연결은 안전하다고 가정한다. 즉 발급 단계에서는 공격자의 개입이 불가능하다고 가정한다.
갱신 프로토콜
발급이 끝난 칩에 전원이 켜져 칩이 TSM에게 사용 요청을 하였을 때 TSM에서 해당 ID의 칩의 유효 기간을 확인한 결과 유효 기간이 남아 있지 않은 경우 칩 사용을 불허하며, 칩에게 공개키 갱신을 요청한다. 안전하지 않은 통신 환경이기에 새로 생성한 칩의 공개키를 전달할 때 기존의 개인키(갱신 전 개인키)로 서명하여 전달함으로써 해당 칩으로부터 온 새 공개키임을 보장한다. 자세한 프로토콜은 도 3d를 참고하여 설명한다.
ⓐ 유효 기간 확인 요청 : ID와 랜덤 수(RN)을 TSM에게 전달한다(3401).
ⓑ 유효 기간 확인 및 갱신 요청 : TSM이 유효 기간을 확인한다(3402). 유효 기간이 남아 있지 않은 경우 갱신을 요청한다. 공격자가 임의로 기기를 갱신시킬 수 없도록 ID와 수신한 랜덤 수, 그리고 갱신 코드(RENEWAL)를 TSM의 개인키로 서명하여 갱신 요청 메시지에 덧붙인다.
ⓒ 공개키 쌍 갱신 및 전달 : 칩은 수신한 갱신 요청 메시지의 ID와 서명을 확인(3403 및 3404)한 후, 1 증가시킨 UpNumECC를 이용하여 새로 공개키쌍(d'Chip, Q'Chip)을 생성한다(3405). 그리고 그 중 공개키를 ID와 함께 갱신 전 개인키(dChip)로 서명하여 TSM에게 전달한다(3406).
* 오류 처리(ID 오류) : 칩이 TSM으로부터 받은 ID가 자신의 것이 아니라면 오류 메시지(ERR_RENEWAL)로 응답한다. TSM은 ID를 확인하고 맞다면 갱신 요청 메시지(REQ_RENEWAL)부터 반복한다.
* 오류 처리(서명 오류) : 칩이 TSM으로부터 받은 서명이 유효하지 않을 경우, 오류 메시지(ERR_RENEWAL)로 응답한다. TSM은 기존 갱신 요청 메시지(REQ_RENEWAL)을 재전송하거나 서명 생성부터 반복한다.
ⓓ 인증서 발급 : TSM은 칩의 공개키의 유효성 검사와 서명의 유효성 검사를 수행한다(3407 내지 3409). 그리고 수신한 공개키에 자신의 개인키로 서명한 인증서를 생성하여 칩에게 전달한다. 상술한 바와 같이 인증서를 재생성할 때에도 공개키 외에 추가 정보가 함께 붙을 수 있다.
* 오류 처리(공개키 오류) : TSM이 칩으로부터 받은 칩의 공개키(Q'Chip)가 유효하지 않을 경우 오류 메시지(ERR_RENEWAL)로 응답하여 칩의 공개키를 재요청한다.* 오류 처리(서명 오류) : TSM이 칩으로부터 받은 메시지의 서명이 유효하지 않을 경우 칩에게 오류 메시지(ERR_RENEWAL)로 응답하여 재전송을 요청한다. 칩은 서명 생성부터 반복한다.
ⓔ 인증서 검증 : 칩은 인증서에 포함된 ID와 공개키가 자신의 것과 동일한지 확인한다(3410). 그리고 ID와 공개키에 대한 인증서의 서명을 확인한다(3411). 서명이 확인되면 UpNumECC와 TSM으로부터 받은 인증서를 비휘발성 메모리에 저장한다(3413).
* 오류 처리(인증서 오류) : 인증서 오류(ID, 공개키, 서명 오류) 발생 시 폐기(3412)가 있을 수도 있지만, 칩은 인증서 오류 메시지(ERR_REG_CERT)를 TSM에게 보내 인증서를 재요청하여 과정을 반복할 수도 있다. 갱신이 끝나면 칩은 공개키 갱신에 사용된 1증가된 UpNumECC와 새로 갱신한 공개키에 대한 TSM의 인증서를 비휘발성 메모리에 가지고 있게 된다. 그리고 단계(3414)와 단계(3415)를 거쳐 갱신 프로토콜을 마무리된다.
재발급 프로토콜
갱신 시엔 새 공개키를 기존의 개인키로 서명함으로써 새 공개키가 칩의 것임을 보장하였다. 그러나 유효 기간 만료가 한참 지난 경우엔 기존의 개인키를 더 이상 사용할 수 없으므로 발급 기관에서 칩을 다시 재발급 받아야 하며, 자세한 프로토콜은 다음과 같다.
ⓐ 유효 기간 확인 요청 : 카드 삽입(3501) 후 칩은 재발급 상태인지 모르므로 갱신과 마찬가지로 ID와 랜덤 수(RN)를 생성(3502)하여 함께 송신하는 명령을 발급기기로 전달한다. 발급기기는 이를 받아 TSM에게 재발급 명령을 요청한다.
ⓑ 재발급 요청 : TSM은 갱신 요청과 비슷한 방식으로 ID와 수신한 랜덤 수, 그리고 재발급 코드(ISSUE)를 TSM의 개인키로 서명(3503)하여 재발급 요청 메시지에 덧붙인다.
ⓒ 재발급 요청 확인 : 칩은 CRC와 ID, 서명을 확인한 후(3504 내지 3506) UpNumECC를 1증가시킨다(3507).
* 오류 처리(CRC오류) : 칩이 발급기기로부터 받은 메시지에 CRC 오류가 있을 경우 오류 메시지(ERR_REPUK)을 송신하여 ID, 서명을 다시 받는다.
* 오류 처리(ID 오류) : 칩이 TSM으로부터 받은 ID가 자신의 것이 아니라면 오류 메시지(ERR_REPUK)로 응답한다. TSM은 ID를 확인하고 맞다면 재발급 요청 메시지(REQ_REPUK)부터 반복한다.
* 오류 처리(서명 오류) : 칩이 TSM으로부터 받은 서명이 유효하지 않을 경우 오류 메시지(ERR_REPUK)로 응답한다. TSM은 기존 갱신 요청 메시지(REQ_REPUK)를 재전송하거나 서명 생성부터 반복한다.
그리고 여기서 상술한 도 3c로 설명한 발급 프로토콜의 ⓕ 내지 ⓗ가 반복된다.
ⓓ (발급의 ⓕ) 공개키 생성 및 전달(3301) : ID, PUF, 갱신 정보를 바탕으로 공개키 쌍을 생성하여 그 중 공개키는 발급기기로 전달하고 발급기기는 이를 TSM으로 전달한다. 이 구간은 신뢰되는 것으로 간주하며 통신상의 오류를 배제할 수 있도록 CRC 코드를 덧붙인다.
* 오류 처리(CRC 오류) : 발급기기가 칩으로부터 받은 메시지에서 CRC 오류 발생 시(3302) 오류 메시지(ERR_PUK)를 송신하여 칩의 공개키를 다시 전송 받는다. 오류 반복 시 칩을 폐기(Disuse)(3303) 시킬 수 있다.
ⓔ (발급의 ⓖ) 인증서 발급 : TSM은 CRC 검사(3304), 칩의 공개키의 유효성 검사(3305)를 수행한다. 그리고 수신한 공개키에 자신의 개인키로 서명한 인증서를 생성(3307)하여 발급기기로 전달하고 발급기기는 이를 칩에게 전달한다. 이 경우에도 발급 시와 마찬가지로 필요에 따라 다양한 추가 정보(이를테면, 발급기관, 유효기간)들이 함께 추가될 수 있다.* 오류 처리(CRC 오류) : TSM이 발급기기로부터 받은 메시지에서 CRC 오류 발생 시 발급기기는 칩에게 CRC 오류 메시지(ERR_CERT)로 응답하여 재전송을 요청한다.
* 오류 처리(공개키 오류) : TSM이 발급기기로부터 받은 칩의 공개키(QChip)가 유효하지 않을 경우 오류 메시지(ERR_CERT)로 응답하여 칩의 공개키를 재요청한다. 발급기기는 이를 받아 오류 메시지(ERR_PUK)를 칩에게 전달한다. 오류 반복 시 칩을 폐기(Disuse)(3306) 시킬 수 있다.
* 오류 처리(CRC 오류) : 발급기기가 TSM으로부터 받은 메시지에서 CRC 오류 발생 시(3308) 발급기기는 TSM에게 인증서 요청 메시지(REQ_CERT)를 다시 전송한다.
ⓕ (발급의 ⓗ) 인증서 검증 : 칩은 CRC를 검사하고(3309) 인증서에 포함된 ID와 공개키가 자신의 것과 동일한지 확인한다. 그리고 ID와 공개키에 대한 인증서의 서명을 확인한다(3310). 서명이 확인되면 UpNumECC와 TSM으로부터 받았던 새 인증서를 비휘발성 메모리에 저장한다(3313).
* 오류 처리(CRC 오류) : 칩이 발급기기로부터 받은 메시지에서 CRC 오류 발생 시(3311) 칩은 발급기기에 CRC 오류 메시지(ERR_REG_CERT)로 응답하여 재전송을 요청한다. 재전송 후 에러처리이면 폐기(3312) 가능하다.
* 오류 처리(인증서 오류) : 인증서 오류(ID, 공개키, 서명 오류) 발생 시 칩은 인증서 오류 메시지(ERR_REG_CERT)를 발급기기에게 보내고 발급기기는 TSM에게 보내 인증서를 재요청(REQ_CERT)하고 이 후에 단계(3508)에서 도 3c에서 설명한 내용이 수행된다. 이것은 도 3c를 참조하여 설명한 발급 과정의 ⓕ 내지 ⓗ이다. 이 부분이 수행된 이후 다시 도 3e의 마무리 단계로 돌아간다. 재발급 결과 1증가한 UpNumECC와 새로 발급받은 인증서(R’, S’)가 새롭게 저장된다(3507). 발급 프로토콜과 마찬가지로 발급 단계에서는 공격자의 개입이 불가능하다고 가정한다.
사용 프로토콜
도 3f를 참조하여 설명한다. 사용 프로토콜은 TSM과 상호 인증을 수행하여 core로 하여금 secure mode의 권한을 수여하는 프로토콜이다. 도 3a에서 설명되는 인증 과정을 수행하는 예시적 프로토콜이다.
ⓐ 유효 기간 확인 요청 : 갱신, 재발급 프로토콜과 동일하게 ID와 랜덤 수(RN)를 생성(3601)하여 TSM에게 전달하며 프로토콜이 시작한다.
ⓑ 유효 기간 확인 및 세션 요청 : TSM이 유효 기간을 확인한다(3602). 유효 기간이 남아 있는 경우 칩과 키를 공유하기 위한 ECDH 과정으로 임시 키 쌍(a, A)를 생성한다. 그리고 이를 TSM의 개인키로 서명하여 칩에게 전달한다.
ⓒ 공유키 생성 : 칩은 수신한 ID를 확인하고(3603), 수신한 공개키(A)의 유효성, 그리고 서명의 유효성을 확인한다(3604 및 3605). 그리고 ECDH 과정으로 칩의 임시 키 쌍(b, B)를 생성한다. 그리고 TSM으로 받은 임시 공개키(A)와 칩이 생성한 임시 개인키(b)를 이용하여 공유 비밀정보(W)를 만들고 이를 키 유도 함수(Key derivation function)로 확장하여 공유 비밀키(K1, K2, IV)를 생성한다(3606). 생성한 공개키와 이에 대해 칩의 개인키로 서명한 서명, 그리고 hand shake를 위해 공유 비밀키로 암호화한 정보(C1)를 TSM에게 전달한다(3607 내지 3608).
* 오류 처리(ID 오류) : 칩이 TSM으로부터 받은 ID가 자신의 것이 아니라면 오류 메시지(ERR_SESSION)로 응답한다. TSM은 ID를 확인하고 맞다면 세션 요청 메시지(REQ_SESSION)부터 반복한다.
* 오류 처리(공개키 오류) : 칩이 TSM으로부터 받은 공개키가 유효하지 않은 경우 오류 메시지(ERR_SESSION)로 응답한다. TSM은 세션 요청 메시지(REQ_SESSION)부터 반복한다.
* 오류 처리(서명 오류) : 칩이 TSM으로부터 받은 서명이 유효하지 않은 경우 오류 메시지(ERR_SESSION)로 응답한다. TSM은 서명 생성을 다시 하거나 세션 요청 메시지(REQ_SESSION)부터 반복한다.
ⓓ　Hand shake : TSM은 수신한 공개키(B)의 유효성과 서명의 유효성을 확인한다(3609 및 3610). 그리고 전달받은 칩의 공개키(B)와 TSM에서 생성하였던 임시 개인키(a)를 이용하여 공유 비밀정보(W)를 만들고 이를 키 유도 함수(Key derivation function)으로 확장하여 공유 비밀키(K1, K2, IV)를 생성한다(3611). 이를 이용하여 C1을 복호화함으로써 칩이 동일한 공유 비밀키들을 생성하였음을 확인한다. TSM 또한 공유 비밀키로 암호화한 정보(C2)를 칩에게 전달한다(3612).
* 오류 처리(공개키 오류) : TSM이 칩으로부터 받은 공개키가 유효하지 않은 경우 오류 메시지(ERR_HS)로 응답한다. 칩은 hand shake 요청 메시지(REQ_HS)부터 반복한다.
* 오류 처리(서명 오류) : TSM이 칩으로부터 받은 서명이 유효하지 않은 경우 오류 메시지(ERR_HS)로 응답한다. 칩은 서명 생성을 다시 하거나 hand shake 요청 메시지(REQ_SESSION)부터 반복한다. 만약 서명 오류가 반복될 경우 hand shake 과정을 멈추고 인증 실패를 위한 오류 메시지(ERR_HS)를 인증 실패 코드(ER_AUTH)와 함께 보내 인증 결과를 실패(FAuth = Fasle)로 설정하도록 한다.
* 오류 처리(Hand shake 오류) : TSM이 칩으로부터 받은 C1의 확인 결과 실패할 경우 오류 메시지(ERR_HS)로 응답한다. 비밀키 생성이나 C1 생성부터 다시 수행한다.
ⓔ Hand shake2 : 칩은 수신한 C2를 복호화하여 확인함으로써 TSM 또한 동일한 공유 비밀키들을 생성하였음을 확인한다(3613).
* 오류 처리(Hand shake 오류) : 칩이 TSM으로부터 받은 C2의 확인 결과 실패할 경우 오류 메시지(ERR_HS)로 응답한다. 공유 비밀키 생성이나 C2 생성부터 다시 수행한다.
위 과정에서 서로 주고받은 서명을 통해 서로를 인증할 수 있으며, 공유된 비밀키(K1, K2, IV)는 향후 TSM과 통신 시 암호화 키, MAC용 키, initial vector로 각각 활용하게 된다. 인증이 성공적으로 수행된 경우 secure mode에 대한 권한을 부여한다(FAuth = True)(3614).
이상이 Pre-authentication의 수행, 발급, 갱신, 재발급, 사용 각각의 구체적 프로토콜이다. 이러한 과정을 통해 Pre-authentication 인증부가 장치와 TSM에 이르는 하드웨어를 인증하게 된다.
하드웨어의 소프트웨어 인증
기존의 TrustZone 등의 TEE(Trusted Execution Environment)에서 플랫폼의 무결성을 보장하기 위하여 secure booting 기능을 포함하고 있다. 이는 OS 이미지 자체가 오염된 상태로 시스템이 시작하는 것을 방지하기 위한 것으로, 부팅 시 OS 이미지의 무결성을 확인 후 실행함으로써 플랫폼이 무결한 상태에서 시작할 수 있도록 하는 기술이다.
도 4는 일실시예에 따르면 이러한 보안 부팅(secure booting)의 흐름을 설명하기 위한 흐름도이다. 디바이스가 파워-온(410)되면, ROM의 SoC 부트로더(420)가 가장 먼저 실행되어 권한을 가진다. bootloader는 on-SoC ROM에 저장되어 있어 수정이 불가능하므로 신뢰 근원(Root of trust)으로서 secure booting 절차의 근간이 된다. 또한 on-SoC 하드웨어는 TSM 인증기관의 공개키를 수정이 불가능한 OTP 형태 등으로 가지고 있다. 부트로더(420)는 이 공개키를 이용하여 플래시 디바이스 부트로더(flash device bootloader)(430)의 서명을 검증함으로써 무결함을 확인하게 되고, 그 후 플래시 디바이스 부트로더(430)에게 권한을 주어 실행될 수 있게 한다. 권한을 넘겨받은 플래시 디바이스 부트로더(430)는 secure world OS의 이미지의 서명을 검증함으로써 무결함을 확인하게 되고 이를 실행(시큐어 부팅)시키게 된다(440). 이러한 과정을 뒤에서도 반복하면서 normal world 부트로더(450)가 권한을 받아 normal world OS를 부팅하고(460) 시스템이 구동된다. 수정이 불가능하여 무결성이 보장된 하드웨어 차원의 신뢰 근원으로부터 스텝 바이 스텝으로 소프트웨어 인증을 수행하면서 앞으로 나아가는 이러한 과정을 신뢰 체인이라고 한다.
이러한 방식으로 하드웨어는 하드웨어에서 수행될 소프트웨어를 신뢰 체인으로 인증하고, 도 3a 내지 3f를 참고하여 설명한 것처럼 소프트웨어도 하드웨어를 인증하여 상호 인증이 수행되는 것이다.
PUF를 이용한 보안의 강화
실시예에 따른 PUF(Physical Unclonable Function)는 반도체 제조과정에서 발생하는 공정편차를 이용하여 칩 고유의 true random bit을 생성할 수 있다. 반도체 제조과정에서 발생하는 공정편차는 칩 마다 상이하므로, 칩의 대량 생산 시 PUF는 칩의 고유 ID로 활용될 수 있으며, 이를 이용하면 암호/복호화, 메모리 보호, 전자서명 등에 활용되는 근원 키(root key)가 제공될 수 있다.
이러한 PUF의 값은 칩 외부로 유출되기 어려워 신뢰-근원(Root-of-Trust)으로서 최상위 보안등급을 제공할 수 있다. 현재 대륙간탄도미사일(ICBM) 등 군사용 무기, 차량용 보안시스템(HSM), 스마트 폰의 AP, 스마트카드 등의 많은 응용분야에서 PUF를 보안에 이용하기 위한 표준화 및 상용화가 진행되고 있다.
도 5는 일실시예에 따른 PUF의 구현을 설명하기 위한 개요도이다. 예시적인 구현으로서, 이에 한정되는 것은 아님에 유의해야 한다. 일실시예에 따르면 PUF는 통상적인 디자인 룰(도시된 예에서는 250nm*250nm)에서 정한 via hole size보다 작은 via hole을 디자인하여 제조된 비아(또는 인터-레이어 컨택) 어래이를 갖는다. 이 경우 via hole 어래이에서 open과 short가 random하게 분포되며, 이는 무작위적(random)이고 실질적으로 시간 불변인 (invariant over time) 디지털 값을 제공할 수 있다. 제시된 실시예에 따라 제조된 VIA PUF는 공인평가기관에서 JEDEC 표준에 따른 다양한 테스트를 통과하여 Reliability가 검증되었고, 램덤성도 NIST 표준인 SP 800-90B의 true random number testing suite를 통과하였다.
추가적인 실시예의 설명
도 6은 일실시예에 따라 물리적 공격으로부터 근본적으로 보호되는 보안 SoC 플랫폼을 도시한다.
보안 코어(601)에 연결되어 REE 환경의 컴퓨팅을 수행하는 일반 버스(610) 외에 secure world를 위한 히든 버스(620)가 제공된다. SRAM(611)이나 Peripheral IP들(612)가 일반 모드에서 동작하는 중 보안 모드 실행이 필요한 경우에는 보안 ISA를 통해 명령어 수준에서 보안 IP들(621)이 동작할 수 있다.
일실시예에 따르면 보안 코어(601)는 메모리 영역을 코드 영역과 데이터 영역으로 분할한다. 분할되는 메모리 영역은 normal world의 것일 수도 있으나, 다른 실시예에서는 secure world의 것일 수도 있다. 보안 코어(601)는 상기 코드 영역에는 쓰기(write)를 금지하고, 데이터 영역에서는 실행(execution)을 금지시키는 메모리 보호 유닛(Memory Protection Unit, MPU) 을 포함할 수 있다. 여기서 상기 코드 영역과 상기 데이터 영역은 상기 Core-A 프로세서의 ASR에 대한 명령어를 이용하여 처리되는 보안 명령어에 의해 설정될 수 있다. 나아가, 상기 코드 영역과 상기 데이터 영역 외에 시스템 영역도 설정될 수 있다.
영역\모드 U/N U/S P/N P/S
코드 영역 RX RX RWX RWX
데이터 영역 RW RW RW RW
시스템 영역 - - RWX RWX
위 표에서 모드 "U"는 User mode를 의미하고, "P"는 Privilege mode를 의미한다. 그리고 "N"은 Normal mode를, "S"는 Secure mode를 의미한다. 코드 영역 별로 허용되는 동작이 제시되어 있다. 이를테면, 유저 모드이고 일반 모드일 때는 R인 읽기, 그리고 X인 실행(eXecution)은 가능하나, 쓰기 W는 허용되지 않는다.
한편, 일실시예에 따르면 상기 프로세서 코어는 코드 시퀀스에 포함되는 리턴 어드레스를 백업하는 하드웨어 기반 섀도우 스택을 포함할 수 있다. 이 경우, 상기 섀도우 스택은 기존의 메모리 상에 상주하는 스택과는 별도로 동일 또는 별도의 추가된 메모리, 또는 별도의 추가된 레지스터 등에 위치할 수 있다. 상기 섀도우 스택은 버스를 사용하지 않고, OS나 소프트웨어에 의해 접근되지 않으며, 추가된 하드웨어 기반 제어 회로에 의해 메모리 스택 관련 명령 수행 시 자동으로 수행되어 상기 리턴 어드레스를 이중으로 관리할 수 있다. 섀도우 스택을 이용한 리턴 어드레스의 이중 관리로, 소프트웨어 공격으로 인해 기존의 메모리 상에 상주하는 스택에 저장되어 있는 리턴 어드레스가 변경되는 것을 감지할 수 있다. 섀도우 스택은 하드웨어 회로로만 제어되고 소프트웨어로 접근 불가능하므로 섀도우 스택에 저장된 내용을 변경하려는 공격도 원천적으로 차단할 수 있다. 위에서 설명한 섀도우 스택은 리턴 어드레스를 이중으로 관리하는 예시적 구성이며, 리턴 어드레스를 주기적으로 백업해 이중으로 관리하는 스택이면 특정한 예시적 구현에 한정되는 것은 아니다.
시스템 부팅 시 동작
도 7 내지 도 8은 일실시예에 따른 SoC의 동작을 설명하기 위한 흐름도이다. 일실시예에 따르면 디바이스 파워-온 시 인증서 서버로부터 인증을 받는 절차(710)가 수행된다. 여기서 하드웨어 기반 인증부인 pre-authentication IP가 말단간 상호인증을 통해 외부 인증서 서버와 통신하는 내용은 도 3a를 통해 상술한 바와 같고, 이 과정에서 PUF가 이용되는 것은 도 5를 참조하여 설명하였다.
단계(720)에서 인증에 성공한 경우라면, Secure ISA가 사용 가능하도록 관리되고(730), 디버깅 포트 접근이 가능해지고 secure world OS가 부팅된다(740). 그리고 이어서 노말 모드 부팅을 통해 시스템은 구동 가능하게 된다(750).
그러나, 단계(720)에서 인증에 실패하는 경우라면, 도 8의 단계(810)에서 secure world는 접근 불가능하게 된다. 그리고 노말 월드만 부팅되어 REE 환경의 컴퓨팅 구동만 가능해질 수 있다. 이러한 과정에 대해서는 도 1, 도 2 및 도 4 등을 참조하여 상술한 바와 같다.
이상에서 설명된 장치는 메모리의 하드웨어 구성요소, 메모리를 제어 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPA(field programmable array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다.
소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치, 또는 전송되는 신호 파(signal wave)에 영구적으로, 또는 일시적으로 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.
실시예에 따른 메모리 동작 제어 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 실시예의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
실시예들이 비록 한정된 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다. 그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims (19)

  1. 반도체 칩에 있어서,
    프로세서 코어; 및
    외부 신뢰 기관과 상호 인증을 수행하여 상기 반도체 칩 및 상기 외부 신뢰 기관 사이의 인증을 수행하는 인증부
    를 포함하는 반도체 칩.
  2. 제1항에 있어서,
    상기 프로세서 코어에 제1 버스를 통해 연결되는 엘리먼트들을 포함하는 제1 그룹; 및
    상기 프로세서 코어에 제2 버스를 통해 연결되며 보안 모드에서 동작하는 엘리먼트들을 포함하는 제2 그룹
    을 더 포함하는 반도체 칩.
  3. 제2항에 있어서,
    상기 인증부가 상기 인증에 성공한 경우에만 상기 제2 그룹을 사용 가능하도록 활성화 하는 반도체 칩.
  4. 제2항에 있어서,
    상기 제2 그룹은 Cryptographic IP, secure SRAM, secure DMA 및 boot ROM 중 적어도 하나를 포함하는 반도체 칩.
  5. 제1항에 있어서,
    상기 인증부가 상기 외부 신뢰 기관과 상기 상호 인증을 수행하는 데에 이용되는 키를 제공하는 PUF를 더 포함하는 반도체 칩.
  6. 제2항에 있어서,
    상기 제2 그룹은 상기 제1 그룹과 상이한 메모리 어드레스를 이용하여 데이터를 처리하는 반도체 칩.
  7. 제2항에 있어서,
    상기 프로세서 코어는 32 비트 RISC(Reduced Instruction Set Computing) 타입의 임베디드 프로세서인 Core-A 프로세서를 포함하는 반도체 칩.
  8. 제7항에 있어서,
    상기 제2 버스는 상기 Core-A 프로세서의 ASR (Application Specific Register)을 상기 제2 그룹에 포함되는 엘리먼트를 제어하는 주소 공간으로 사용하여 구현되는 히든 버스를 포함하는 반도체 칩.
  9. 제8항에 있어서,
    상기 제2 그룹은 상기 보안 모드에서 상기 ASR에 대한 데이터 처리 명령인 MTA(Move to ASR) 명령과 MFA(Move from ASR) 명령어를 보안 명령어(secure instruction) 처리에 이용하는 반도체 칩.
  10. 제1항에 있어서,
    상기 인증부는 하드웨어 로직이며, 기존의 컴퓨팅 언어와 상이한 독자 언어로 구동되어 상기 인증 절차를 수행하는 반도체 칩.
  11. 제10항에 있어서,
    상기 인증부는 기존의 컴퓨팅 언어와 상이한 독자 언어로 구성되는 인증 절차를 수행하는 반도체 칩.
  12. 제11항에 있어서,
    상기 인증부는 ROM이나 상기 반도체 칩 내의 IP와 다르게 일반 셀로 구성되는 반도체 칩.
  13. 소프트웨어를 임베드한 하드웨어 장치에 있어서,
    상기 소프트웨어를 구동하는 프로세서 코어; 및
    상기 하드웨어 장치를 통해 상기 소프트웨어를 구동하기 위해 외부 신뢰 기관과 상호 인증을 수행하여 상기 반도체 칩 및 상기 외부 신뢰 기관 사이의 인증을 수행하는 인증부
    를 포함하는 장치.
  14. 제13항에 있어서,
    상기 반도체 칩은 상기 프로세서 코어에 노말 모드에서 동작하는 엘리먼트들을 포함하는 제1 그룹을 연결하는 제1 버스; 및
    상기 프로세서 코어에 보안 모드에서 동작하는 엘리먼트들을 포함하는 제2 그룹을 연결하는 제2 버스
    를 더 포함하는 장치.
  15. 제14항에 있어서,
    상기 인증부가 상기 인증에 성공한 경우에만 상기 제2 그룹을 사용 가능하도록 제2 버스로의 접근을 활성화 하는 장치.
  16. 제13항에 있어서,
    상기 인증부가 상기 외부 신뢰 기관과 상기 상호 인증을 수행하는 데에 이용되는 키를 제공하는 PUF를 더 포함하는 장치.
  17. 반도체 칩의 동작 방법에 있어서,
    인증부가 외부 신뢰 기관과 상호 인증을 수행하는 단계; 및
    상기 인증이 성공하는 경우에 상기 반도체 칩의 보안 모드를 활성화하는 단계
    를 포함하는 방법.
  18. 제17항에 있어서,
    상기 반도체 칩은 상기 프로세서 코어에 노말 모드에서 동작하는 엘리먼트들을 포함하는 제1 그룹을 연결하는 제1 버스; 및 상기 프로세서 코어에 보안 모드에서 동작하는 엘리먼트들을 포함하는 제2 그룹을 연결하는 제2 버스를 더 포함하고,
    상기 방법은 상기 인증이 성공하는 경우에 상기 제2 그룹 및 상기 제2 버스를 활성화 하고, 상기 인증이 실패하는 경우에 상기 제2 그룹 및 상기 제2 버스를 비활성화 하고 상기 제1 그룹 및 상기 제1 버스를 활성화 하는 방법.
  19. 제18항에 있어서,
    상기 제2 그룹은 Cryptographic IP, secure SRAM, secure DMA 및 boot ROM 중 적어도 하나를 포함하는 방법.
PCT/KR2017/001560 2016-02-12 2017-02-13 하드웨어 디바이스 및 그 인증 방법 WO2017138799A1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201780010962.7A CN108604275A (zh) 2016-02-12 2017-02-13 硬件装置及其认证方法
US16/075,951 US20190253417A1 (en) 2016-02-12 2017-02-13 Hardware device and authenticating method thereof

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR20160016587 2016-02-12
KR10-2016-0016587 2016-02-12
KR1020170019497A KR20170095163A (ko) 2016-02-12 2017-02-13 하드웨어 디바이스 및 그 인증 방법
KR10-2017-0019497 2017-02-13

Publications (1)

Publication Number Publication Date
WO2017138799A1 true WO2017138799A1 (ko) 2017-08-17

Family

ID=59563324

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/001560 WO2017138799A1 (ko) 2016-02-12 2017-02-13 하드웨어 디바이스 및 그 인증 방법

Country Status (1)

Country Link
WO (1) WO2017138799A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110932842A (zh) * 2018-09-19 2020-03-27 微安科技有限公司 用于执行虚拟专用网络功能的片上系统及包含该片上系统的系统
CN112948855A (zh) * 2021-03-03 2021-06-11 深圳市建讯电子有限公司 集成式处理器芯片、应用程序终端及终端设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060015947A1 (en) * 2004-07-01 2006-01-19 Conti Gregory R P System and method for secure mode for processors and memories on multiple semiconductor dies within a single semiconductor package
KR101118826B1 (ko) * 2011-02-15 2012-04-20 한양대학교 산학협력단 물리적 공격을 방어하는 암호화 장치 및 암호화 방법
KR20130019358A (ko) * 2011-08-16 2013-02-26 (주) 아이씨티케이 사물지능통신에서 ｐｕｆ에 기반한 장치간 보안 인증 장치 및 방법
KR20140114263A (ko) * 2013-03-13 2014-09-26 삼성전자주식회사 어플리케이션 인증 방법 및 이를 구현하는 전자 장치
KR101477080B1 (ko) * 2006-09-13 2014-12-29 에이알엠 리미티드 메모리 액세스 보안 관리

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060015947A1 (en) * 2004-07-01 2006-01-19 Conti Gregory R P System and method for secure mode for processors and memories on multiple semiconductor dies within a single semiconductor package
KR101477080B1 (ko) * 2006-09-13 2014-12-29 에이알엠 리미티드 메모리 액세스 보안 관리
KR101118826B1 (ko) * 2011-02-15 2012-04-20 한양대학교 산학협력단 물리적 공격을 방어하는 암호화 장치 및 암호화 방법
KR20130019358A (ko) * 2011-08-16 2013-02-26 (주) 아이씨티케이 사물지능통신에서 ｐｕｆ에 기반한 장치간 보안 인증 장치 및 방법
KR20140114263A (ko) * 2013-03-13 2014-09-26 삼성전자주식회사 어플리케이션 인증 방법 및 이를 구현하는 전자 장치

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110932842A (zh) * 2018-09-19 2020-03-27 微安科技有限公司 用于执行虚拟专用网络功能的片上系统及包含该片上系统的系统
CN110932842B (zh) * 2018-09-19 2023-07-04 微安科技有限公司 用于执行虚拟专用网络功能的片上系统及包含该片上系统的系统
CN112948855A (zh) * 2021-03-03 2021-06-11 深圳市建讯电子有限公司 集成式处理器芯片、应用程序终端及终端设备
CN112948855B (zh) * 2021-03-03 2024-03-19 深圳市建讯电子有限公司 集成式处理器芯片、应用程序终端及终端设备

Similar Documents

Publication Publication Date Title
KR20170095163A (ko) 하드웨어 디바이스 및 그 인증 방법
US9910990B2 (en) Security controlled multi-processor system
US8788840B2 (en) Secure processor
JP4774049B2 (ja) セキュアなプラットフォーム間およびプラットフォーム内通信のための方法およびプログラム
US10318765B2 (en) Protecting critical data structures in an embedded hypervisor system
US10498712B2 (en) Balancing public and personal security needs
AU2020244511B2 (en) Balancing public and personal security needs
KR20090109589A (ko) 프로세서 내에서의 보호된 리소스들로의 억세스에 대한 안전한 보호 방법
TWI745629B (zh) 電腦系統以及初始化電腦系統的方法
KR20090078551A (ko) 이동 저장 장치에서 호스트 인증 방법, 호스트 인증을 위한정보 제공 방법, 장치, 및 기록매체
US20090064273A1 (en) Methods and systems for secure data entry and maintenance
US20060005015A1 (en) System and method for secure inter-platform and intra-platform communications
US10452565B2 (en) Secure electronic device
WO2017138799A1 (ko) 하드웨어 디바이스 및 그 인증 방법
US20230409700A1 (en) Systems and methods for managing state
WO2017138797A1 (ko) 시큐어 시스템 온 칩
Vaswani et al. Confidential machine learning within graphcore ipus
US11405201B2 (en) Secure transfer of protected application storage keys with change of trusted computing base
WO2023145240A1 (ja) 情報処理装置および情報処理システム
CA3042984C (en) Balancing public and personal security needs
KR20070017455A (ko) 프로세서 내에서의 보호된 리소스들로의 억세스에 대한안전한 보호 방법
CN110059489A (zh) 安全电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17750491

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17750491

Country of ref document: EP

Kind code of ref document: A1