• 04/09/2016
  • Public Content

The following figure shows an example of how an application, which has broken its processing into two component parts, provides attestation to a challenging service provider to receive some value added service from them.
Remote Attestation Example
The figure Remote Attestation Example shows the basic steps involved in canonical enclave attestation. Included in this diagram is the Quoting Enclave (QE). The steps in the figure are described below:
  1. When the application needs a service from outside the platform, it first establishes communication with the service providing system. The service provider issues a challenge to the application to demonstrate that it is indeed running the necessary components of itself inside one or more enclaves. The challenge itself contains a nonce for liveness purposes.
  2. The application requests a report from the application’s enclave and passes in the nonce from the challenger.
  3. The enclave generates a report structure and returns this structure along with a manifest to the application.
    1. The manifest contains those values which are included in the user data portion of the report.
    2. The manifest may include the nonce and an ephemerally generated public key to be used by the challenger for communicating secrets back to the enclave.
  4. The report is delivered to the Quoting Enclave for signing.
    1. The Quoting Enclave authenticates the report.
    2. The Quoting Enclave converts the body of the report into a quote and signs it with the Intel EPID key.
  5. The Quoting Enclave returns the quote structure requested.
  6. The application returns the quote structure and any associated manifest of supporting data to the service challenger.
  7. The challenger uses the EPID public key certificate to validate the signature over the quote or may optionally choose to use an EPID verification service to perform this function.
  8. The challenger compares the enclave information in the quote against the trusted configuration and only renders the service to the application if the enclave information matches the trusted configuration. The challenger might enforce different trust policies, for example, only trusting a specific version of an enclave, identified by the measurement of the code and data in the enclave, or trusting all enclaves with a specific Product ID from a specific enclave author, identified by the hash of the public key in the ISV certificate. A trust policy must include enclave authorship and attributes check. For example, a debug enclave should never be trusted with any secret.
These steps serve as an example to illustrate one possible way that an enclave can be attested by a remote entity.
The trusted configuration mentioned in step 8 above is typically provided by the enclave author to the service provider. The mechanism for the service provider to acquire the trusted configuration is out of the scope of the remote attestation. One possible mechanism is that the service provider utilizes existing PKI infrastructure to verify the identity of the entity that’s providing the trusted configuration information before accepting the trusted configuration information.

Product and Performance Information

1

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.