## 2 Trustworthy Assumptions and Threat Models  
Before integrating the proposed security processing unit (SPU) into an embedded system to establish the expected CPU-SPU collaborative SoC, the trustworthy assumptions and threat models aiming at embedded system should first be determined. Generally, some sensitive components in embedded system are likely susceptible to malicious attacks; thus, we should make their associated trustworthy assumptions and focus on security protections according to potential threat models. Hence, we make the following assumptions regarding the CPU-SPU collaborative SoC hardware architecture, the potential malicious attacks, and the program monitoring and instruction recovery mechanism. We plan to integrate the hardware-implemented SPU with an open-source reduced instruction set computing (OpenRISC) processor OR1200 for constructing a secure CPU-SPU collaborative SoC architecture. In this, the central processing unit (CPU) of OR1200 is a 32-bit scalar RISC softcore processor with a Harvard micro architecture. This satisfies the GNU general public license (GPL) protocol, which is supported by the OpenCoresorganization. The CPU core consists of a five-stage execution pipeline: the instruction fetching (IF) stage, instruction decoding (ID) stage, instruction executing (EX) stage, memory accessing (MA) stage, and writing back (WB) stage, which is a single-emission sequence execution pipeline. Moreover, the CPU core is configured with instruction memory management unit (IMMU) and data memory management unit (DMMU). For decreasing the average delays in fetching instructions and data from the external memory, the instruction cache (I-Cache) and data cache (D-Cache) were configured and connected with the addressable quick memory (QMEM), the temporal locality principle and spatial locality principle of program execution in accessing cache memory can be fully exploited to keep up with CPU's execution pipeline. The CPU-SPU collaborative SoC hardware architecture is shown in Figure 1.  
Since all the program operations are performed under the control of CPU, the components directly connected to the CPU are the critical targets of interest for inserting hardware Trojans or injecting fault attacks, and thus an erroneous instruction could pose a serious security challenge to embedded system. We assume the whole SoC architecture is an integration of IPs, and many of which are acquired from the untrusted third-party vendors for shortening the time-to-market of its applied products. We reasonably make the trustworthy assumption regarding the proposed CPU-SPU collaborative SoC architecture that our self-designed SPU was highly tested and validated that anywhere without hidden hardware Trojans being inserted within internal control logic. However, the CPU core, cache memory, register file, main memory, etc. are sensitive components that are likely to suffer from the malicious tampering attacks during program executions. In addition, many memory IPs (including RAM technology library) need to acquire from the third-party vendors for SoC convenient taping-out, this will further aggravate the concerns of hardware confidence. According to the different locations where program tampering attacks may occurred by hardware Trojans or fault injection, there are four types of threat model assumptions, which are common-used approaches to disturb CPU normal program execution in reported researches:  
* The first situation is that instruction codes were modified or tampered with in the processor core. The authors in [20] designed a sequential hardware Trojan, which was activated by a sequence of rare events to modify instruction codes before the  
Figure 1: The CPU–SPU collaborative SoC hardware architecture for real-time security protection. ID stage. In addition, a capacitor-based triggering Trojan IP was embedded into a CPU [21], which leveraged an analog circuit to siphon charges from nearby wires and enforced the victim to flip-flop to a desired value.