WO2017138797A1 - Système sur puce de sécurité - Google Patents

Système sur puce de sécurité Download PDF

Info

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
Application number
PCT/KR2017/001554
Other languages
English (en)
Korean (ko)
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 CN201780010950.4A priority Critical patent/CN108604274A/zh
Priority to US16/076,449 priority patent/US11089016B2/en
Priority claimed from KR1020170019341A external-priority patent/KR20170095161A/ko
Publication of WO2017138797A1 publication Critical patent/WO2017138797A1/fr

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

  • 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

L'invention concerne un système sur puce de sécurité. Par exemple, la puce à semi-conducteur est un système sur puce. Le système sur puce est activé en connectant les IP normaux à un cœur de processeur compris dans ceux-ci par le biais d'un bus système. Un bus de sécurité, qui est un bus caché physiquement séparé du bus système, est fourni séparément. Les IP de sécurité permettant d'exécuter une fonction de sécurité ou de gérer des données de sécurité sont connectés au bus de sécurité. La puce à semi-conducteur de sécurité peut effectuer l'authentification requise lors de la commutation entre un mode normal et un mode de sécurité.
PCT/KR2017/001554 2016-02-12 2017-02-13 Système sur puce de sécurité WO2017138797A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201780010950.4A CN108604274A (zh) 2016-02-12 2017-02-13 安全片上系统
US16/076,449 US11089016B2 (en) 2016-02-12 2017-02-13 Secure system on chip

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR20160016587 2016-02-12
KR10-2016-0016587 2016-02-12
KR10-2017-0019341 2017-02-13
KR1020170019341A KR20170095161A (ko) 2016-02-12 2017-02-13 시큐어 시스템 온 칩

Publications (1)

Publication Number Publication Date
WO2017138797A1 true WO2017138797A1 (fr) 2017-08-17

Family

ID=59563378

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/001554 WO2017138797A1 (fr) 2016-02-12 2017-02-13 Système sur puce de sécurité

Country Status (1)

Country Link
WO (1) WO2017138797A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
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 湖北芯擎科技有限公司 设备管理方法、装置、电子设备及计算机可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
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 (주) 아이씨티케이 사물지능통신에서 ｐｕｆ에 기반한 장치간 보안 인증 장치 및 방법
KR20140114263A (ko) * 2013-03-13 2014-09-26 삼성전자주식회사 어플리케이션 인증 방법 및 이를 구현하는 전자 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
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 (주) 아이씨티케이 사물지능통신에서 ｐｕｆ에 기반한 장치간 보안 인증 장치 및 방법
KR20140114263A (ko) * 2013-03-13 2014-09-26 삼성전자주식회사 어플리케이션 인증 방법 및 이를 구현하는 전자 장치

Cited By (5)

* Cited by examiner, † Cited by third party
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 湖北芯擎科技有限公司 设备管理方法、装置、电子设备及计算机可读存储介质

Similar Documents

Publication Publication Date Title
US11089016B2 (en) Secure system on chip
Jauernig et al. Trusted execution environments: properties, applications, and challenges
Machiry et al. BOOMERANG: Exploiting the Semantic Gap in Trusted Execution Environments.
Nasahl et al. HECTOR-V: A heterogeneous CPU architecture for a secure RISC-V execution environment
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
Li et al. TEEv: Virtualizing trusted execution environments on mobile platforms
US20160085965A1 (en) Execution of a secured environment initialization instruction on a point-to-point interconnect system
US11888972B2 (en) Split security for trusted execution environments
US20100115625A1 (en) Policy enforcement in trusted platforms
KR20120099472A (ko) 보안 애플리케이션 실행을 제공하는 방법 및 장치
WO2017138797A1 (fr) Système sur puce de sécurité
Evtyushkin et al. Flexible hardware-managed isolated execution: Architecture, software support and applications
WO2017138799A1 (fr) Dispositif matériel et procédé d'autorisation associé
Vaswani et al. Confidential machine learning within graphcore ipus
Zhang et al. iFlask: Isolate flask security system from dangerous execution environment by using ARM TrustZone
Dubrulle et al. Blind hypervision to protect virtual machine privacy against hypervisor escape vulnerabilities
Mohammad et al. Required policies and properties of the security engine of an SoC
Kumar et al. A novel holistic security framework for in-field firmware updates
Stajnrod Attacking ARM TrustZone using Hardware vulnerability
Zhang et al. T-MAC: Protecting Mandatory Access Control System Integrity from Malicious Execution Environment on ARM-Based Mobile Devices

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