Skip to content

Attestation

Learn more about Confidential Computing 📖

The aim of this guide is to discuss attestation in more detail.

We will cover the following topics:

Note that while the attestation process follows the same guiding principles, the low-level details can differ depending on the selected Confidential platform and Cloud providers. We currently support the deployment of BlindBoxes on AMD SEV-SNP confidential VMs with Azure, but plan to support other platforms in future releases.

What is attestation?

Attestation is a key concept in Confidential Computing. It is the process which allows us to have hardware-derived proof that we are communicating with an application running in a Trusted Execution Environment (TEE). It can be viewed a bit like a checksum for applications running in secure Confidential environments.

This process can provide us with additional information about the configuration of the TEE and the code running inside of it, allowing BlindBox to perform additional security checks to enhance the application's security posture.

What do we attest?

The attestation report generated by the TEE hardware provider allows us to verify that:

  • We are communicating with a genuine and correctly-configured TEE.
  • The code loaded inside of the TEE is the expected code (and has not been modified in any way).
  • The VM is running in production mode and not debug mode.
  • The attestation report contains an authentic signature from the hardware provider.
  • The signature of the service that verifies the attestation report's signature is authentic.

Who is responsible for attestation?

The attestation process is an automated process managed by BlindBox which also replies on a couple of trusted dependencies.

✅ Attestation is set-up to be performed by default whenever an end user starts a new connection to a BlindBox- from a customer perspective, no additional actions are required.

⛔ If any of our attestation checks fail, the end user will be unable to connect to the BlindBox.

📜 The BlindBox attestation process relies on the enclave hardware provider such as AMD to generate and sign attestation reports.

🕵 The process also relies on either a service provided by the hardware provider or an independent trusted enforcer such as the Microsoft Attestation Service to verify and sign this report to vouch for its validity.

The attestation workflow

Let’s walk through the whole life cycle of the attestation process from the moment an end user starts a new connection with a SaaS application deployed with BlindBox.

  1. The end user queries the application. This triggers a new connection request, which in turn triggers the attestation process.
  2. BlindBox requests attestation from the TEE hardware provider.
  3. An attestation report is generated by the hardware provider and is signed by a hardware-derived key.
  4. This report is verified by a service provided either by the hardware provider or a trusted independent third party.
  5. If this check is successful, the service will sign and send a report or token to BlindBox containing information gathered during the attestation process.
  6. BlindBox will use the service's public key to verify this signature.
  7. BlindBox will then use the details provided in this report or token to verify additional security details.
  8. BlindBox returns an error if any of these checks are unsuccessful. If not, the end user will successfully connect to the BlindBox application and their query will be processed.

What happens when attestation fails?

Let's take a look at some examples of what happens if the attestation process is not successful.

Non-compliant Confidential VM

Query: 

res = requests.post(url=f"http://{CONFIDENTIAL_VM_IP_ADDRESS}/generate", json={"input_text": "def print_hello_world():"})

Response: 

$ __main__.NonCompliantUvm: Attestation validation failed (non-compliant uvm). Exiting.

Debug mode

Query: 

res = requests.post(url=f"http://{CONFIDENTIAL_VM_IP_ADDRESS}/generate", json={"input_text": "def print_hello_world():"})

Response: 

$ __main__.DebugMode: Attestation validation failed (enclave is in debug mode). Exiting.

Conclusions

This concludes our advanced guide into how attestation is implemented in BlindBox.

We have seen:

  • What attestation is
  • What details are verified during the attestation process
  • The role of each concerned party in attestation
  • The life cycle of the attestation process
  • What to expect if attestation fails

If you have any further questions or want to know more detailed platform-specific information, please get in touch!

Contact us