Attested Connection Process

Overview

When you use OBLV Client to connect to an enclave, it creates a secure connection between your local environment and the enclave that is running your application. This process guarantees that all communication is handled securely while maintaining data confidentiality and integrity throughout the entire session. This page presents the operational flows that underpin the establishment of secure connections. The main two operational flows are the Enclave Inititialisation flow which launches the OBLV Client and performs initial attestation of the enclave and the Client Request flow which operates the OBLV Client and attests the enclave with the additional services and plugins installed by the user.

Enclave Initialisation Flow

The enclave initialisation flow is a phase where the OBLV Client is executed in admin/controller mode, where it acts as a binary. This process is initiated directly by the underlying host machine (pod) itself, which performs the following steps:

1

Execution Mode

The pod launches the OBLV Client as a binary.

2

Attestation of the Enclave

At this preliminary stage, the pod attests the enclave to ensure that the base services are operational and secure. During this phase, additional plugins or applications are not yet loaded into the enclave.

This initial step is crucial for setting up a trusted foundation before any user-specific configurations or extensions are introduced. This initiation may occur in scenarios such as scaling up applications.

Client Request Flow

The client request flow outlines the interaction between the client-side OBLV Client, operating as a reverse proxy, and the server-side components:

Execution Mode

The OBLV Client operates in client/user mode, installed on the local machine.

Attestation of the Enclave

During execution, the attestation process validates not only the default and base services but also any additional services and plugins installed by the user.

This flow takes place every time a user connects to the enclave.

Detailed Steps of the Flows

Below, you will find detailed steps of both the Enclave Initialisation and the Client Request Flows. Both are very similar, however, all the user-defined services and plugins are only attested during the Client Request Flow.

1

The pod starts OBLV Client (only in the Enclave Initialisation Flow).

2

OBLV Client processes the command-line arguments and determines the following

1. The configuration file path.
2. Enclave's URL.
3. The mode it needs to operate in (either user or controller depending on the flow type).

3

OBLV Client reads and parses the Configuration file.

4

OBLV Client starts to check the health state of the enclave and returns a response with a health status.

5

OBLV Client starts the attestation process

6

OBLV Client uploads the manifest to the enclave, which in turn returns the upload response to the OBLV Client.

7

OBLV Client returns a status code to the user indicating success or failure, and if successful, starts the HTTP reverse proxy on the given port.

Attestation Process

After OBLV Client receives a response with a success status for the health check, it goes through the validation process, where it validates the enclave based on the following details:

Attestation document

Validates the PCR codes and Nonce field of the attestation document. The details of these fields can be found here.

Manifest

A yaml file describing the application running inside the enclave is received. From this manifest, the following details are validated.

• Docker digests for all of the containers running inside the enclave.
• Configuration digests for the containers running inside the enclave.

Note

Currently, the validation process involves comparing the string values in the Attestation response with those in the user-provided config file. However, it can be validated by retrieving the Docker digests from the container registry and calculating the hashes for the required config on the user's end.

The flow below showcases the attestation process:

Manifest Upload

The OBLV Client needs to upload the manifest to the enclave. The flow below exemplifies the manifest upload process:

Note

For a more detailed description of the connection and the attestation processes, please contact the Oblivious team to request access to a whitepaper.

What's Next?

Navigate to Guides to follow step-by-step guides on how to use OBLV Deploy functionalities to provide isolation and attestation to your applications.