WO2017138797A1 - 시큐어 시스템 온 칩 - Google Patents
시큐어 시스템 온 칩 Download PDFInfo
- Publication number
- WO2017138797A1 WO2017138797A1 PCT/KR2017/001554 KR2017001554W WO2017138797A1 WO 2017138797 A1 WO2017138797 A1 WO 2017138797A1 KR 2017001554 W KR2017001554 W KR 2017001554W WO 2017138797 A1 WO2017138797 A1 WO 2017138797A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- secure
- group
- security
- bus
- authentication
- Prior art date
- Legal status (The legal status 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 status listed.)
- Ceased
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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
- SoC System on Chip
- a technique for preventing a security attack in a hardware module is known.
- recent processors use ARM TrustZone technology to increase security.
- TrustZone technology one physical processor core is separated into virtual cores, the normal world and the secure world. In CPU, memory, memory address address translation, etc., they are distinguished from each other. Some applications or tasks are more secure because they are isolated on only one side.
- the present invention is to provide a secure system on a chip that can be operated in a safe environment by preventing a security attack.
- a processor core A first group comprising elements coupled to the processor core via a first bus; And a second group coupled to the processor core via a second bus and including elements operating in a secure mode.
- the second bus is physically separated from the first bus, and the second group is physically isolated from the first group.
- the second group may process 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. This may be understood to implement a hidden bus for secure IPs included in the second group using the ASR interface.
- MTA Move to ASR
- MFA Move from ASR
- the processor core may be a RISC V ISA applied CPU core.
- the processor core divides a memory area into a code area and a data area, prohibits writing to the code area, and the data area includes a memory protection unit (MPU) prohibiting execution.
- the code area and the data area may be set by a security command processed using the 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.
- the processor core may include a shadow stack for backing 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.
- the semiconductor chip may further include an authentication unit performing mutual authentication with an external trust authority during power-on of the semiconductor chip.
- the semiconductor chip may make the second group available only when the authentication is successful.
- the security mode is performed when the authentication is successful and the second group is available, and when the first group is operating in normal mode, there is a security breach event or when there is a call for which elevated security handling should be handled. Can be.
- this security mode at least part of the second group may be operated by a security command to perform a predetermined function.
- it includes at least one of Cryptographic IP, secure SRAM, secure DMA, and boot ROM.
- the semiconductor chip may further include a physical unclonable function (PUF) that provides a source key used by the authentication unit to perform the mutual authentication with the external trust authority.
- PUF physical unclonable function
- PUF may be included intrinsic into the semiconductor chip using process variations in the semiconductor manufacturing process.
- 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. .
- a method of operating a semiconductor system on chip includes: authenticating the mutual authentication with an external trust authority; If the authentication is not successful, activating a first group including elements connected to a processor core via a first bus and deactivating elements connected to the processor core via a second bus and operating in a secure mode. It may include.
- the second group may be a secure IP group including at least one of Cryptographic IP, secure SRAM, secure DMA, and boot ROM.
- the source key used for the authentication unit to perform the mutual authentication with the external trust authority may be provided from a PUF included in the semiconductor system on chip.
- the method may further include a method in which the first group is in operation while the authentication is successful and the second group is available, and there is a call that a security breach event occurs or an elevated security handling must be handled.
- the method may further include operating at least a part of the second group by performing the security mode.
- the processor core may include a hardware-based shadow stack that does not use a bus and is not accessed by an OS or software and backs up a return address included in a code sequence.
- the method may further include detecting, by the processor core, an attack by backing up the return address when performing a memory stack related instruction and comparing with a return address stored in a stack on an existing memory.
- a SoC platform that can be operated in a safe environment by preventing a security attack can be provided.
- FIG. 1 is a block diagram of an SoC device according to an embodiment.
- FIGS. 2A and 2B show an SoC structure according to one embodiment.
- 3A and 3B are diagrams for describing an authentication process and detailed processing 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 illustrating an operation of a SoC according to an exemplary embodiment.
- 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 SoC 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.
- a secure bus may be a hidden bus implemented using the Application Specific Register (ASR) of the Core-A processor as an address space for control of 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 secure mode management different 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, the proposed study can access resources in the secure world directly 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.
- the main features of the security ISA according to the 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
- the security ISA is granted only to authorized users. This authentication process and detailed processing will be described with reference to FIGS. 3A and 3B. As described above, there is a portion 310 within the SoC 300 that handles authentication and operates in a secure mode.
- the hardware-based authentication unit pre-authentication IP 301 may communicate with the external certificate server 301 through end-to-end mutual authentication when the power is turned on or after the reset.
- such mutual authentication may be by public key cryptography using a source key generated by the PUF 303.
- 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 generates a private key from the VIA-PUF 303 and transfers 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.
- supporting TEE in the end SoC requires a secure CPU core design with new features in ISA.
- Core-A is a 32-bit CPU core and free of charge, making it a good starting point for developing a secure core.
- Core A has the following characteristics:
- the original five-stage pipelined Core-A CPU uses a GCC-based Core-A compiler to perform similarly to the ARM9E-S CPU on the EEMBC CoreMark Benchmark.
- Core-A's ASR interface can be used as a scratch-pad memory for storing frequently used data or as a Transaction Memory Mapped Interface similar to AMBA AXI-Lite.
- the address space of the ASR is not included in the main memory area. It is physically separated from the main memory interface and can be used only through specific instructions.
- the embodiment presented here uses the ASR interface as a hidden security bus for secure IP access.
- Core-A is widely used by fabless companies in Korea.
- Core-A is supported by Dynalith System, and by default Core-A is open source, and Core-A's ISA is free to use. Embodiments may be understood as customizing and extending the ISA of Core-A.
- FIG. 4 is a flowchart illustrating a flow of secure booting according to an embodiment. See FIG. 4 for explanation.
- Secure booting This is to ensure the integrity of the entire software image to be performed next. It can prevent unauthorized or maliciously modified software from being executed.
- the SoC bootloader 420 of the ROM boots the secure world OS, whose integrity is verified, via the flash device bootloader 430 with authority.
- the normal world boot loader 450 receives the permission to boot the normal world OS (460) and the system is driven.
- the progression of the later stages inherits the integrity verification of the previous stages sequentially, thereby preventing the attack from intervening.
- the security ISA since the security ISA according to the embodiments supports secure booting while making the entire process non-preemptive, an attempt such as a time-of-check to time-of-use (TOCTTOU) attack can be prevented.
- TOCTTOU time-of-check to time-of-use
- the hidden ASR interface of Core-A is used as a hidden bus used only in secure mode. These hidden buses are intended for the secure world, which physically completely separates access paths to the secure world, such as secure IP, on-chip boot ROM, and secure SRAM, from the main memory interface / bus.
- DMA Security Direct Memoty Access
- PUF-based secure storage space Secure data stored in nonvolatile memory is encrypted using VIA-PUF as the root key.
- 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 for dually managing the return address, and the shadow stack is updated from time to time every time there is an update of the return address, and the stack is not limited to a 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 SoC device and platform described above may be implemented as a hardware component, a control software component, and / or a combination of hardware 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.
- the operating method of the SoC according to the embodiment may be implemented in the form of program instructions that may be executed by various computer means and may be recorded in 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.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
Abstract
보안 반도체 칩이 제시된다. 반도체 칩은 이를 테면 시스템 온 칩이다. 시스템 온 칩에 포함되는 프로세서 코어에는 시스템 버스를 통해 통상의 IP들이 연결되어 동작한다. 상기 시스템 버스와 물리적으로 구분되는 히든 버스인 보안 버스가 별도로 제공된다. 보안 버스에는 보안 기능을 수행하거나 보안 데이터를 취급하는 보안 IP들이 연결된다. 보안 반도체 칩은 일반 모드와 보안 모드를 바꾸어 가며 필요한 인증을 수행할 수 있다.
Description
시스템 온 칩(System on Chip: SoC) 구조 및 그 운용 방법에 연관되며, 보다 특정하게는 보안 공격을 방지할 수 있는 시큐어 SoC의 하드웨어 구조와 운용에 연관된다.
보안 공격을 방지하기 위해 하드웨어 모듈에서 보안 공격 방지를 하는 기술이 알려져 있다. 예를 들어, 최근 프로세서들에는 보안을 강화하기 위해 ARM TrustZone 기술이 사용되고 있다. TrustZone 기술에서는 하나의 물리적 프로세서 코어를 가상 코어(virtual core)들인 Normal world와 Secure world로 분리하여 운용한다. CPU, 메모리, 메모리 어드레스 주소 변환 등에 있어서 이 둘은 서로 구분된다. 어떤 응용 프로그램 또는 태스크는 한 쪽에만 고립되기에(isolated) 보안성이 높아진다.
TrustZone 기술에서는 Normal world에서 Secure World로 진입하기 위해서는 특수한 CPU 명령인 SMC(Secure Monitor Call)을 통한 모니터 모드(monitor mode)로의 진입이 있어야 한다. 또한 디바이스가 파워 온 되면 시큐어 월드 부트로더(secure world bootloader)를 통해 Secure world OS(Operation System)가 부팅되고, 그 이후에 노말 월드 부트로더를 통해 Normal world OS가 부팅된다.
미국 공개 특허공보 US 2013/0145475 (공개일 2013년6월6일)에는 ARM사의 TrustZone 하드웨어 구조를 갖는 핸드헬드 디바이스에서, 터치스크린을 보안 레이어와 비-보안 레이어로 구분하여 처리함으로써, 맬웨어 등 소프트웨어에의 보안공격에 의한 사용자 PIN의 유출을 방지하는 보안 기술이 제시되었다.
기술문헌 "ARM Security Technology: Building a Secure System using TrustZone® Technology" (ARM Limited, White-Paper PRD29-GENC-009492C, April 2009)은 ARM사의 TrustZone 하드웨어 구조, 그리고 그 안에서의 Secure world와 Normal world의 구현과 운용을 제시한다.
본 발명은 보안 공격을 방지하여 안전한 환경에서 운영될 수 있는 시큐어 시스템 온 칩을 제공하기 위한 것이다.
일측에 따르면, 프로세서 코어; 상기 프로세서 코어에 제1 버스를 통해 연결되는 엘리먼트들을 포함하는 제1 그룹; 및 상기 프로세서 코어에 제2 버스를 통해 연결되며 보안 모드에서 동작하는 엘리먼트들을 포함하는 제2 그룹을 포함하는 반도체 칩이 제공된다.
일실시예에 따르면 상기 제2 버스는 상기 제1 버스와 물리적으로 구분되어, 상기 제2 그룹은 상기 제1 그룹으로부터 물리적으로 고립되어 동작한다. 여기서 상기 제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일 수도 있다.
일실시예에 따르면 상기 프로세서 코어는 메모리 영역을 코드 영역과 데이터 영역으로 분할하고, 상기 코드 영역에는 쓰기를 금지하고, 상기 데이터 영역은 실행을 금지시키는 메모리 보호 유닛(Memory Protection Unit, MPU) 을 포함한다. 상기 코드 영역과 상기 데이터 영역은 상기 Core-A 프로세서의 ASR에 대한 명령어를 이용하여 처리되는 보안 명령어에 의해 설정될 수 있다. 나아가, 상기 코드 영역과 상기 데이터 영역 외에 시스템 영역도 설정될 수 있다.
일실시예에 따르면 상기 프로세서 코어는 코드 시퀀스에 포함되는 리턴 어드레스를 백업하는 섀도우 스택을 포함할 수 있다. 이 경우, 상기 섀도우 스택은 기존의 메모리 상에 상주하는 스택과는 별도로 동일 또는 별도의 추가된 메모리, 또는 별도의 추가된 레지스터 등에 위치할 수 있다. 상기 섀도우 스택은 버스를 사용하지 않고, OS나 소프트웨어에 의해 접근되지 않으며 추가된 하드웨어 기반의 제어 회로의 의해 메모리 스택 관련 명령 수행 시 자동으로 수행되어 상기 리턴 어드레스를 이중으로 관리할 수 있다.
일실시예에 따르면 상기 반도체 칩 파워-온 시 외부 신뢰 기관과 상호 인증을 수행하는 인증부를 더 포함한다. 반도체 칩은 상기 인증에 성공한 경우에만 상기 제2 그룹을 사용 가능하도록 할 수 있다. 인증에 성공하여 상기 제2 그룹이 사용 가능한 경우에 있고 상기 제1 그룹이 일반 모드에서 동작하는 중, 보안 위반 이벤트가 발생하거나 또는 상승된 보안 취급이 처리되어야 하는 호출이 있는 경우 상기 보안 모드가 수행될 수 있다. 이 보안 모드에서 제2 그룹의 적어도 일부가 보안 명령에 의해 동작하여 정해진 기능을 수행할 수 있다. 일실시예에 따르면 Cryptographic IP, secure SRAM, secure DMA 및 boot ROM 중 적어도 하나를 포함한다.
일실시예에 따르면 반도체 칩은 상기 인증부가 상기 외부 신뢰 기관과 상기 상호 인증을 수행하는 데에 이용되는 근원 키를 제공하는 PUF(Physical unclonable function)를 더 포함할 수 있다. 예시적으로, 그러나 한정되지 않게, PUF는 반도체 제조 공정상의 공정 편차를 이용하여 상기 반도체 칩 내에 내재적으로(intrinsic) 포함될 수 있다. 하나의 예시적인 구현에서, 상기 PUF는 반도체의 전도성 레이어 간에 래이이웃 된 비아(via)나 인터-레이어 컨택이 공정에서 정상적으로 패터닝 되어 상기 전도성 레이어 사이를 단락하는지에 따라 디지털 값을 제공하는 것일 수 있다.
다른 일측에 따르면, 반도체 시스템 온 칩(SoC)의 동작 방법이 제시된다. 방법은, 인증부가 외부 신뢰 기관과 상호 인증을 수행하는 단계; 상기 인증에 성공하지 못하는 경우 프로세서 코어에 제1 버스를 통해 연결되는 엘리먼트들을 포함하는 제1 그룹을 활성화하고, 상기 프로세서 코어에 제2 버스를 통해 연결되며 보안 모드에서 동작하는 엘리먼트들은 비활성화하는 단계를 포함할 수 있다. 일실시예에 따르면 상기 제2 그룹은 Cryptographic IP, secure SRAM, secure DMA 및 boot ROM 중 적어도 하나를 포함하는 secure IP 그룹일 수 있다.
일실시예에 따르면 상기 인증부가 상기 외부 신뢰 기관과 상기 상호 인증을 수행하는 데에 이용되는 근원 키는 상기 반도체 시스템 온 칩의 내부에 포함되는 PUF로부터 제공될 수 있다.
일실시예에 따르면 방법은, 상기 인증에 성공하여 상기 제2 그룹이 사용 가능한 상태에 있는 중, 상기 제1 그룹이 동작하다가 보안 위반 이벤트가 발생하거나 또는 상승된 보안 취급이 처리되어야 하는 호출이 있는 경우 상기 보안 모드를 수행하여 상기 제2 그룹의 적어도 일부를 동작시키는 단계를 더 포함할 수 있다.
일실시예에 따르면 상기 프로세서 코어는, 버스를 사용하지 않고 OS나 소프트웨어에 의해 접근되지 않으며 코드 시퀀스에 포함되는 리턴 어드레스를 백업하는 하드웨어 기반의 섀도우 스택을 포함할 수 있다. 이 경우, 방법은 상기 프로세서 코어가 메모리 스택 관련 명령 수행 시 상기 리턴 어드레스를 백업하고 기존의 메모리상의 스택에 저장된 리턴 어드레스와 비교하여 공격을 감지하는 단계를 더 포함할 수 있다.
본 발명에 따르면, 보안 공격을 방지하여 안전한 환경에서 운영될 수 있는 SoC 플랫폼이 제공될 수 있다.
도 1은 일실시예에 따른 SoC 장치의 블록도이다.
도 2a 및 2b는 일실시예에 따른 SoC 구조를 도시한다.
도 3a 및 3b는 일실시예에 따른 인증 과정과 세부 처리 내용을 설명하기 위한 도면이다.
도 4는 일실시예에 따르면 보안 부팅(secure booting)의 흐름을 설명하기 위한 흐름도이다.
도 5는 일실시예에 따른 PUF의 구현을 설명하기 위한 개요도이다.
도 6은 일실시예에 따라 물리적 공격으로부터 근본적으로 보호되는 보안 SoC 플랫폼을 도시한다.
도 7 내지 도 8은 일실시예에 따른 SoC의 동작을 설명하기 위한 흐름도이다.
이하에서, 실시예들을 첨부된 도면을 참조하여 상세하게 설명한다. 그러나, 권리범위는 이러한 실시예들에 의해 제한되거나 한정되는 것은 아니다. 각 도면에 제시된 동일한 참조 부호는 동일한 부재를 나타낸다.
아래 설명에서 사용되는 용어는, 연관되는 기술 분야에서 일반적이고 보편적인 것으로 선택되었으나, 기술의 발달 및/또는 변화, 관례, 기술자의 선호 등에 따라 다른 용어가 있을 수 있다. 따라서, 아래 설명에서 사용되는 용어는 기술적 사상을 한정하는 것으로 이해되어서는 안 되며, 실시예들을 설명하기 위한 예시적 용어로 이해되어야 한다.
또한 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 설명 부분에서 상세한 그 의미를 기재할 것이다. 따라서 아래 설명에서 사용되는 용어는 단순한 용어의 명칭이 아닌 그 용어가 가지는 의미와 명세서 전반에 걸친 내용을 토대로 이해되어야 한다.
시스템 온 칩의
소프트웨어에 대한 보안 공격
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 코어 및 그 동작 방법의 실시예들이 제시된다. 도면을 참고하여 다양한 실시예들을 설명하기로 한다.
시스템의 개요 - normal world와 secure world의 물리적 격리
도 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)는 현재 트랜잭션의 대상이 되는 외부 터미널이 신뢰할 수 있는 상기 외부 인증 기관이 맞다는 점을 상호 인증하기도 한다.
일반
모드와
보안
모드의
전환
SoC는 일반 모드(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)되어 복호화되지 않으면 이는 의미 없다.
예시적 시스템 구현
도 2a 및 2b는 일실시예에 따른 SoC를 구현한 구조를 도시한다. 예시적으로, 그러나 한정되지 않게, 상기 프로세서 코어는 32 비트 RISC(Reduced Instruction Set Computing) 타입의 임베디드 프로세서인 Core-A 프로세서(201)를 포함한다. 다른 일실시예에 따르면 상기 프로세서 코어는 RISC V ISA를 적용한 CPU core일 수도 있다. 이하에서 '프로세서', '프로세서 코어', '시큐어 코어', '시큐어 프로세서' 등은 경우에 따라 상호간에 바뀌어 쓰일 수 있는 용어들로 이해되어야 한다. 예시적인 구현으로 'Core-A'를 이용한 구현에 대해 주로 설명하지만 RISC V ISA를 적용한 CPU 코어 등 다른 타입의 구현이 얼마든지 가능함은 이 분야의 기술자에게 자명하다.
도 2a를 참조하면, 일반 버스(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)에 직접 연결되어 있어 데이터를 암호화하여 안전하게 저장하는 것이 가능하다.
도 2b에서 보안 버스(220)의 구현 예시가 제시되어 있다. 보안 버스(secure bus)는 상기 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로 보안 레지스터의 내용 암호화
보안
모드
일실시예에 따르면 보안 수준을 강화하기 위하여, 보안 ISA를 인가된 사용자에게만 허가한다. 이러한 인증 과정과 세부 처리 내용을 도 3a 및 3b를 참조하여 설명한다. 상술한 바와 같이 SoC(300) 내에는 인증을 처리하고 보안 모드에서 동작하는 부분(310)이 존재한다.
보안 ISA를 모두 사용할 수 있는 보안 모드를 설명한다. 일반적으로 말단 SoC가 보안 연산을 수행할 때 모든 어플리케이션은 외부의 인증서 서버로부터 인증을 받아야 한다. 일실시예에 따르면 하드웨어 기반 인증부인 pre-authentication IP(301)는 전원이 켜졌을 때나 리셋된 이후 말단간 상호인증을 통해 외부 인증서 서버(301)와 통신할 수 있다.
예시적으로, 그러나 한정되지 않게 이러한 상호 인증은 PUF(303)가 만들어 내는 근원 키를 이용한 공개키 암호화 방식에 의할 수 있다. 서버(301)와 제안한 플랫폼(300)은 각자의 개인키로 서명을 생성하고 인증서 내에는 자신의 공개키가 포함되어 있다. 상호 인증은 인증서와 서명을 교환함으로써 수행된다. Pre-authentication IP(302)는 VIA-PUF(303)로부터 개인키를 생성하고 이를 이용해 생성한 서명을 인증서 서버에게 전달한다. 그리고 저장하고 있던 외부 인증서 서버의 공개키로 수신한 서명을 검증한다. 이 때 서명 알고리즘은 공개키 암호 알고리즘으로 ECC나 RSA일 수 있다. 성공적인 상호인증으로 시스템이 보안 모드에 진입하면 보안 코어가 secure booting을 제어한다. 또한 디버깅 포트는 오직 보안 모드일 때에만 열려, 인증된 사용자만 디버깅을 수행할 수 있게 된다. 인증이 성공하는 경우에는 보안 모드가 허가될 수 있으며, secure world의 IP 자원들(311 및 312 등)이 동작할 수 있다.
Core-A 프로세서의 특징을 이용
실시예들에 따라 말단 SoC에서 TEE를 지원하기 위해서는 ISA에서 새로운 특징을 갖는 보안 CPU 코어 설계가 필요하다. Core-A는 32-bit CPU core로 사용료가 무료이기에 보안 코어를 개발하는 데 좋은 시작점이다. Core A의 특징은 다음과 같다.
| 설명 | |
| 개요 | 하버드 구조를 갖는 32-bit RISC(Reduced Instruction Set Computer) 프로세서 |
| 특징 | 최대 4개의 coprocessor 지원. ASR(Application Specific Register) 인터페이스 |
| 명령어 | - Load-store 구조- 분기 명령어 내 프로그래밍이 가능한 delay slot- MUI 명령어와 32-bit 상수의 쉬운 생성- NOP 명령어 사용을 피할 수 있도록 하는 모든 명령어 내 NOP 필드 |
원래 5단계 파이프라인 Core-A CPU는 GCC 기반 Core-A 컴파일러를 사용하여 EEMBC CoreMark Benchmark에서 ARM9E-S CPU와 비슷한 성능을 보인다. Core-A의 ASR 인터페이스는 자주 사용되는 데이터를 저장하기 위한 스크래치-패드 메모리(scratch-pad memory)로 사용되거나 AMBA AXI-Lite와 비슷한 Transaction Memory Mapped Interface로 사용될 수 있다. ASR의 주소 공간은 주 메모리 영역에 포함되지 않으며, 주 메모리 인터페이스와 물리적으로 분리되어 특정 명령어를 통해서만 사용할 수 있다. 적절한 보안 모드 관리를 통해 여기서 제시되는 실시예에서는 ASR 인터페이스를 보안 IP 접근을 위한 숨겨진 보안 버스로 이용한다. 참고로 Core-A는 한국 내 팹리스 회사에서 널리 사용된다. Core-A는 Dynalith System사에 의해 지원되고 있으며, 기본적으로 Core-A는 오픈 소스로써 Core-A의 ISA 사용은 무료이다. 실시예들은 Core-A의 ISA를 사용자 정의, 확장하는 것으로 이해될 수도 있다.
보안이 강화된 secure world
실시예에 따른 VIA-PUF와 secure core에 기반을 둔 강화된 secure world의 특징의 예는 아래와 같다. 도 4는 일실시예에 따르면 보안 부팅(secure booting)의 흐름을 설명하기 위한 흐름도이다. 설명을 위해 도 4를 참조한다.
- Secure booting: 다음 수행될 소프트웨어 이미지 전체에 대한 무결성을 보장하기 위한 것으로, 인가되지 않거나 악의적으로 수정된 소프트웨어가 수행되는 것을 방지할 수 있다. 디바이스가 파워-온(410)되면, ROM의 SoC 부트로더(420)가 권한을 가지고 플래시 디바이스 부트로더(430)를 거쳐 무결성이 검증되는 secure world OS를 부팅한다(440). 그리고 normal world 부트로더(450)가 권한을 받아 normal world OS를 부팅하고(460) 시스템이 구동된다. 이러한 흐름에서 뒤 단계의 진행은 앞 단계의 무결성 검증을 순차적으로 상속하므로 중간에 공격이 개입하는 것이 방지된다. 이 과정에서 실시예들에 따른 보안 ISA는 전체 과정을 비선점되도록 만들면서 secure booting을 지원하므로, Time-Of-Check To Time-Of-Use(TOCTTOU) 공격과 같은 시도가 방지될 수 있다.
- 숨겨진 버스에 기반을 둔 secure world의 물리적 분리: 상술한 바와 같이 일실시예에 따르면 Core-A의 숨겨진 ASR 인터페이스를 오직 보안 모드에서만 사용되는 히든 버스로 활용한다. 이러한 히든 버스는 secure world를 위한 것으로, 보안 IP, on-chip boot ROM, secure SRAM와 같은 secure world로의 접근 경로를 주 메모리 인터페이스/버스로부터 물리적으로 완전히 분리해주는 역할을 한다.
- 보안 DAM(Direct Memoty Access): 비휘발성 메모리에서 내장 SRAM으로 DMA 전송 시 소프트웨어의 무결성을 확인하고 무결성 확인 결과에 따라 해당 코드의 실행을 결정한다.
- PUF 기반 보안 저장 공간: 비휘발성 메모리에 저장되는 보안 데이터는 VIA-PUF를 근원 키(Root key)로 사용하여 암호화된다.
- 보안 SRAM: 일반 영역으로부터 물리적으로 분리된다.
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 등을 참조하여 상술한 바와 같다.
이상에서 설명된 SoC 장치 및 플랫폼은 하드웨어 구성요소, 이를 제어 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, 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)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.
실시예에 따른 SoC의 동작 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 실시예의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
실시예들이 비록 한정된 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다. 그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.
Claims (20)
- 프로세서 코어;상기 프로세서 코어에 제1 버스를 통해 연결되는 엘리먼트들을 포함하는 제1 그룹; 및상기 프로세서 코어에 제2 버스를 통해 연결되며 보안 모드에서 동작하는 엘리먼트들을 포함하는 제2 그룹을 포함하는 반도체 칩.
- 제1항에 있어서,상기 제2 버스는 상기 제1 버스와 물리적으로 구분되어, 상기 제2 그룹은 상기 제1 그룹으로부터 물리적으로 고립되어 동작하는 반도체 칩.
- 제1항에 있어서,상기 제2 그룹은 상기 제1 그룹과 상이한 메모리 어드레스를 이용하여 데이터를 처리하는 반도체 칩.
- 제1항에 있어서,상기 프로세서 코어는 32 비트 RISC(Reduced Instruction Set Computing) 타입의 임베디드 프로세서인 Core-A 프로세서를 포함하는 반도체 칩.
- 제4항에 있어서,상기 제2 버스는 상기 Core-A 프로세서의 ASR (Application Specific Register)을 상기 제2 그룹에 포함되는 엘리먼트를 제어하는 주소 공간으로 사용하여 구현되는 히든 버스를 포함하는 반도체 칩.
- 제5항에 있어서,상기 제2 그룹은 상기 보안 모드에서 상기 ASR에 대한 데이터 처리 명령인 MTA(Move to ASR) 명령과 MFA(Move from ASR) 명령어를 보안 명령어(secure instruction) 처리에 이용하는 반도체 칩.
- 제1항에 있어서,상기 프로세서 코어는 메모리 영역을 코드 영역과 데이터 영역으로 분할하고, 상기 코드 영역에는 쓰기를 금지하고, 상기 데이터 영역은 실행을 금지시키는 메모리 보호 유닛을 포함하는 반도체 칩.
- 제7항에 있어서,상기 코드 영역과 상기 데이터 영역은 상기 Core-A 프로세서의 ASR에 대한 명령어를 이용하여 처리되는 보안 명령어에 의해 설정되는 반도체 칩.
- 제1항에 있어서,상기 프로세서 코어는 코드 시퀀스에 포함되는 리턴 어드레스를 백업하는 섀도우 스택을 포함하는 반도체 칩.
- 제9항에 있어서,상기 섀도우 스택은 버스를 사용하지 않고 OS나 소프트웨어에 의해 접근되지 않으며 메모리 스택 관련 명령 수행 시 자동으로 수행되어 상기 리턴 어드레스를 백업하고 상기 백업된 리턴 어드레스를 이용하여 원본 리턴 어드레스와 동일성 확인에 의해 보안 공격 감지를 하는 반도체 칩.
- 제1항에 있어서,상기 반도체 칩 파워-온 시 외부 신뢰 기관과 상호 인증을 수행하는 인증부를 더 포함하고,상기 인증에 성공한 경우에만 상기 제2 그룹을 사용 가능하도록 하는 반도체 칩.
- 제1항에 있어서,상기 제2 그룹이 사용 가능하고 상기 제1 그룹이 동작하는 중, 보안 위반 이벤트가 발생하거나 또는 상승된 보안 취급이 처리되어야 하는 호출이 있는 경우 상기 보안 모드가 수행되어 상기 제2 그룹의 적어도 일부가 동작하는 반도체 칩.
- 제1항에 있어서,상기 제2 그룹은 Cryptographic IP, secure SRAM, secure DMA 및 boot ROM 중 적어도 하나를 포함하는 반도체 칩.
- 제1항에 있어서,상기 인증부가 상기 외부 신뢰 기관과 상기 상호 인증을 수행하는 데에 이용되는 근원 키를 제공하는 PUF를 더 포함하는 반도체 칩.
- 반도체 시스템 온 칩의 동작 방법에 있어서,인증부가 외부 신뢰 기관과 상호 인증을 수행하는 단계; 및상기 인증에 성공하지 못하는 경우 프로세서 코어에 제1 버스를 통해 연결되는 엘리먼트들을 포함하는 제1 그룹을 활성화하고, 상기 프로세서 코어에 제2 버스를 통해 연결되며 보안 모드에서 동작하는 엘리먼트들은 비활성화하는 단계를 포함하는 방법.
- 제15항에 있어서,상기 제2 그룹은 Cryptographic IP, secure SRAM, secure DMA 및 boot ROM 중 적어도 하나를 포함하는 방법.
- 제15항에 있어서,상기 인증부가 상기 외부 신뢰 기관과 상기 상호 인증을 수행하는 데에 이용되는 근원 키는 상기 반도체 시스템 온 칩의 내부에 포함되는 PUF로부터 제공되는 방법.
- 제15항에 있어서,상기 인증에 성공하여 상기 제2 그룹이 사용 가능한 상태에 있는 중, 상기 제1 그룹이 동작하다가 보안 위반 이벤트가 발생하거나 또는 상승된 보안 취급이 처리되어야 하는 호출이 있는 경우 상기 보안 모드를 수행하여 상기 제2 그룹의 적어도 일부를 동작시키는 단계를 더 포함하는 방법.
- 제15항에 있어서,상기 프로세서 코어는, 버스를 사용하지 않고 OS나 소프트웨어에 의해 접근되지 않으며 코드 시퀀스에 포함되는 리턴 어드레스를 백업하는 하드웨어 기반의 섀도우 스택을 포함하는 방법.
- 제19항에 있어서,상기 프로세서 코어가 메모리 스택 관련 명령 수행 시 상기 리턴 어드레스를 백업하는 단계; 및상기 리턴 어드레스를 원본과 비교하여 동일성을 체크함으로써 공격을 감지하는 단계를 더 포함하는 방법.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US16/076,449 US11089016B2 (en) | 2016-02-12 | 2017-02-13 | Secure system on chip |
| CN201780010950.4A CN108604274A (zh) | 2016-02-12 | 2017-02-13 | 安全片上系统 |
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR20160016587 | 2016-02-12 | ||
| KR10-2016-0016587 | 2016-02-12 | ||
| KR1020170019341A KR20170095161A (ko) | 2016-02-12 | 2017-02-13 | 시큐어 시스템 온 칩 |
| KR10-2017-0019341 | 2017-02-13 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2017138797A1 true WO2017138797A1 (ko) | 2017-08-17 |
Family
ID=59563378
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/KR2017/001554 Ceased WO2017138797A1 (ko) | 2016-02-12 | 2017-02-13 | 시큐어 시스템 온 칩 |
Country Status (1)
| Country | Link |
|---|---|
| WO (1) | WO2017138797A1 (ko) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110532777A (zh) * | 2018-05-24 | 2019-12-03 | 霍尼韦尔环境自控产品(天津)有限公司 | 安全启动系统及方法、终端设备及其核心系统 |
| CN111414626A (zh) * | 2020-04-01 | 2020-07-14 | 中国人民解放军国防科技大学 | 基于tee扩展的实时性保证方法及系统 |
| CN114238946A (zh) * | 2022-02-23 | 2022-03-25 | 湖北芯擎科技有限公司 | 设备管理方法、装置、电子设备及计算机可读存储介质 |
| CN121069856A (zh) * | 2025-11-06 | 2025-12-05 | 上海壁仞科技股份有限公司 | 可信执行环境控制电路和人工智能芯片 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20000070127A (ko) * | 1997-01-15 | 2000-11-25 | 칼 하인쯔 호르닝어 | 소프트웨어 프로그램의 규정된 실행을 모니터링하기 위한 방법 |
| 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 | (주) 아이씨티케이 | 사물지능통신에서 puf에 기반한 장치간 보안 인증 장치 및 방법 |
| KR20140114263A (ko) * | 2013-03-13 | 2014-09-26 | 삼성전자주식회사 | 어플리케이션 인증 방법 및 이를 구현하는 전자 장치 |
-
2017
- 2017-02-13 WO PCT/KR2017/001554 patent/WO2017138797A1/ko not_active Ceased
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20000070127A (ko) * | 1997-01-15 | 2000-11-25 | 칼 하인쯔 호르닝어 | 소프트웨어 프로그램의 규정된 실행을 모니터링하기 위한 방법 |
| 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 | (주) 아이씨티케이 | 사물지능통신에서 puf에 기반한 장치간 보안 인증 장치 및 방법 |
| KR20140114263A (ko) * | 2013-03-13 | 2014-09-26 | 삼성전자주식회사 | 어플리케이션 인증 방법 및 이를 구현하는 전자 장치 |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110532777A (zh) * | 2018-05-24 | 2019-12-03 | 霍尼韦尔环境自控产品(天津)有限公司 | 安全启动系统及方法、终端设备及其核心系统 |
| CN111414626A (zh) * | 2020-04-01 | 2020-07-14 | 中国人民解放军国防科技大学 | 基于tee扩展的实时性保证方法及系统 |
| CN111414626B (zh) * | 2020-04-01 | 2023-09-26 | 中国人民解放军国防科技大学 | 基于tee扩展的实时性保证方法及系统 |
| CN114238946A (zh) * | 2022-02-23 | 2022-03-25 | 湖北芯擎科技有限公司 | 设备管理方法、装置、电子设备及计算机可读存储介质 |
| CN114238946B (zh) * | 2022-02-23 | 2022-05-03 | 湖北芯擎科技有限公司 | 设备管理方法、装置、电子设备及计算机可读存储介质 |
| CN121069856A (zh) * | 2025-11-06 | 2025-12-05 | 上海壁仞科技股份有限公司 | 可信执行环境控制电路和人工智能芯片 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Nasahl et al. | HECTOR-V: A heterogeneous CPU architecture for a secure RISC-V execution environment | |
| US11089016B2 (en) | Secure system on chip | |
| Jauernig et al. | Trusted execution environments: properties, applications, and challenges | |
| Li et al. | TEEv: Virtualizing trusted execution environments on mobile platforms | |
| Mohammad et al. | Required policies and properties of the security engine of an SoC | |
| US9842212B2 (en) | System and method for a renewable secure boot | |
| Evtyushkin et al. | Iso-x: A flexible architecture for hardware-managed isolated execution | |
| US7376974B2 (en) | Apparatus and method for creating a trusted environment | |
| US8850212B2 (en) | Extending an integrity measurement | |
| US7028149B2 (en) | System and method for resetting a platform configuration register | |
| US8583908B2 (en) | Enhanced network and local boot of Unified Extensible Firmware Interface images | |
| US20070277223A1 (en) | Execution of a secured environment initialization instruction on a point-to-point interconnect system | |
| US20100115625A1 (en) | Policy enforcement in trusted platforms | |
| US11888972B2 (en) | Split security for trusted execution environments | |
| US8689318B2 (en) | Trusted computing entities | |
| KR20120099472A (ko) | 보안 애플리케이션 실행을 제공하는 방법 및 장치 | |
| Evtyushkin et al. | Flexible hardware-managed isolated execution: Architecture, software support and applications | |
| Shen et al. | T-Edge: Trusted Heterogeneous Edge Computing | |
| Dubrulle et al. | Blind hypervision to protect virtual machine privacy against hypervisor escape vulnerabilities | |
| Zhang et al. | iFlask: Isolate flask security system from dangerous execution environment by using ARM TrustZone | |
| WO2017138799A1 (ko) | 하드웨어 디바이스 및 그 인증 방법 | |
| CN115688198B (zh) | 电力物联智能终端可信执行系统 | |
| Kumar et al. | A novel holistic security framework for in-field firmware updates | |
| Liu et al. | MaTEE: Efficiently bridging the semantic gap in TrustZone via ARM pointer authentication | |
| Ciravegna | Detecting compromise in TEE applications at runtime |
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: 17750489 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: 17750489 Country of ref document: EP Kind code of ref document: A1 |