## 3 Analysis of TEE Usage in Edge Intelligence and IoT
### Analysis of SGX in Edge Intelligence and IoT
#### 3.3.1 I/O Security Issues  
Firstly, SGX does not include specific protection measures for I/O operations. While memory regions are protected by SGX, I/O operations still interact with external systems through unprotected channels. These channels, such as networks and storage devices, may become targets for attackers, potentially leading to the risk of I/O data being intercepted or alerted on edge devices. To establish a trusted path between the enclave and I/O devices, various solutions have been proposed, as shown in Table 2.  
There are generally three approaches to construct a trusted I/O path: hypervisor-based, software-based and external hardware (HW)-based solutions. For hypervisor-based methods such as SGXIO [50], although it leverages a virtual machine to supervise the OS, it significantly increases the TCB. Additionally, because SGX does not trust the hypervisor, this approach involves a complex process of trusted domain binding and attestation. Software-based solutions like Aurora [51] protects I/O using the System Management Mode (SMM) but occupies valuable SMRAM resources and lacks distinction between secure and non-secure devices. Rocket-io [52] leverages the Storage Performance Development Kit (SPDK) and Data Plane Development Kit (DPDK) to accelerate communication between the enclave and peripherals. However, it is limited to the disk and network interface card, offering poor generality. The approaches based on external HW encounter challenges such as significant overhead when establishing trusted I/O paths. Ref. [53] designs an external HW called USB Dongle, and implements a Device Provisioning Enclave (DPE) for key exchange and information transmission, but during the initialization of the trusted path, a trusted OS  
\begin{table}
\begin{tabular}{c c l l} \hline \hline
**Category** & **Reference** & **Methodology** & **Limitations** \\ \hline Hypervisor-based & [PERSON] et al., 2017 [50] & Based on trusted hypervisor & Large TCB and complex \\ \hline Software-based & [PERSON] et al., 2020 [51] & Leverages SMM and SMVisor to protect I/O operations & Occupies limited SMRAM \\ \cline{2-4}  & [PERSON] et al., 2021 [52] & Based on SPDK and DPDK for user–space I/O & Limited generality \\ \hline External HW & [PERSON] et al., 2019 [53] & USB Dongle (HW) and DPE for attestation & Additional overhead \\ \cline{2-4}  & [PERSON] et al., 2024 [54] & Based on UDP (HW) for USB packet forwarding & Substantial overhead caused \\ \hline Specific Scenarios & [PERSON] et al., 2018 [55] & Modify the protocol stack and use the Bluetooth controller to protect Bluetooth device I/O & Limited generality \\ \cline{2-4}  & [PERSON] et al., 2019 [56] & Two dongles for keyboard and monitor, enhancing security for browser & Limited screen protection area, Unprotected mouse \\ \hline \hline \end{tabular}
\end{table}
Table 2: Trusted I/O path construction in SGX environment.  
must first be booted to bind the DPE and the device, resulting in significant performance overhead. Furthermore, A USB proxy device (UPD) is designed in [54] for transmitting USB packets. However, the I/O path setup relies on remote attestation, which incurs significant overhead. Some I/O protection solutions for specific scenarios, such as Bluetooth [55] and browsers [56] are proposed but these also encounter issues such as limited generality and inadequate security protection. This demonstrates that SGX still lacks a universal solution for I/O security and I/O performance degradation issues. This is particularly concerning in edge intelligence scenarios, where attackers can more easily access devices and data sources, leading to increased security risks.