It’s Butterfree!

What we would like is a decentralized remote attestation that allows us to add support to any enclave wishing to join our distributed network. We would like that no external verifiers be used - the network should use its own validators not 3rd parties to perform trust verification of a joining enclave TCB.

To accomplish this we must be able to securely extend the root of trust(the certificate chain) and then bind this identity(the expected hash) to a persisted state we can use to verify attestation credentials after they have been challenged, independently verified, with the associated proof stored on-chain.

We begin by making our own enclave the root of trust, so we self-sign a certificate(Instead of receiving one from Intel). The “rules” about what is acceptable as evidence are embedded in a special attestation contract. This contract has a “policy” with the definition of the rules which the network supports. At the beginning this will be maintained by our developers but in the future it can be done by the consensus validators.

With a self signed certificate we can now generate an identity key and embed it inside our TLS session so that it can’t be tampered with. We create an attestation payload which must contain assertions relating to our TLS Identity Key (TIK-C), which associates the private key with the attestation information.

The enclave binary and the other checks are performed by a random assignment of endorsers(peers who have already completed attestation), and with each passing result it will be provided the additional signature of that verifier. With a threshold of attestations an “attestation token” is generated to share with our relying party. This will be stored on our blockchain so that any relying party can quickly verify it.

This extends and secures the root of trust and binds our quote to the key of a particular enclave instance. By design, only this enclave has access to the key. The end result is an attested secure channel through which the attested validators can communicate. Freshness of the exchanged messages is guaranteed by TLS itself: nonces at the record layer protect against replays and attestation evidence can be determined through time stamps attached to it. They will additionally need an ECDH (secp256r1) key agreement and encryption - we can choose AEAD-AES-GCM-256.

We now have available the option of using a whitelist to store the identities of the nodes we want to trust to perform computations. But we cannot be assured there aren’t any discrepancies between the identities that have been added to each of our lists. We obviously do not want to use a trusted third party to keep for us the list of these “registered” identities.

It would be better to have a global state with a reference to these credentials be stored, updated, or revoked by consensus nodes and are subject to runtime verification. To do this we need a Decentralized Public Key Infrastructure(DPKI).