mirror of
https://github.com/corda/corda.git
synced 2025-01-09 14:33:30 +00:00
78 lines
4.0 KiB
Markdown
78 lines
4.0 KiB
Markdown
|
# SGX Infrastructure design
|
||
|
|
|
||
|
|
.. important:: This design document describes a feature of Corda Enterprise.
|
||
|
|
|
||
|
|
This document is intended as a design description of the infrastructure around the hosting of SGX enclaves, interaction
|
||
|
|
with enclaves and storage of encrypted data. It assumes basic knowledge of SGX concepts, and some knowledge of
|
||
|
|
Kubernetes for parts specific to that.
|
||
|
|
|
||
|
|
## High level description
|
||
|
|
|
||
|
|
The main idea behind the infrastructure is to provide a highly available cluster of enclave services (hosts) which can
|
||
|
|
serve enclaves on demand. It provides an interface for enclave business logic that's agnostic with regards to the
|
||
|
|
infrastructure, similar to [serverless architectures](details/serverless.md). The enclaves will use an opaque reference
|
||
|
|
to other enclaves or services in the form of [enclave channels](details/channels.md). Channels hides attestation details
|
||
|
|
and provide a loose coupling between enclave/non-enclave functionality and specific enclave images/services implementing
|
||
|
|
it. This loose coupling allows easier upgrade of enclaves, relaxed trust (whitelisting), dynamic deployment, and
|
||
|
|
horizontal scaling as we can spin up enclaves dynamically on demand when a channel is requested.
|
||
|
|
|
||
|
|
## Infrastructure components
|
||
|
|
|
||
|
|
Here are the major components of the infrastructure. Note that this doesn't include business logic specific
|
||
|
|
infrastructure pieces (like ORAM blob storage for Corda privacy model integration).
|
||
|
|
|
||
|
|
* [**Distributed key-value store**](details/kv-store.md):
|
||
|
|
Responsible for maintaining metadata about enclaves, hosts, sealed secrets and CPU locality.
|
||
|
|
|
||
|
|
* [**Discovery service**](details/discovery.md)
|
||
|
|
Responsible for resolving an enclave channel to a specific enclave image and a host that can serve it using the
|
||
|
|
metadata in the key-value store.
|
||
|
|
|
||
|
|
* [**Enclave host**](details/host.md):
|
||
|
|
This is a service capable of serving enclaves and driving the underlying traffic. Third party components like Intel's
|
||
|
|
SGX driver and aesmd also belong here.
|
||
|
|
|
||
|
|
* [**Enclave storage**](details/enclave-storage.md):
|
||
|
|
Responsible for serving enclave images to hosts. This is a simple static content server.
|
||
|
|
|
||
|
|
* [**IAS proxy**](details/ias-proxy.md):
|
||
|
|
This is an unfortunate necessity because of Intel's requirement to do mutual TLS with their services.
|
||
|
|
|
||
|
|
## Infrastructure interactions
|
||
|
|
|
||
|
|
* **Enclave deployment**:
|
||
|
|
This includes uploading of the enclave image/container to enclave storage and adding of the enclave metadata to the
|
||
|
|
key-value store.
|
||
|
|
|
||
|
|
* **Enclave usage**:
|
||
|
|
This includes using the discovery service to find a specific enclave image and a host to serve it, then connecting to
|
||
|
|
the host, authenticating(attestation) and proceeding with the needed functionality.
|
||
|
|
|
||
|
|
* **Ops**:
|
||
|
|
This includes management of the cluster (Kubernetes/Kubespray) and management of the metadata relating to discovery to
|
||
|
|
control enclave deployment (e.g. canary, incremental, rollback).
|
||
|
|
|
||
|
|
## Decisions to be made
|
||
|
|
|
||
|
|
* [**Strategic roadmap**](decisions/roadmap.md)
|
||
|
|
* [**CPU certification method**](decisions/certification.md)
|
||
|
|
* [**Enclave language of choice**](decisions/enclave-language.md)
|
||
|
|
* [**Key-value store**](decisions/kv-store.md)
|
||
|
|
|
||
|
|
## Further details
|
||
|
|
|
||
|
|
* [**Attestation**](details/attestation.md)
|
||
|
|
* [**Calendar time for data at rest**](details/time.md)
|
||
|
|
* [**Enclave deployment**](details/enclave-deployment.md)
|
||
|
|
|
||
|
|
## Example deployment
|
||
|
|
|
||
|
|
This is an example of how two Corda parties may use the above infrastructure. In this example R3 is hosting the IAS
|
||
|
|
proxy and the enclave image store and the parties host the rest of the infrastructure, aside from Intel components.
|
||
|
|
|
||
|
|
Note that this is flexible, the parties may decide to host their own proxies (as long as they whitelist their keys) or
|
||
|
|
the enclave image store (although R3 will need to have a repository of the signed enclaves somewhere).
|
||
|
|
We may also decide to go the other way and have R3 host the enclave hosts and the discovery service, shared between
|
||
|
|
parties (if e.g. they don't have access to/want to maintain SGX capable boxes).
|
||
|
|
|
||
|
|
|