Table of Contents
Fetching ...

LSKV: A Confidential Distributed Datastore to Protect Critical Data in the Cloud

Andrew Jeffery, Julien Maffre, Heidi Howard, Richard Mortier

TL;DR

This work presents CKVS, a confidential, ledger-backed datastore built on the Confidential Consortium Framework that provides an etcd-compatible API while keeping cloud operators out of the trust boundary. It argues that simple lift-and-shift strategies are insufficient for confidentiality and offers incremental adoption via TEEs and write receipts to ease migration. CKVS combines a flexible consistency model (optimistic latest data and pessimistic historical data), a public ledger with Merkle-tree signatures, and verifiable write receipts to enable end-to-end trust in intermediary services. The evaluation shows CKVS achieving competitive performance with etcd, scalable horizontal and vertical deployment, and effective auditability, making it a practical foundation for building trustworthy cloud-native datastores under confidential computing constraints.

Abstract

Software services are increasingly migrating to the cloud, requiring trust in actors with direct access to the hardware, software and data comprising the service. A distributed datastore storing critical data sits at the core of many services; a prime example being etcd in Kubernetes. Trusted execution environments can secure this data from cloud providers during execution, but it is complex to build trustworthy data storage systems using such mechanisms. We present the design and evaluation of the Ledger-backed Secure Key-Value datastore (LSKV), a distributed datastore that provides an etcd-like API but can use trusted execution mechanisms to keep cloud providers outside the trust boundary. LSKV provides a path to transition traditional systems towards confidential execution, provides competitive performance compared to etcd, and helps clients to gain trust in intermediary services. LSKV forms a foundational core, lowering the barriers to building more trustworthy systems.

LSKV: A Confidential Distributed Datastore to Protect Critical Data in the Cloud

TL;DR

This work presents CKVS, a confidential, ledger-backed datastore built on the Confidential Consortium Framework that provides an etcd-compatible API while keeping cloud operators out of the trust boundary. It argues that simple lift-and-shift strategies are insufficient for confidentiality and offers incremental adoption via TEEs and write receipts to ease migration. CKVS combines a flexible consistency model (optimistic latest data and pessimistic historical data), a public ledger with Merkle-tree signatures, and verifiable write receipts to enable end-to-end trust in intermediary services. The evaluation shows CKVS achieving competitive performance with etcd, scalable horizontal and vertical deployment, and effective auditability, making it a practical foundation for building trustworthy cloud-native datastores under confidential computing constraints.

Abstract

Software services are increasingly migrating to the cloud, requiring trust in actors with direct access to the hardware, software and data comprising the service. A distributed datastore storing critical data sits at the core of many services; a prime example being etcd in Kubernetes. Trusted execution environments can secure this data from cloud providers during execution, but it is complex to build trustworthy data storage systems using such mechanisms. We present the design and evaluation of the Ledger-backed Secure Key-Value datastore (LSKV), a distributed datastore that provides an etcd-like API but can use trusted execution mechanisms to keep cloud providers outside the trust boundary. LSKV provides a path to transition traditional systems towards confidential execution, provides competitive performance compared to etcd, and helps clients to gain trust in intermediary services. LSKV forms a foundational core, lowering the barriers to building more trustworthy systems.
Paper Structure (43 sections, 11 figures)

This paper contains 43 sections, 11 figures.

Figures (11)

  • Figure 1: High-level view of a typical 3-node cluster.
  • Figure 2: Architecture and trust during incremental adoption. Green is secure, yellow is using encryption but not necessarily integrity protected, red is insecure. The background represents the security of the environment.
  • Figure 3: Example of a malicious proxy being detected with write receipts.
  • Figure 4: CKVS internals. Dashed arrows imply asynchronous communication.
  • Figure 5: Timeline of Raft term changes and revisions. Annotated vertices show Raft term history entries.
  • ...and 6 more figures