Enable DCAP quote generation

[bvavala]

This PR enables DCAP quote generation in PDO, alongside EPID quotes.

The PR adds the following features:

• a new PDO_ATTESTATION_TYPE variable to specify the type of attestation. Currently, it supports the following values: simulated in SIM mode; epid-linkable or dcap in HW mode.
• updated docker build to support DCAP quote generation in HW mode
  • updated support for dcap devices and a new file to specify the sgx attestation type (even in SIM mode)
  • a PCCS is required and the build assumes that an instance is up and running. The URL can be configured through the PCCS_URL variable.
• documentation for the dcap attestation and new variables
• support for DCAP quote generation, alongside EPID quote generation, inside the eservice. The attestation type is used to select the quoting enclave target and the right data structures to use. As before, a generic quote buffer is returned to the caller. For EPID, this is sent to IAS to retrieve the verification report. For DCAP, the proof data is currently dropped because: 1) support for DCAP quote verification must be implemented; 2) this allows to test the rest of PDO (CCF TP and pservice), albeit (with the rest compiled) for SIM mode.

Testing.

• This PR depends on fix build to make CCF PDO work with the eservice (only) in SGX HW mode #379 -- which enables HW mode only for the eservice, for testing purposes.
• This PR was tested through:
  • the usual github CI, in SIM mode;
  • locally in HW mode with EPID;
  • locally in HW mode with DCAP, using a local PCCS on the same platform -- if behind a proxy, the no-proxy variables must be set properly, so that the docker compose/container can access the service on the host.
    • Troubleshooting proxy/PCCS issues in CI. Errors in proxy/pccs configuration typically result in Error returned from the p_sgx_get_quote_config API. 0xe019.
    • Make sure that the no-/proxy variables are set up correctly on the host (since these are later ported to the containers in the CI) and in the containers.
    • Also, make sure that the /etc/sgx_default_qcnl.conf on the host, or in the container, is set up correctly with a reachable PCCS.

[marcelamelara]

Two questions:

• Has this PR been tested when SPID/SPID_API_KEY aren't provided in DCAP mode, or does the eservice still expect dummy values for these?
• This may be a bit tangential: This PR presumably uses the latest SGX SDK 2.17 (Docker certainly always installs the latest). It may be good to update the documentation accordingly. Does this PR also require the latest SGX SSL?

EDIT: One more thing: the CI fails for wawaka, though at first glance the issue seems to be with CCF... not sure if these changes led to this problem, since the other CI instances did not fail.

[marcelamelara]

Wouldn't we want to register DCAP quoting enclave keys?

[bvavala]

Yes, we want that.
This is the same discussion we had in #379 and #380 .
Unfortunately, this is not implemented in our CCF TP yet.

[marcelamelara]

Suggested change

	pdo = enclave.pdo_enclave_info(signed_enclave, spid, attestations_type, num_of_enclaves)
	pdo = enclave.pdo_enclave_info(signed_enclave, spid, attestation_type, num_of_enclaves)

[bvavala]

Good catch!
This error was not detected during tests because this piece of code is not tested in this PR, but it is tested in #380 .
Hence, I'm going to covert this to a draft until the other is merged (and this is rebased).

(Long explanation, for the records)

The registration of the enclave info and IAS keys on the ledger is performed through the register-with-ledger.sh script. This is only triggered in Sawtooth builds in HW mode, since CCF builds do not support HW mode currently.
This is visible in the docker/Makefile, specifically in the make [..] register occurrences.

The removal of Sawtooth implies the removal of the tests of the registration procedure -- which uses the python code for grabbing an enclave attestation to get the mrenclave and basename. This would result in a lower test coverage.

For this reason, #380 adds a make [..] register occurrence in the test-env-setup-with-no-build-ccf section.
This makes sure that the script is still triggered in HW mode.
This is important in conjunction with #379 , which allows to execute (only) the eservice in HW mode.
The script does not trigger errors since the interaction with the ledger is removed (again, the CCF TP does not support this feature), but provides warnings to remind to fix this once CCF TP support is completed.

In #382 , the script is further refined to trigger the registration only in HW mode when EPID is selected.

[bvavala]

As expected, with #380 merged, this issue showed up in the tests, and even a few more.
These have been addressed in bff1abc .

[bvavala]

Two questions:

• Has this PR been tested when SPID/SPID_API_KEY aren't provided in DCAP mode, or does the eservice still expect dummy values for these?

The latter.

• This may be a bit tangential: This PR presumably uses the latest SGX SDK 2.17 (Docker certainly always installs the latest). It may be good to update the documentation accordingly. Does this PR also require the latest SGX SSL?

Nothing has changed regarding that. Info about the sdk the ssl are here:

private-data-objects/docker/Dockerfile.pdo-dev

Line 66 in 5db8889

ARG SGX=2.15.1

EDIT: One more thing: the CI fails for wawaka, though at first glance the issue seems to be with CCF... not sure if these changes led to this problem, since the other CI instances did not fail.

I think I can safely say that that's an old issue (present also in main) which we still have not figure out.
It's a transient segfault happening in the system-tests/kv-tests.
Unfortunately it never happened in local tests.

[bvavala]

Closing it for now -- stale.