Skip to content

Assignment 1: Attest CAS

The second assignment focuses on how to attest and verify SCONE CAS. SCONE CAS is a configuration and attestation service. This means that SCONE CAS can verify the integrity of applications and services. This is done by validating if an attestation report from the application satisfies a specified policy. We will focus on this aspect in a later assignment. An attestation report is a signed report that enables CAS to establish trust in services.

With the help of an attestation report, CAS can verify that:

  • the service executes the right code, i.e., the code defined in the service's policy,
  • the service executes inside of an enclave, i.e., inside of an encrypted region of main memory that only the service code itself can access, and
  • the firmware of the CPU is up-to-date, i.e., the CPU has all security patches installed, and
  • there are no known vulnerabilities known for this CPU, and
  • the filesystem of the service is up to date.

We delegate quite some responsibility to SCONE CAS. Before doing so, we need to check that SCONE CAS itself can be trusted. In particular, SCONE CAS satisfies all the above-mentioned properties. We show how to establish trust in a SCONE CAS instance with the help of the scone CLI.

Task

Your task is to attest a SCONE CAS instance with the help of command scone cas attest. To attest a SCONE CAS, one needs to know MrEnclave (i.e., the initial state of the CAS enclave) and/or MrSigner (i.e., a public key to verify the signature of the CAS enclave).

To attest a debug CAS, one needs to set a view flag for the scone CLI accepting to talk to this CAS instance.

Task 1: Extract MrEnclave

To attest CAS, we need to determine MrEnclave of the current version of CAS. For a production CAS, one should also verify MrSigner of CAS. We will see in a later assignment, that one can load that information from a CAS. In other words, as soon as you know MrEnclave and MrSigner, you will be able to get information for future versions of CAS.

For the initial attestation of CAS, you need to get MrEnclave from somewhere. You have multiple alternatives to do so. You can extract MrEnclave from the CAS container image. You will also get this information when you purchase a production version of CAS.

In this assignment, we want to use a public CAS instance. This CAS runs in debug mode. We verify the attestation report with MrEnclave. You can connect with TLS to the public CAS web page and extract MrEnclave - using screen scraping - and store it in the environment variable $MRENCLAVE.

Task 2: Attest CAS with MrEnclave

Use scone cas attest to attest CAS with the extracted $MRENCLAVE. When attesting the public CAS, you need to know that this runs on some older SGX-enabled computer inside a debug enclave. Attestation will fail - unless you enable some options to accept that this is not secure:

  • -G: accept GROUP OUT OF DATE verification response (TCB out-of-date, dangerous!)

  • --only_for_testing-ignore-signer: This flag says that scone cas attest does not verify that the CAS software signature was signed by MRSIGNER.

  • --only_for_testing-debug: Allow CAS to run in debug mode, in which it CANNOT PROTECT SECRETS. This mode is for development and testing purposes only.

If you want to run and attest a production CAS running on up-to-date hardware, you might want to spin up a SCONE CAS instance on the Azure Marketplace.

Secure Communication with SCONE CAS

After attesting the CAS instance, you will be able to extract the CAS certificate from the SCONE CLI by executing:

scone cas show-certificate > cas_cert.crt

You can see the information in the certificate with the command:

openssl x509 -in cas_cert.crt -text

You can now use this certificate to connect securely with tools like curl to this SCONE CAS instance.

We create a policy example_session that defines a value example_value that is exported to everybody via the field export_public: true:

name: example_session
version: "0.3"
predecessor: 1ffb67d636570ccae5b2e8f8a6c8c6f912f69cc1fe138443e69e42dc783793eb
secrets:
  - name: example_value
    export_public: true
    kind: ascii
    value: "42"
access_policy:
  read:
    - CREATOR
  update:
    - CREATOR

You should now be able to retrieve the value of example_value via curl (or similar tool):

export CAS_ADDR=scone-cas.cf
export session_name="example_session"
export value_name="example_value"

curl --cacert  cas_cert.crt  --connect-to cas:8081:$CAS_ADDR:8081 https://cas:8081/v1/values/session=${session_name},secret=${value_name}

The output will be something like this:

{
  "kind": "string",
  "value": "42",
  "expires": null,
  "renew": null
}

Solution

A solution for this task for bash is available in assignment 1](https://github.com/scontain/Exercise/tree/main/Exercise1).

Screencast

Troubleshooting

  • curl returns an error message like:

    curl --cacert  cas_cert.crt  --connect-to cas:8081:$CAS_ADDR:8081 https://cas:8081/v1/values/session=${session_name},secret=${value_name}
{
"msg": [
    "Failed to read value 'example_value' of '/session=example_sessionx' requested by a public client",
    "Secret does not exist or is not visible for a public client"
]
}

The session name is wrong or the value name is wrong or we have updated SCONE CAS and forgot to add the session example_session.

  • curl returns a cryptic error message:
curl: (35) error:0DFFF006:asn1 encoding routines:CRYPTO_internal:EVP lib

Check if this is caused by a wrong certificate by enabling flag --verbose of curl. Switching on verbose logging might is often a good approach. In this context, it still produces only cryptic information. Anyhow, this error is caused by providing the wrong certificate via --cacert.

  • If you experience any additional issues, please let us know via email. We will add the issue and a proposed solution to this troubleshooting section.