In this section, we review some existing security solutions in commercial prod- ucts. In general, they fall into one of two categories: 1) a secure co-processor approach that executes sensitive information on a standalone and secure com-
ware, either as a co-processor or as a main processor, that ensures that the computing platform is trustworthy.
3.2.1 Secure Co-Processor
The IBM 4758 secure co-processor [56, 57] is a self-contained, tamper-resistant and responsive computing device attached to the host computer via a Periph- eral Component Interconnect (PCI) interface. It also contains a factory-built private key of a public and private key pair and uses the public key cryp- tographic algorithm to enable attestation and symmetric key exchange with remote parties. Internally, there are cryptographic accelerators to perform data en-/decryption and digital signatures. It also contains limited memory to store the encrypted or decrypted data inside the platform. Because it is designed as a general purpose secure co-processor, it remains a high cost solution.
TrustedDB [22] employs the IBM 4764 secure co-processor [58], a successor of IBM 4758, to protect the data confidentiality of an outsourced database in the cloud. Due to the limited computational power and storage capacity of the secure co-processor, it still relies on the host computer to execute non- sensitive data and store the outsourced database. The secure co-processor is responsible for most query executions, including parsing the encrypted queries sent from the client. The queries, after parsing, are further re-written into public sub-queries or private sub-queries. Public sub-queries are handled by the host computer to process unencrypted data while private sub-queries are executed by the secure co-processor to compute encrypted data. The final query result is assembled and encrypted by the secure co-processor. Under such architecture, sensitive data can only be decrypted and stored inside the secure co-processor. However, its limiting computational power and high latency data communication cause 1.03⇥ to 8⇥ slowdown on OLAP workloads.
A FPGA provides an alternative to a custom secure co-processor. It ex- hibits the feature of hardware security and reconfigurability, making it a good
alternative to build a trusted computing platform. Eisenbarth et al. [59] proposed to build the root of trust on FPGA with the same Trusted Platform Module (TPM) functionalities, which allows flexible updates to TPM function- ality. Eguro et al. [60] proposed to use a FPGA to build a custom execution engine for secure data processing, where the encrypted data can be decrypted, computed and re-encrypted inside the reconfigurable logic. The bitstream is protected by encryption and securely loaded into the FPGA via the on-board secure boot logic. These proposals provide a general discussion on the possi- bility of using a FPGA to build a trusted computing platform but lacks an in-depth discussion of its performance impact.
Inherited from Eguro’s proposal, Cipherbase [23] proposed to use a FPGA- based query co-processor to process an encrypted database in the cloud. Sim- ilar to TrustedDB, it also relies on the host computer to execute non-sensitive data and store the outsourced database. But it leverages the framework in CryptDB, so the majority of the query execution is done at the host computer. The FPGA is only responsible for those operations that CryptDB cannot sup- port or can barely support with low efficiency (e.g. addition, multiplications). This has two major benefits over TrustedDB. First, the major query execu- tion is offloaded to the host computer, which has higher computational power. Second, it reduces data communication over the PCI bus. However, it also poses a potential hazard for performance because the FPGA generally runs at a slower clock frequency than Application Specific Integrated Circuit (ASIC) and data communication over the PCI bus is still quite costly. Its evaluation over OLTP workloads shows 17% to 20% throughput degradation but the per- formance over OLAP workloads is still largely unknown. The authors also suggested that it may not perform well over OLAP workloads because data mining queries typically touch a large number of records. It greatly amplifies the performance overhead caused by the FPGA and data communication.
on a secure co-processor to execute a large amount of sensitive information can cause significant performance overhead.
3.2.2 Trusted Platforms
Trusted Computing Platform Alliance (TCPA) has specified TPM [11], a small chip mounted on the motherboard, to provide a root of trust for a computing platform. Its main objective is to protect the platform from software attack by providing a remote attestation and protected storage mechanism. The attesta- tion is based on a white-list approach that compares the hashing measurement of all the software layers with the approved value stored inside the chip. It means that any software attack on the system would alter the hashing mea- surement and therefore TPM can detect and respond to the tampering. TPM provides specific access control on the encrypted data called sealing. A sealed storage can only be deciphered in a specific system configuration. A number of works propose using TPM to provide a trusted platform in Cloud Computing [61, 62]. However, a major disadvantage of TPM is that it offers protection of encryption keys but does not protect the encryption key and the decrypted data once unsealed. Thus, the decrypted data and encryption key can still be obtained by an attacker through cold-boot attack [14].
Intel Trusted Execution Technology (TXT) [45] also builds upon TPM to provide protected execution. The processor support extends the security of TPM in that it erases the memory content in off-chip memory if any tampering is detected by TPM. This targets against memory snooping software attacks but not against physical attacks. Intel AES-NI [63] provides instruction sup- port to use the on-chip Advanced Encryption Standard (AES) cryptographic engine. It also has an on-chip Digital Random Number Generator (DRNG) [64] to generate the encryption key. However, they are originally designed for acceleration purposes where the encryption key can be stored and the de- crypted data are stored outside the processor chip. Sensitive information thus
remains unprotected in off-chip memory.
ARM TrustZone [46] introduces a set of security extensions to the ARM processor to provide a trusted execution environment by virtually partition- ing all hardware resources into two isolated subsystems - “secure world” and “normal world”. The root of trust is provided in hardware by implementing an additional bit in the system bus, cache and Translation Lookaside Buffer (TLB) for strong isolation between these two subsystems. Security sensitive applications can run in a secure world and is protected from any software at- tack in a normal world. ARM TrustZone architecture also enforces secure boot mechanisms and secure I/O paths via trusted peripherals. Unlike TPM and secure co-processor approaches, there is no cryptographic engine or factory- installed private key burnt into the processor. In fact, ARM’s model provides a generic but isolated system for executing security sensitive applications. It does not consider the privacy protection of off-chip memory.
Maxim Integrated (formerly Dallas Semiconductor) manufactures the DS5250 secure microprocessor [65]. As its architecture is very similar to the secure pro- cessor approach, we include it in Section 3.3.1 below for ease of discussion.
Commercial architecture usually aims at providing a trusted platform for software to run (the software stack is securely booted). It relies on software to perform security critical tasks but does not consider physical attacks.