Authors:
(1) Mathias Brossard, Systems Group, Arm Research;
(2) Guilhem Bryant, Systems Group, Arm Research;
(3) Basma El Gaabouri, Systems Group, Arm Research;
(4) Xinxin Fan, IoTeX.io;
(5) Alexandre Ferreira, Systems Group, Arm Research;
(6) Edmund Grimley-Evans, Systems Group, Arm Research;
(7) Christopher Haster, Systems Group, Arm Research;
(8) Evan Johnson, University of California, San Diego;
(9) Derek Miller, Systems Group, Arm Research;
(10) Fan Mo, Imperial College London;
(11) Dominic P. Mulligan, Systems Group, Arm Research;
(12) Nick Spinale, Systems Group, Arm Research;
(13) Eric van Hensbergen, Systems Group, Arm Research;
(14) Hugo J. M. Vincent, Systems Group, Arm Research;
(15) Shale Xiong, Systems Group, Arm Research.
Editor's note: this is part 1 of 6 of a study detailing the development of a framework to help people collaborate securely. Read the rest below.
Table of Links
- Abstract and 1 Introduction
- 2 Hardware-backed Confidential Computing
- 3 IceCap
- 4 Veracruz
- 4.1 Attestation
- 4.2 Programming model
- 4.3 Ad hoc acceleration
- 4.4 Threat model
- 5 Evaluation and 5.1 Case-study: deep learning
-
5.2 Case-study: video object detection
-
5.3 Further comparisons
-
- 6 Closing remarks and References
Abstract
Sensitive computations are now routinely delegated to third parties. In response, Confidential Computing technologies are being introduced to microprocessors, offering a protected processing environment, which we generically call an isolate, providing confidentiality and integrity guarantees to code and data hosted within—even in the face of a privileged attacker. Isolates, with an attestation protocol, permit remote third-parties to establish a trusted “beachhead” containing known code and data on an otherwise untrusted machine. Yet, the rise of these technologies introduces many new problems, including: how to ease provisioning of computations safely into isolates; how to develop distributed systems spanning multiple classes of isolate; and what to do about the billions of “legacy” devices without support for Confidential Computing?
Tackling the problems above, we introduce Veracruz, a framework that eases the design and implementation of complex privacy-preserving, collaborative, delegated computations among a group of mutually mistrusting principals. Veracruz supports multiple isolation technologies and provides a common programming model and attestation protocol across all of them, smoothing deployment of delegated computations over supported technologies. We demonstrate Veracruz in operation, on private in-cloud object detection on encrypted video streaming from a video camera. In addition to supporting hardware-backed isolates—like AWS Nitro Enclaves and Arm® Confidential Computing Architecture Realms—Veracruz also provides pragmatic “software isolates” on Armv8-A devices without hardware Confidential Computing capability, using the high-assurance seL4 microkernel and our IceCap framework.
1 Introduction
Code and data are now routinely shared with a delegate who is better placed, either through economies of scale, or computational capacity, to host a computation. While Cloud computing is the obvious exemplar of this trend, other forms of distributed computing—including volunteer Grid Computing, wherein machines lend spare computational capacity to realize some large computation, and Ambient Computing, wherein computations are mobile and hop from device-to-device as computational contexts change—also see computations freely delegated to third parties.
At present, in the absence of the widespread deployment of Advanced Cryptography [42], delegating computation to a third party inexorably means entering into a trust relationship with the delegate, and for some especially sensitive computations this may be simply unacceptable. Yet, even for less sensitive delegated computations, there is still an interest in limiting the scope of this trust relationship. In the Cloud context, though established hosts may be reputable, technical means may be desired to shield computations from prying or interference which may originate from many sources, not only from the hosting company themselves: malefactors may exploit hypervisor bugs to spy on co-tenants, for example. Cloud hosts also increasingly see an interest in deniable hosting, wherein technical measures ensure that a customer’s computations simply cannot be interfered with, or spied upon, by the hosts themselves—even in the face of legal compulsion. For Ambient and volunteer Grid Computing, these concerns also manifest: nodes must be assumed hostile and assumed to be trying to undermine a computation, either through malice or as a consequence of bugs or glitches. As a result, volunteer Grid Computing deployments may schedule computations on multiple nodes and check for consistency [4].
In response, novel Confidential Computing technologies are being added to microprocessor architectures and cloud infrastructure, providing protected computing environments— variously called Secure Enclaves, Realms, Trusted Execution Environments, and which we generically call isolates— that provide strong confidentiality and integrity guarantees to code and data hosted within, even in the face of a privileged attacker. Isolates are also typically paired with an attestation protocol, allowing a third-party to deduce, with high confidence, that a remote isolate is authentic and configured in a particular way. Taken together, one may establish a protected “beachhead” on an untrusted third-party’s machine—exactly what is needed to protect delegated computations.
Isolates offer a range of benefits for system designers, namely allowing programmers to design arbitrarily complex privacy-preserving distributed systems using standard tools and programming idioms that run at close to native speed. Moreover, compared to cryptographic alternatives, Confidential Computing technology is available for use and deployment in real systems today. Yet, the emergence of Confidential Computing technology poses some interesting problems.
First, note that Confidential Computing technologies simply provide an empty, albeit secure, isolate. Associated questions like how computations are securely provisioned into an isolate, how to make this process straightforward and foolproof, and how systems are designed and built around isolates as a new kind of primitive, are left unanswered. Moreover, for some types of distributed system—such as Grid and Ambient computing systems, previously discussed—it is feasible that different types of isolate will be used within a single larger system. Here, bridging differences in attestation protocol and programming model will be key, as will be easing deployment and scheduling of computations hosted within isolates.
For this reason, we introduce our main research contribution: Veracruz, a framework that abstracts over isolates and their associated attestation processes. Veracruz supports multiple different isolation technologies, including hardwarebacked isolates like AWS Nitro Enclaves and Arm Confidential Computing Architecture Realms on a private branch. Adding support for more is straightforward. Veracruz provides a uniform programming model across different supported isolates—using WebAssembly (Wasm, henceforth) [96]—and a generalized form of attestation, providing a “write once, isolate anywhere” style of development: programs can be protected using any supported isolation technology without recompilation. Veracruz is discussed in §4.
Veracruz captures a particularly general form of interaction between mutually mistrusting parties. As a result, Veracruz can be specialized in a straightforward manner to obtain an array of delegated, privacy-preserving computations of interest. In support of this claim we provide a description of how Veracruz can be used for secure ML model aggregation, and an industrial case-study built around AWS Nitro Enclaves, demonstrating an end-to-end encrypted video decoding and object-detection flow, using a deep learning framework processing video obtained from an IoT camera. These case-studies, and further benchmarking, are discussed in §5.
In §2 we argue that Confidential Computing technology is likely to be widely deployed within industry, despite wellknown flaws in particular implementations. Yet, billions of existing devices have already been shipped without any explicit support for Confidential Computing, and these devices will continue to be used for years, if not decades, to come. Is there some pragmatic isolation mechanism that we could use on “legacy” devices which, while falling short of the confidentiality and integrity guarantees offered by hardwarebacked Confidential Computing mechanisms, can yet provide believable isolation for workloads? Rising to this challenge, we introduce our second research contribution: IceCap, a pragmatic “software isolate” for Armv8-A devices without explicit support for Confidential Computing. IceCap uses the high-assurance seL4 microkernel to provide strong confidentiality and integrity guarantees for VMs, with little overhead.
IceCap is supported by Veracruz, and taken together, one may design and deploy delegated computations across hardware- and software-isolates on next-generation and legacy hardware, alike. We introduce IceCap in §3, as a stepping stone to the introduction of Veracruz.
This paper is available on arxiv under CC BY 4.0 DEED license.