Table of Links
Abstract and I. Introduction
II. Background
III. Paranoid Stateful Lambda
IV. SCL Design
V. Optimizations
VI. PSL with SCL
VII. Implementation
VIII. Evaluation
IX. Related Work
X. Conclusion, Acknowledgment, and References
VI. PSL WITH SCL
We discuss the experience and implementation effort to use SCL for PSL. Every PSL worker is started with a Worker Enclave in SCL, and attested by In-Enclave FaaS Leader. The code for PSL is directly executed on sandboxed Javascript engine. Our key distribution and management protocol provides every worker enclave with unique private keys derived from a master key by the FaaS Leader. The keys can be easily generated, verified and rotated to prevent potential key leakage.
A. Sandboxing
To isolate in-enclave applications from the PSL infrastructure, we use a sandboxed Javascript interpreter, Duktape, to dynamically interpret the Lambda program at runtime. In order for sandboxed Javascript program communicate with its other counterparts, we modify the Duktape and introduce two functions put and get to interact with SCL. We note that the program is transparent with and sandboxed from the underlying cryptographic schemes, so that it cannot observe and unintentionally leak the cryptographic secrets.
B. Attestation
PSL builds its attestation protocol on top of the Asylo’s attestation primitives. For each worker or FaaS leader that requires code running in the enclave, it starts with an Assertion Generation Enclave(AGE) as a Quoting Enclave(QE) that helps generates quotes on behalf of the enclave. The QE is certified by the Provisioning Certification Enclave (PCE), which uses Provisioning Certification Key (PCK) that is written, and distributed by Intel to sign QE’s hardware REPORT. The PCK certificate chain can be traced back to Intel SGX Root Certificate Authority(CA). After receiving an assertion request from a remote attester, the worker or FaaS leader establishes bi-directional local attestation with AGE to forward the assertion request from the remote attester and to get the assertion from the AGE. After the remote attester verifies the assertion, they establish a secure gRPC channel and the remote attester sends confidential information, such as crypographic keys, to the worker or FaaS leader.
C. Launching Process
Each PSL worker node starts a lambda runtime in the enclave, which is registered with a third-party job scheduler. To launch a PSL workload, the user contacts the job scheduler with an encrypted program and corresponding launching configurations, such as how many lambdas are needed. The job scheduler contacts idle worker nodes within its registry and forwards the encrypted program to the potential worker nodes. To prevent malicious worker nodes, the user sends cryptographic keys via a separate channel through FaaS leader that runs in an enclave. After verifies the identity of the FaaS leader using remote attestation, the worker distributes the keys to the FaaS leader. The workers which receive the encrypted program also verify itself with remote attestaion with the FaaS leader. After the workers are authenticated, the FaaS leader forwards the cryptographic keys to the worker nodes, and the worker nodes can decrypt and run the program. When the PSL workload is finished, all the user-related confidential information, such as the content of the memtable, is cleared by a RESET command by the FaaS leader, because restarting the lambda runtime may take longer time. The FaaS leader keeps track of the idleness of the workers and only distribute keys to the idle workers. The workers after RESET need to be re-attested for the next PSL workload.
D. Key Management
In PSL, key management is needed for worker enclaves to verify each other’s identity, and to satisfy the security guarantees of DataCapsules. Our key management design goals are: 1) Provenance: by providing a unique key pair per worker enclave; 2) Authentication: each worker enclave needs to sign with the (derived) DataCapsule owner identity; 3), PSL uses a hierarchical structure with a parent FaaS Leader and multiple child Lambda Enclaves. We want to design a key management scheme to efficiently manage hierarchically structured key pairs with low overhead.
To derive a each set of public/private key pairs from a master key, we use Hierarchical Deterministic (HD) Wallet from Bitcoin Wallet[30]. HD Wallet is a key management scheme that allows all the child public keys to be derived from a single parent public key. We use hardened derived child keys, a scheme of HD wallet to prevent the problem of HD Wallet that the leakage of the child private key leaks the private key of the parent. HD Wallet enables efficient key management in PSL as follows: 1) After attestation between the client and the FaaS Leader, the client sends its owner key to the FaaS Leader. 2) The FaaS Leader generates a child public/private key pair for the current running application. 3) The FaaS Leader uses the application child key pair to generate multiple grandchild key pairs, one per worker enclave. 4) The FaaS Leader attests and sends every enclave its grandchild key pair. 5) FaaS Leader multicasts the application public key to all enclaves. 6) Each worker enclave derives the other worker enclaves’ public keys using the application public key.
Key Leakage and Rotation We enable efficient key rotation scheme with SCL that can derive and distribute a new set of key pairs for the workers from the new hardened key pair. This prevents the cryptographic key leakage over time. This is done by (1) client deriving a new child hardened key pair and multicasting the public key to all enclave workers; (2) the FaaS Leader then derives a new set of key pairs for the workers from the new key pair. To handle lost multicasted messages or enclave worker failure, we can rely on SCL’s consistency coordinator and include the current parent public key in the SYNC reports. This ensures that any enclave worker can verify that they are using the correct signing keys in a given epoch by validating the keys against the consistency coordinator’s SYNC reports. The frequency in which key rotation occurs depends on the user’s threat model. Users may choose to rotate keys per function invocation. This ensures any new function invocations may not affect previous function invocations.
VII. IMPLEMENTATION
Our codebase contains 32,454 LoC in C++ excluding comments and 43,011 LoC code base in total counted by cloc[1]. The core SCL KVS code consisted of roughly 4,000 lines of code in C++, excluding the attestation, distributive application implementations, and experiment scripts. We implement the KVS directly on top of Asylo instead of on a containerized enclave environment. This yields a much smaller TCB than related works such as Speicher [9].
Asylo is a hardware-agnostic framework for TEEs, supporting Intel SGX(v1 and v2) and ARM TrustZone. It also provided a POSIX compliant library that made it easier to port existing applications into enclaves. We use ZeroMQ to implement network multicast and communications between Worker Enclaves. We use gRPC to create a secure FaaS Leader Enclave, which can generate HD Wallet keypairs and startup enclave workers. We use DukTape, an embedded JavaScript engine in C++, to sandbox enclave applications, now that enclaves can directly execute JavaScript code.
CapsuleDB is implemented in C++ and is 2200 LoC. It also uses several features of Asylo and the structures created in the PSL implementation. We use a similar memtable implementation, but leverage mutexes on each entry instead of a spinlock. Due to the implementation timeline, the current version of CapsuleDB writes data to disc rather than to a network attached DataCapsule using the Boost serialization library. The DataCapsule replication service contains about 1,000 LoC in C++ excluding comments. We use RocksDB as embedded persistent storage for each DataCapsule replica, ZeroMQ to implement network communication between DataCapsule replicas, and OpenSSL for signature and verification.
:::info
Authors:
(1) Kaiyuan Chen, University of California, Berkeley ([email protected]);
(2) Alexander Thomas, University of California, Berkeley ([email protected]);
(3) Hanming Lu, University of California, Berkeley (hanming [email protected]);
(4) William Mullen, University of California, Berkeley ([email protected]);
(5) Jeff Ichnowski, University of California, Berkeley ([email protected]);
(6) Rahul Arya, University of California, Berkeley ([email protected]);
(7) Nivedha Krishnakumar, University of California, Berkeley ([email protected]);
(8) Ryan Teoh, University of California, Berkeley ([email protected]);
(9) Willis Wang, University of California, Berkeley ([email protected]);
(10) Anthony Joseph, University of California, Berkeley ([email protected]);
(11) John Kubiatowicz, University of California, Berkeley ([email protected]).
:::
:::info
This paper is available on arxiv under CC BY 4.0 DEED license.
:::
