Biblio

In this paper we tackle the open paradoxical challenge of FPGA-accelerated cloud computing: On one hand, clients aim to secure their Intellectual Property (IP) by encrypting their configuration bitstreams prior to uploading them to the cloud. On the other hand, cloud service providers disallow the use of encrypted bitstreams to mitigate rogue configurations from damaging or disabling the FPGA. Instead, cloud providers require a verifiable check on the hardware design that is intended to run on a cloud FPGA at the netlist-level before generating the bitstream and loading it onto the FPGA, therefore, contradicting the IP protection requirement of clients. Currently, there exist no practical solution that can adequately address this challenge.We present the first practical solution that, under reasonable trust assumptions, satisfies the IP protection requirement of the client and provides a bitstream sanity check to the cloud provider. Our proof-of-concept implementation uses existing tools and commodity hardware. It is based on a trusted FPGA shell that utilizes less than 1% of the FPGA resources on a Xilinx VCU118 evaluation board, and an Intel SGX machine running the design checks on the client bitstream.

The increasing complexity of modern computing devices has rendered security architectures vulnerable to recent side-channel and transient-execution attacks. We discuss the most relevant defenses as well as their drawbacks and how to overcome them for next-generation secure processor design.

Hardware security architectures and primitives are becoming increasingly important in practice providing trust anchors and trusted execution environment to protect modern software systems. Over the past two decades we have witnessed various hardware security solutions and trends from Trusted Platform Modules (TPM), performance counters for security, ARM's TrustZone, and Physically Unclonable Functions (PUFs), to very recent advances such as Intel's Software Guard Extension (SGX). Unfortunately, these solutions are rarely used by third party developers, make strong trust assumptions (including in manufacturers), are too expensive for small constrained devices, do not easily scale, or suffer from information leakage. Academic research has proposed a variety of solutions, in hardware security architectures, these advancements are rarely deployed in practice.