204 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 16, NO. 2, MARCH/APRIL 2019 Design and Implementation of the Ascend Secure Processor Ling Ren , Christopher W. Fletcher, Albert Kwon, Marten van Dijk, and Srinivas Devadas Abstract—This paper presents post-silicon results for the Ascend secure processor, taped out in a 32 nm SOI process. Ascend prevents information leakage over a processor’s digital I/O pins—in particular, the processor’s requests to external memory—and certifies the program’s execution by verifying the integrity of the external memory. In secure processor design, encrypting main memory is not sufficient for security because where and when memory is accessed reveals secret information. To this end, Ascend is equipped with a hardware Oblivious RAM (ORAM) controller, which obfuscates the address bus by reshuffling memory as it is accessed. To our knowledge, Ascend is the first prototyping of ORAM in custom silicon. Ascend has also been carefully engineered to ensure its timing behaviors are independent of user private data. In 32 nm silicon, all security components combined (the ORAM controller, which includes 12 AES rounds and one SHA-3 hash unit) impose a moderate area overhead of 0.51 mm2. Post tape-out, the security components of the Ascend chip have been successfully tested at 857 MHz and 1.1 V,at which point they consume 299 mW of power. Index Terms—Computation outsourcing, secure processors, oblivious RAM, integrity verification, ASIC design Ç 1INTRODUCTION S embedded and mobile devices become ubiquitous, protects the user’s private data while it is being computed Ausers have become more computationally limited and upon. The smaller the trusted computing base (TCB), the bet- computation outsourcing is becoming more common. From ter from a security perspective. At the same time, removing financial information to medical records, sensitive user data components from the TCB typically impacts performance is being sent to and computed upon by the cloud. Data pri- and/or energy efficiency. Despite the hit in efficiency, the vacy has therefore become a huge concern, as sensitive user computationally-limited user is still motivated to outsource data is being revealed to and can be attacked by potentially computation since compute, energy and memory resources malicious cloud applications, hypervisors/operating sys- are significantly cheaper for the server than the user. tems, or insiders. A serious limitation with current secure hardware solu- One example is health diagnoses given a user’s private tions, however, is that they have to “trust” the program run- medical records [1]. In this case, a mobile device is constantly ning on the secure hardware. To “trust” the program, the monitoring its user’s symptoms and wants to compute the user has to “sign-off” on that program, believing that it is likelihood that the user has some condition given these free of malicious code or bugs that leak sensitive data. But symptoms. To outsource computation, the device sends a applications like MedComp() are seldom trustworthy. Veri- cloud server an encryption of {symptoms, condition of inter- fying bug-free and malicious behavior is a hard problem, if est}, which will be inputs to a program (call it MedComp()). not intractable, for sufficiently complex programs. Frequent After running MedComp() on the user’s private data, the software patches, which are typical in modern software server sends an encryption of the result (e.g., “there is a 55 development, only confound the issue. Furthermore, the percent likelihood that you have the condition”) back to the user may not have access to the program in the first place as user. To maintain privacy, the server must never learn any- the program may be proprietary. thing about the user’s private inputs—the symptoms or dis- The Ascend1 secure processor is a step towards solving this eases of interest—at any time before, during or after the problem. With Ascend, the user sends the server encrypted computation. More examples are given in [1]. input (symptoms and medical information), and requests a One candidate solution is for the server to use tamper- program (e.g., MedComp()) to be executed. The server would resistant hardware [2], [3], [4]. Here, computation takes place then run the program on the user’s private data on an Ascend inside a secure hardware compartment on the server side that processor, which decrypts user input, runs the program and returns encrypted results to the user. Ascend ensures that even a buggy or malicious program cannot leak information L. Ren, C.W. Fletcher, A. Kwon, and S. Devadas are with the MIT Computer about the user’s private data outside the Ascend chip. Science and Artificial Intelligence Laboratory (CSAIL), Department of the EECS, Cambridge, MA. E-mail: {renling, cwfletch, kwonal, devadas}@mit.edu. M. van Dijk is with the University of Connecticut, Department of ECE, 1.1 The Problem with Untrusted Programs Storrs, CT. E-mail: [email protected]. Today’s secure processors (e.g., Intel+TXT [2], XOM [3], Manuscript received 23 July 2016; revised 3 Jan. 2017; accepted 12 Jan. 2017. Aegis [4], and Intel SGX [5]) leak private information when Date of publication 24 Mar. 2017; date of current version 13 Mar. 2019. For information on obtaining reprints of this article, please send e-mail to: [email protected], and reference the Digital Object Identifier below. 1. Ascend stands for Architecture for Secure Computation on Digital Object Identifier no. 10.1109/TDSC.2017.2687463 ENcrypted Data. 1545-5971 ß 2017 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information. REN ET AL.: DESIGN AND IMPLEMENTATION OF THE ASCEND SECURE PROCESSOR 205 running badly written or malicious programs. Consider the Section 1.1. Regardless of whether and how curious() following scenario. A user sends the server its symptoms accesses external memory, Ascend runs for T time and and condition of interest (denoted x) and expects the server behaves in an indistinguishable way from the perspective of to run the MedComp() program described above. Note, the digital side channels. user will send x to the server encrypted, and x is decrypted inside the secure processor. However, the server being curi- 1.3 Contributions ous may instead run the following program in order to learn This paper presents post-silicon results for the Ascend the user’s data. secure processor. We make three primary contributions: void curious(x) { if (x & 0x1) M[0]; 1) We give an overview of the Ascend execution model } to securely run untrusted programs. This part (Sec- M denotes program memory, which will be backed up in tion 2) has been published in an STC workshop cache (inside the processor) and in DRAM/disk (outside paper [10]. the processor). If M[0] is not in cache, whether it is accessed 2) We provide a comprehensive overview of challenges is visible to the server and reveals a bit in the user’s data. in implementing a hardware Oblivious RAM The server can then repeat this experiment with different (ORAM) controller, the core component in the versions of curious(x) to learn other bits in x. Ascend design. We present new techniques to These types of attacks are difficult to prevent. Adding address these issues. These materials (Section 4, 5, 6) cache doesn’t help: The server can re-design curious(x) have been published in a series of our papers [11], to miss the cache. Encrypting data that leaves the secure [12], [13]. processor also doesn’t help. As shown in the above exam- 3) We implement all the techniques described in this ple, the attack can succeed when the server sees where the paper in hardware, tape out the Ascend processor in program accesses memory (the access pattern), and 32 nm silicon, and report hardware evaluation and whether/when accesses occur. measurement results. This part (Section 7) is new Of course, even if the server does run a non-malicious material for this manuscript. 2 program, program characteristics or bugs can leak private The security mechanisms of Ascend take up 0.51 mm of information in the same way. Here, we use a toy example silicon in 32 nm technology, which is roughly half the area of curious() to illustrate the point, but several works have a single processor core. Post tape-out, the security compo- demonstrated information leakage from memory access pat- nents of the Ascend chip has been successfully tested at terns in practical scenarios [6], [7], [8], [9]. 857 MHz and 1.1 V, at which point they consume 299 mW of power. Our design is entirely written in Verilog and is avail- 1.2 Ascend: Obfuscation in Hardware able at https://github.com/ascend-secure-processor/oram. Ascend defeats attacks like those posed by the curious() program by performing obfuscation in hardware. Ascend 1.4 Organization guarantees that given an untrusted program P, a public The rest of the paper is organized as follows. Section 2 length of time T and two arbitrary inputs x and x0: Running presents the Ascend execution model. Section 3 gives a PðxÞ for T time is indistinguishable from running Pðx0Þ for background on Oblivious RAM (ORAM). Section 4 presents T time from any of the Ascend processor’s digital external the main challenges in implementing ORAM in hardware. pins. Ascend has input/output (I/O) and address pins like Sections 5 and 6 describe optimizations which address the a normal processor, but obfuscates both the value and the aforementioned challenges. Sections 7 present ASIC imple- timing of digital signals on these pins. Therefore, the server mentation and measurement results.