Secure Code Execution: A Generic PUF-Driven System Architecture

Abstract

In his invited talk, joint between CHES 2016 and CRYPTO 2016 on the Future of Embedded Security, Paul Kocher suggested to move the security into chips because hardware is the lowest level and thus security can not be compromized by a lower layer. In this paper, we propose a generic PUF-driven secure code execution architecture that employs instruction-level code encryption. Our design foresees a tight integration of a Physically Unclonable Function (PUF) and the decryption of encrypted program code directly inside the processor’s instruction pipeline to avert revealing keys or decrypted code in externally accessible registers or memory. The architecture prevents code-injection by executing only code encrypted for individual target CPUs, has an adaptable impact on performance, and requires only minor changes to the software development process. Our PUF-based code encryption defends also from reverse engineering attempts and enforces IP protection. A proof-of-concept implementation demonstrates the feasibility of our proposed architecture.

Appendices

Appendices

Fig. 4.

SEPP architecture building blocks overview (orange arrows: key generation, black arrows: execution) (Color figure online)

1.1 A Deployment of Software Updates

Programs are initially flashed to a SEPP-powered System-on-a-Chip (SoC) at deployment time by the user via a secure connection to the device, e.g., a dedicated cable. To enable software updates in the field, an encrypted binary ${\text {c}}_{k_ u }(\mathcal {B})$—initially deployed in a secure environment as stated above—may contain an update function. This update function needs to be able to take a new user-key ${k_ u }'$ and a new encrypted binary ${\text {c}}_{{k_ u }'}(\mathcal {B}')$ and feed it into the PUF-driven executable-image generation process. SEPP will return $\pi ' = {\text {c}}_{{k_ p }'}({k_ u }')$ to be packaged into a new image $\left( {\text {c}}_{{k_ u }'}(\mathcal {B}'), \pi ' \right)$ for its current instance. A user sends ${\text {c}}_{{k_ u }'}(\mathcal {B}')$ and ${k_ u }'$ to this function; the encrypted ${\text {c}}_{{k_ u }'}(\mathcal {B}')$ can be transmitted via an untrusted network connection, while ${k_ u }'$ needs to be transmitted securely. To provide this secure channel between user and $\mathcal {B}$ running on the SEPP device, the update function already deployed in the trusted binary $\mathcal {B}$ must contain a suitable encryption scheme, e.g., RSA-based such as TLS or SSH. Due to the small key size, the secure channel for ${k_ u }'$ requires only a low data rate.

The PUF-driven executable-image generation process of SEPP, generating $\pi = {\text {c}}_{k_ p }({k_ u })$, has to be deactivated physically after deployment of the binaries for ultimate security demands. This completely prohibits the generation of any new executable sequence of instructions for this instance of SEPP and therefore completely prevents injections. For the over-the-air update, this security feature has to be deactivated as trade-off for an update path. The executable-image generation process of SEPP alternatively can only be triggered by a privileged instruction. This restricts its usage to the security kernel, however shifting the responsibility into software to decide what trusted code is allowed to generate new code.

1.2 B Practical Performance Measurements

Benchmarks and tests were conducted on our prototype implementation. We compare the test results with our prototype’s base platform, the OR1200 CPU, running on the same FPGA board as SEPP’s prototype implementation. In order to demonstrate the performance impact, we developed a number of custom tests with known parameters such as the number of branching instructions. These custom tests were all compiled without any compiler optimization in order to ensure deterministic outcomes. The results of our tests are summarized in Table 2.

Table 2. Results of custom tests executed on prototype implementation

By reducing the number of jump instructions from 14.3% to 5.3% through the removal of a function call within a loop, compared to the baseline system, the performance penalty decreases from 84% to 34%. This clearly demonstrates the impact of branch and jump instructions on the execution time of encrypted programs.

Loops generally introduce a substantial number of jumps into program execution. To verify this assumption, we manually unrolled a loop of a short example program. The number of branch instructions thereby decreased from 9.8% to 3.8%, reducing performance penalty from 61% to 17% for our custom test cases.

Furthermore, we performed CoreMark⁴ benchmarks, to show the influence of unrolling loops and to enable comparison with future developments and other platforms. We conducted the benchmark both on our system in encrypted form as well as on the baseline architecture in unencrypted form. We compare the benchmark compiled with GCC’s optimization level -O3 with another version that is compiled with additional loop unrolling optimization, enabled with the flag -funroll-all-loops. Compilation with -O3 results in a 48.8% penalty of SEPP, and enabling unrolling reduces this to 43.5%. While the baseline processor only speeds up by 9% with the additional -funroll-all-loops, SEPP’s execution speed gains 21%. This confirms that the reduction of branching instruction benefits SEPP greatly. These benchmark comparisons prove the expected effects of our instruction-level decryption, specifically the warm-up latency on branching, for actual calculations.

Unfortunately, the comparison of our prototype with related implementations is not straightforward, as authors in this field use a variety of methods for performance assessment. The AEGIS developers used the SPEC2000 CPU⁵ benchmark suite [27], which is not freely available. Lie et al. [19] provide a theoretical performance analysis for their XOM architecture [19]. The OASIS instruction set extension is not directly comparable to SEPP, as the authors only give absolute time overheads for specific platform operations [25].

The AEGIS developers state that degradation can be as high as 60%; while it mostly stays below 40%. XOM’s slow down is less than 50% according to the authors’ calculations. Given this comparison, we conclude that the runtime penalty of SEPP lies well within worst case, best case, and average for comparable systems. We expect a significant performance advantage of SEPP over the compared platforms when the described improvements are implemented in future work.

We are not able to compare SEPP to previous work in respect to FPGA resources overhead for the lack of information about properties of those approaches: XOM is only an architectural design without a hardware implementation [19]. OASIS was only simulated in software [25]. Although, an FPGA implementation of AEGIS was evaluated [28] no information about their FPGA resource requirements were given. Its resource overhead was only determined by an ASIC synthesis. The ASIC area overhead of AEGIS was given as being roughly 90% larger than their baseline. We consider this value not to be directly comparable to the roughly 68% Slices overhead of SEPP.