Skip to content

How we protect your data

BlindBox protects user data with two key elements:

  • By leveraging confidential computing technologies to deploy applications within secure hardware-based highly-isolated environment called secure enclaves or Trusted Execution Environments (TEEs).
  • By allowing data owners to set custom security policies to control what can happen inside of their BlindBox enclave.

Let's now take a look at the technologies behind our solution and how they protect user data!

Confidential Computing

In typical workflows, data may be encrypted in transit, but it is accessible in clear when being analyzed by software. Confidential computing is a fast-growing new technology which aims to tackle this problem and protects data during computation.

Solutions usually center around three key concepts.

  • Isolation: data is processed in highly-isolated Trusted Execution Environments.
  • Attestation: we verify the authenticity of the Trusted Execution Environments and its components.
  • Runtime encryption: data is encrypted, even during analysis.

Let's dive into a bit more detail about these concepts.

Isolation

In a confidential workflow, data is sent to and analyzed within a Trusted Execution Environment (TEE), otherwise known as a secure enclave. Data sent to the enclave is only decrypted in isolated environments or when being processed. Even if hackers or malicious insiders gain access to the host machine an enclave is running on, they will not be able to access data inside the enclave.

TEE_dark TEE_light

We currently support the following TEEs: AMD SEV-SNP confidential VM.

Attestation

When a user wants to establish communication with an enclave, a process called attestation can be performed to verify the authenticity of the TEE, its configuration and elements such as the application running in the TEE. This means users can be sure the application they are querying is deployed within a genuine TEE before sending any data.

Important

Where attestation verifies the application code, the goal is to check that the code running is indeed the expected application code and that it has not been tampered with. The attestation doesn't audit the application code itself. You could compare it to using a checksum utility when you download a software.

❌ If any of these checks fail, an error is produced and the user will not be able to communicate with the enclave. For BlindBox, this means that a user will only be able to connect to a genuine, verified TEE.

✔️ If these checks are successful, the user is able to communicate with the enclave securely using TLS. The enclave's private key never leaves the enclave, so it is never accessible to anyone, including the cloud or service provider!

Let's take a look at the basic attestation workflow for BlindBox:

attest_light attest_dark

  1. When a user queries a BlindBox application, our client will attempt to create a connection between the user and the application running in the BlindBox. This will trigger the attestation process.

  2. The TEE will be asked to generate a report to prove its identity. This report is signed by keys derived from hardware.

  3. This report and a TLS certificate, which will be used for communications if attestation is successful, are sent back to the client.

  4. A verification process is triggered, where the client will check the TEE is authentic and has the expected identity and settings.

  5. If the verification process is successful, communication via TLS is established and the query will be performed. If the verification process fails, an attestation error will be returned.

Here, we were able to transcribe our audio file while keeping the audio file confidential, even from the SaaS vendor!

For more detailed information about how attestation is implemented in BlindBox, see our advanced attestation guide.

Verifying security

BlindBox is under development, so this code is still being implemented, but we wanted to give you a clear illustration of what will happen when the Confidential VM is not secure.

  • If we talk to a server without signature from the hardware provider (meaning it has no collateral to prove it is secure), then an error will be raised:

    import blindbox.requests as requests

CONFIDENTIAL_VM_IP = "127.0.0.1:8080" # replace with your VM IP address + port

session = requests.SecureSession(addr=CONFIDENTIAL_VM_IP)

>> NotAnEnclaveError

  • If the first check passes, but the hash of the code is not the publicly available hash of BlindBox, another error will be raised:

    import blindbox.requests as requests

CONFIDENTIAL_VM_IP = "127.0.0.1:8080" # replace with your VM IP address + port

session = requests.SecureSession(addr=CONFIDENTIAL_VM_IP)

>> InvalidEnclaveCode

⌛ BlindBox security features (coming soon)

  • Attested network isolation: We will add an additional layer to our attestation process where we will verify that the BlindBox we are connecting to has the expected security policies in place.

  • Data owner security policies: We'll wrap application images in an additional security layer which enforces custom security policies. These custom policies will allow the data owner to set up:

    • Authentication: Data owners will be able to specify who should be able to query their BlindBox.
    • Outward-bound network isolation: Data owners will be able to whitelist external domains that the SaaS application may contact if necessary. Any calls to external domains not on this whitelist will be blocked.

blindbox_architecture_light blindbox_architecture_dark

These security features allow us to offer a solution which is able to rival the security provided by on-premise SaaS deployment while retaining all the advantages of SaaS Cloud deployment!

Learn more about Confidential Computing 📖