Use DCAP as the default RA type

[hu55a1n1]

Acceptance Criteria

• Impl DCAP attestor
• Impl DCAP verifier
• Make DCAP RA default (includes changes to enclaves, gramine manifests, cw packages, etc.)
• Test that it all works end-to-end

Depends on #100

Tasks

Beta Give feedback

1. Remove proxy, listen goes inside enclave, and also change EPID from listen, to DPAC in enclave (see Proposal: remove the proxy altogether for transfers and MTCS #100 too)
2. Quartz cosmwasm - check for quote and collateral (query & verify TCB info, quartz init gets TCB contract address) #175
   cosmwasm +1
   
3. TCB info contract update=early on fmspc (optional) #218
   +0
4. PCCS Dockerize (optional) #219
   +0
   

[hu55a1n1]

So it seems the best way to implement this is to get parts of the collateral from the PCCS while hardcoding the others ->

pub struct Collateral {
    root_ca_crl: CertificateList,               // <---- hardcode or query from the tcb-info contract

    pck_crl_issuer_chain: Vec<Certificate>,     // <---- query from PCCS
    pck_crl: CertificateList,                   // <---- query from PCCS

    tcb_issuer_chain: Vec<Certificate>,         // <---- hardcode
    tcb_info: String,                           // <---- query from tcb-info contract

    qe_identity_issuer_chain: Vec<Certificate>, // <---- hardcode
    qe_identity: String,                        // <---- hardcode
}

To be able to query some of this data, we need to know the fmspc beforehand. So the way to do that is to query the pck cert and parse it from the first cert in the chain based on this C++ code. (see PCCS API spec for more details)
Alternatively, we could use the pckidretrieval tool but we must make sure if/how that works on Azure.

(many thanks to @amiller for inputs/suggestions)

[hu55a1n1]

get parts of the collateral from the PCCS while hardcoding the others

Now the question is who gets this data together and when. Ideally this is something that the host does because the code is non-deterministic (involving HTTP calls, etc. that might have to be retried). In the absence of a host role, we could add this logic to the enclave, but we must make sure that the code is able to handle failures while not being vulnerable to replay attacks.

[hu55a1n1]

Per recent discussions with @amiller and the team, it seems the PCCS service is expected to run on the host and we (Informal) will have total control over it. So for all practical purposes we could treat HTTP calls made by the enclave to this cacheing service as infallible. Later protocol deisgn work to make the system highly-available and fail-safe can handle failures. Also, the PCCS can be dockerized and the fetch for intermediate certificates can be done proactively or on demand.

So the next steps would be ->

• Update enclave code to give back a full DCAP quote with (parts of the) collateral sourced from the PCCS running on host. (basically means continuing with Proposal: remove the proxy altogether for transfers and MTCS #100)
• Optionally, as part of this, check if the TcbInfo on the contract exists and is up-to-date for this fmspc, if not try to update it. (could be future improvement)
• Dockerize PCCS for easy deployment/setup. (Docker compose setup with separate images preferred)
• Modify contract to get the remaining collateral from the TcbInfo contract (e.g. TcbInfo, Root cert? etc.).

Some other points to consider ->

• Maybe the challenge doesn't need to be stored on chain?
• Known problems with running AESM service in docker.
• PCS != PCCS. 😅

[hu55a1n1]

So I found the following options for getting the fmspc ->

Option 1: Using the PCKIDRetrievalTool

This is one of the tools that Intel provides, but I am not sure if it's safe to call from inside the enclave.

Option 2: Make a HTTP POST to the PCS

See https://api.portal.trustedservices.intel.com/content/documentation.html#pcs-certificate-v4-response

Basically we call GET https://api.trustedservices.intel.com/sgx/certification/v4/pckcert and the response headers have a SGX-FMSPC.

The problem with this is I'm not sure where to find the encrypted_ppid and pceid ->

{
    "encrypted_ppid":"...",
    "cpusvn":"...",
    "pcesvn":"...",
    "pceid":"..."
}

Option 3: Link to Intel's C++ lib dynamically and call them

Basically ->

I need modify QVE to expose tee_get_fmspc_ca_from_quote
I need link QPL and QVE with my Gramine app
I can use tee_get_fmspc_ca_from_quoteand tee_get_verification_endorsement to get collateral

See gramineproject/gramine#820

(Also not sure if this is safe)

Other options

• Use an unsafe workaround for now and wait for Intel to add APIs for this (which they apparently will add soon as per Is it possible to get DCAP quote collateral? gramineproject/gramine#820 (reply in thread)).
• Explore how Phala is doing this.
• ?

[hu55a1n1]

So, based on @amiller's inputs, this seems like the best way forward ->

1. Get the host to run PCKIDRetrievalTool and pass that to the enclave on startup.
2. Parse that output to find the encrypted_ppid and pceid.
3. Use those fields along with the cpusvn & pceid from the quote to call GET https://api.trustedservices.intel.com/sgx/certification/v4/pckcert.
4. Parse the header to get SGX-FMSPC and see if that works. If not look at the first cert in the response and parse fmspc from it. (details in SGX_DCAP_Caching_Service_Design_Guide (3.1. Get PCK Certificate))
5. Put fmspc into the Collateral::tcb_info string (simply repurpose the field to temporarily store the fmspc) and send it to the contract as part of the attestation
6. During on-chain verification, query the TcbInfo contract using the specified fmspc and replace it in the collateral.
7. Call the DCAP attestation verifier! 🚀

[hu55a1n1]

Latest findings

• The PCKIDRetrievalTool output does indeed contain everything we need to get the FMSPC. (See https://github.com/intel/SGXDataCenterAttestationPrimitives/blob/main/tools/PCKRetrievalTool/README.txt#L62)
• The relevant fields are encrypted_ppid, cpusvn, pcesvn, pceid, qeid. (to get the FMSPC, we do a GET https://api.trustedservices.intel.com/sgx/certification/v4/pckcert and look at the response header for SGX-FMSPC)
• I tried installing PCKIDRetrievalTool on Zed but ran into the following error which (IIUC) means the SGX driver isn't installed ->

$ ./PCKIDRetrievalTool

Intel(R) Software Guard Extensions PCK Cert ID Retrieval Tool Version 1.21.100.3

Warning: If this is a multi-package platform, please install registration agent package.
         otherwise, the platform manifest information will NOT be retrieved.
Error, call sgx_create_enclave: fail [load_enclave], SGXError:200f.

• The process for installing the PCKIDRetrievalTool seems simple enough but I was trying without sudo/root access so that's probably what complicated it for me. But we should definitely try to install and run it on our Azure machine. Installation is basically just a make && make install, but depends on libcurl-dev and SGX SDK (prebuilt bins exist - see https://download.01.org/intel-sgx/latest/linux-latest/distro/ubuntu20.04-server/)

What/how to impl

• To get the collateral, we need the FMSPC, and for that we need to call the PCKRetrievalTool.
• So this involves multiple (~3) steps as detailed in my previous comment. We could decide to offload some of these steps to the host and could provide CLI utils (quartz enclave start extension) to help the host with this process.
• But it seems the PCKRetrievalTool may have to be run as root, so I propose delegating this step to the host.
• Querying the API for the pckcert seems like a simple improvement that can be added to the CLI later.
• So I propose we start by asking the user to explicitly specify the FMSPC on the quartz enclave start CLI command. We pass this to the enclave via the gramine-manifest which is accessible to the enclave as a CLI arg. The CLI arg then uses the fmspc to construct the partial Collateral as described in a comment above. All this is (almost) implemented in feat(dcap): make DCAP RA default  #150.