Support DCAP attestation

[kostko]

We should support DCAP attestation in a way where the consensus layer serves as a decentralized attestation registry.

Linked Issues

TBD

[Yawning]

Note: Someone that's not me should be the one that ultimately implements this.

The DCAP (ECDSA) based attestation process looks moderately straight forward. Although I have no idea how easy it is to get the API key credentials required, because https://software.intel.com/registration/?lang=en-us just gives me an error page.

Observations:

• Each host that participates needs to retrieve it's PCK certificate, and publish it on-chain. This requires an API key from Intel. Note that the PCK certificate is agnostic to the application being used, so if we are going to proxy this to save node operators the hassle of getting an Intel account, some other form of authentication needs to be designed. There is a chicken+egg problem here if we chose to include the PCK certificates in the node descriptor (since not authenticating is not an option).
• We need to obtain TCBInfo data for all the CPUs that people will be using, and publish that on-chain. This does not require an Intel account. We could have all the node operators publish this along with their PCK certificate, but this would end up bloating the on-chain state due to the expected amount of overlap.
• We need to figure out a different way of binding a X25519 public key to a quote, because the AVR based RAK mechanism 100% does not work, and there is no way that I can see to include additional enclave-specific data in the quote. (As far as I can tell the "supplemental data" refers to sgx_ql_qv_supplemental_t, which is rigidly defined).
• It is not clear to me how we would migrate existing state from the old IAS based attestation mechanism to ECDSA based.

The "nice" way to handle this mess is to do something complicated by publishing all the things required to verify signed quotes on-chain. The "awful" way to handle this mess is to write an IAS knockoff ("OAS") that is centralized, that does everything that IAS does on top of ECDSA-based attestation. The latter while ugly, centralized, and stupid, does simplify most of the open issues, in exchange for being shit and awful.

[kostko]

Each host that participates needs to retrieve it's PCK certificate, and publish it on-chain. This requires an API key from Intel. Note that the PCK certificate is agnostic to the application being used, so if we are going to proxy this to save node operators the hassle of getting an Intel account, some other form of authentication needs to be designed. There is a chicken+egg problem here if we chose to include the PCK certificates in the node descriptor (since not authenticating is not an option).

The proxy service should require that the participant posts the quote to obtain a PCK certificate (instead of just the PPID). Then it could verify that MRENCLAVE/MRSIGNER match a valid enclave, like the current IAS proxy does. It could additionally only allow requests signed by nodes that have corresponding entities registered (because before a node can register its identity key must be whitelisted by an entity).

We need to obtain TCBInfo data for all the CPUs that people will be using, and publish that on-chain. This does not require an Intel account. We could have all the node operators publish this along with their PCK certificate, but this would end up bloating the on-chain state due to the expected amount of overlap.

Depending on size, they could be published separately. The same goes for the QE identity (which also needs to be verified). But doing so will complicate the registration process somewhat.

We need to figure out a different way of binding a X25519 public key to a quote, because the AVR based RAK mechanism 100% does not work, and there is no way that I can see to include additional enclave-specific data in the quote. (As far as I can tell the "supplemental data" refers to sgx_ql_qv_supplemental_t, which is rigidly defined).

The v3 quote includes the original enclave-provided report data in isv_report.report_data (just tested a valid quote using our existing enclaves) so the existing scheme should work.

It is not clear to me how we would migrate existing state from the old IAS based attestation mechanism to ECDSA based.

We should probably support both schemes in parallel and then migration can happen gradually.

[Yawning]

The proxy service should require that the participant posts the quote to obtain a PCK certificate (instead of just the PPID). Then it could verify that MRENCLAVE/MRSIGNER match a valid enclave, like the current IAS proxy does. It could additionally only allow requests signed by nodes that have corresponding entities registered (because before a node can register its identity key must be whitelisted by an entity).

I am vaguely in favor of each node operator obtaining their own Intel API key instead of having a proxy service, but I do not know how annoying this is, because I can't even sign up for an account.

Depending on size, they could be published separately. The same goes for the QE identity (which also needs to be verified). But doing so will complicate the registration process somewhat.

All of this data can be deduplicated I think, so it's just large-ish transactions once in a while.

We need to figure out a different way of binding a X25519 public key to a quote, because the AVR based RAK mechanism 100% does not work, and there is no way that I can see to include additional enclave-specific data in the quote. (As far as I can tell the "supplemental data" refers to sgx_ql_qv_supplemental_t, which is rigidly defined).

The v3 quote includes the original enclave-provided report data in isv_report.report_data (just tested a valid quote using our existing enclaves) so the existing scheme should work.

Oh there it is. Yeah nevermind, The documentation for DCAP is kind of terrible so I missed it.

[Yawning]

https://www.intel.com/content/www/us/en/forms/basic-intel-registration.html

Maybe what is required to sign up for an account, to sign up to get an API key that allows querying PCK certificates, but Intel in their infinite wisdom wants a phone number to sign up.

At least the form takes 1-555-1212 as a phone number. And yes, once a basic intel account is created, it is possible to sign up for API keys, so there is no need to have a proxy.