Verify attestations using the Marlin Hub UI

In this guide, we describe how to verify attestations using the Marlin Hub UI.

The UI

Navigate to the following URL in a browser of your choice: https://hub.marlin.org/oyster/attestation/

You should see a page which looks something like this:

As you can probably gather from the UI, there are two ways you can use this to verify attestations.

Verify a hex-encoded attestation

You can verify an existing hex-encoded attestation by selecting the Paste Hex tab on the tab bar and pasting the attestation in the text box below it. Then click the Verify button to verify and print the attestation fields below.

If passing it directly on the command line is unwieldy or you already have the attestation in a file, you can use the --attestation-hex-file option and give it a text file containing the hex-encoded attestation.

Verify a running enclave

You can also verify a running enclave given its attestation endpoint using the Attestation URL tab on the tab bar and pasting the attestation endpoint in the textbox below it. Then click the Verify button to verify and print the attestation fields below.

The verifier fetches the attestation by making a HTTP request to the specified endpoint, which means that the enclave needs to have a server running on that endpoint. This is handled automatically for enclaves deployed using the blue enclave image (which is the default when you deploy using oyster-cvm deploy unless you explicitly specified --image-url during deployment) since it runs an attestation server at the expected endpoint, but it is something to keep in mind for custom enclave images. We recommend custom images to also run an attestation server on the same port for consistency across the ecosystem unless it is truly unavoidable, so it is very likely that the above works across all enclaves regardless of the underlying enclave image.

Verification results

Upon clicking the Verify button, you can expect to see something like this:

Attestation expectations

Usually, attestation verification only implies verification of the attestation document structure and the certificate chain. In addition, you might want to specify expected values for fields in the attestation in order to run additional checks against the attestation. Most commonly, you would want to verify that the attestation is coming from a real Nitro enclave that is running an expected version of code.

Unlike other verification methods, the UI does not let you specify or customize expectations, you are limited to what is enabled by default.

Verify the root of trust

Verifying that the root of trust matches the expected AWS Nitro public key lets you ensure that the attestation came from a valid AWS Nitro Enclave with all the expected guarantees of a TEE.

important

It is a critical security check that must not be missed for production deployments, therefore it is enabled by default with the AWS Nitro root key.

Verify measurements

Measurements lets you know what code is running inside an enclave and thereby deduce the behaviour of an enclave.

caution

It is a critical security check that must not be missed for production deployments. However, it is not enabled by default since there isn't really a sensible default that can be set.

The UI does not let you specify measurements, instead users are expected to cross-check the measurements manually.

Verify liveness

The UI also sets expectations about the timestamp field in the attestation. We consider liveness checks a good practice for regular deployments, hence it is enabled by default at 5 minutes.

So what exactly is verified?

To summarize, the above method verifies the following:

• the attestation document is valid (in terms of structure), thereby enabling extraction and verification of attestation fields
• the attestation document is signed by a valid certificate chain, thereby enabling extraction and verification of the root public key
• all specified attestation expectations
  • NONE by default