Page History

...

1. Fetches certificates used by EVC. e.g. X.509 certificate chain used in signing AuthContainers.  If EVC is not reachable, goes with the cached copy of the certificates.
2. Tries to retrieve UUID provisioned in the EVC for this EVE instance. If EVC is not reachable, goes with the cached copy of the UUID last received from EVC.
3. Attempts to unseal the key in TPM. If unsuccessful, waits for encrypted Volume Storage Key from EVC, published post-attestation by EVC through configuration response.
4. Whenever HTTP Error 403 is received from EVC, starts a new attestation cycle with EVC:
   1. First EVE requests EVC for a nonce to include to include in the PCR quote, as a freshness proof.
   2. Interacts with TPM Mgr to prepare PCR quote with this nonce value as user-data.
   3. Then, it generates a random value to propose as the Integrity-Token. 
   4. Finally sends attestation request with the following fields:
      1.  The new Integrity-Token value
      2. PCR Quote
      3. TPM Event Log
      4. Image version (EVE and Firmware)
5. Whenever attestation response is successful, populates the Integrity-Token (included in the EVC's reply to attestation request), in a memory mapped file (not on the disk). Since Integrity-Token is volatile, when the device reboots, this automatically triggers re-attestation.
6. If attestation fails, attestation is re-attempted periodically. 
7. Configuration is requested in periodic intervals, with the Integrity-Token(or without that, which will trigger error 403). 
8. If config response contains attestation error (i.e. HTTP error 403), triggers attestation request immediately.
9. Even if attestation is successful, EVC can choose to invalidate Integrity-Token periodically (say every few hours), to re-trigger attestation.  Since Integrity-Token is invalidated, next config request from EVE will receive the same HTTP 403 error code in this case, which will re-trigger attestation.

...