# Security Implications for Ultra-Low Power Configurable SoC FPAA Embedded Systems
## 4 Embedded FPAA Security Concerns
### Addressing FPAA Security Issues  
FPAA devices are far from safe from a potential malicious agent, even with a number of good starting properties. For example, the current FPAA devices do not have encryption and related security on the input control of the device. If an actor could connect to the particular control connections, even if the IC pins are disconnected or disabled, they could get direct control of the device and programming infrastructure. Future FPAA devices will have encryption on the control structure, particularly as they move to a wider user community. The encrypted access can make use of a PUF from the particular FPAA, such as the approach shown in Section 5. Encryption is a straight-forward solution used on secure FPGA devices [19], with multiple papers showing FPGA implementation of secure encryption and decryption [20]. Figure 1 illustrates possible security issues and types of attacks for an embedded system built with SoC FPAA device. Smaller IoT systems often need to address intrusion detection and resulting policy-based mechanisms for security [17]; FPAA enabled systems take these issues to the next level. The FPAA attacks could happen by physical tampering with an existing device, as well as electronic attacks through the communication port, such as a transceiver port. A physical FPAA attack, the device is obtained while avoiding self-destruct sequence to be explicitly deconstructed. If the internal code can be obtained, likely at considerable expense, one could potentially reconstruct the FPAA function. Mismatch encoded functions would require additional computational and measurement structures. An alternate physical FPAA attack could use a compiled digital serial port to gain access to the digital control and resulting programming interface. When digital interfaces (e.g., SPI) are controlled by the processor, getting control of the processor is unlikely. A more likely situation is finding a way to stall the computation resulting from a physical attack on the clock structure. Many systems are far less secure due to physical tampering if the device has been obtained, and any self-destruct/erase mechanism was somehow avoided. A more likely situation is a non-physical attack through the transceiver interface into the IC. These can include attacks to gain control of the FPAA device to reprogram the device, or constantly attacking a device to drain the node battery power. Low-energy computation opens application opportunities at 10 mW, 1 mW, and lower average power consumption, and yet the low power consumption constrains the system security capabilities. Embedded FPAA applications also have limited digital memory because of the system cost. Network security is characterized in terms of classes of networked devices [21], summarized in Table 1[22; 23; 24]. These numbers are framed in terms of the cost of a small IoT OS operation and maybe basic security functions [25]. SoC FPAA is a C\({}_{0}\) device having only 32 kB total digital memory. Digital memory is expensive in terms of relative on-chip area, complexity, and energy dissipation. Many systems going forward might have less total digital memory, as well as many systems that will not rise to the C\({}_{1}\) memory level. FPAAs enables a whole opportunity of C\({}_{0}\) devices, devices many assume are impossible to secure over a network. Running a minimal OS and security code may exceed the rest of system energy budget. So how do we have an ultra-low power secure IoT system? Part of the opportunity is coding systems outside of a minimal OS, consistent with the rest of the event-based FPAA uP code, as well as enabling tight secure stack and security aspects in MSP 430 assembly language. Digital FPAA event code is coded in assembly language and encapsulated in graphical code for easy user reuse. Network traffic attacks on FPAA-based systems are likely to be a point of vulnerability, requiring building tables and metrics of proper and improper network activity and classifying the resulting responses [26; 27; 28; 29; 30; 31; 32; 33; 34; 35].