...

1. To establish a baseline, the following is proposed:
   EVE device is on-boarded in a trusted environment, usually in a manufacturing/supply chain setup (or Intel SDO)
2. When EVE  is on-boarded for the first time, during device-certificate registration, the PCR values coming out of the EVE node will be taken as the baseline for that device. Any change in the PCR value (other than during an EVC-driven upgrade, explained below)  after will be flagged as UUD, and unless the user marks it as legal/accepted, the EVE node will remain in the UUD state.
3.  If the enterprise account is a manufacturing account, then geo-location will be exempted in calculating the baseline.
4. When the EVE node comes online for the first time in a non-manufacturing enterprise, geo-location of the EVE node will be taken and will be frozen as the baseline value for geo-location . In case of mobile gateways, there will be an option to turn-off Geo-Fencing(i.e. Locking of Geo location(only if Location-Lock feature is enabled)

Updated EVE Startup State Transition

...

Fig. Module Level Interaction in EVE - Startup Sequence (Post Onboarding)

1. Device-steps starts client.go (the provisioning client) which will check and do the following:
   1. If certificates from EVC are not yet fetched,  fetches them 
   2. Retrieves UUID from EVC
2. Device-steps starts Vault Mgr
   1. Vault Mgr retrieves the master decryption key from TPM with Unseal operation
   2. Unlocks /persist/vault with the master-key
   3. Publishes vault status (unlocked)
   4. Waits for Integrity-Token and/or master-key from EVC. 
   5. Once received, rotates the master-key if requested, and also copies the new Integrity-Token to /persist/vault/itoken file
3. Device-steps starts TPM mgr
   1. TPM manger retrieves the attestation certificate and publishes to Zedagent
   2. Waits for Quote requests on pubsub channel from Zedagent
4. Device-steps starts Zedagent (and Zedagent starts 3 concurrent tasks: attest, info and config)
   1. Attest task picks up the attestation certificate and publishes to EVC
   2. Attest task requests for a nonce from EVC (to prepare PCR quote)
   3. Attest task sends the nonce back to TPM Mgr and waits for PCR quote
   4. Attest task, once notified about the quote readiness, creates a random nonce value for Integrity-Token
   5. Attest task sends { Quote, Location, Event Log, Integrity-Token, Image Version } to EVC
   6. EVC, if quote is the same as previous quote, approves the attestation request
      1. If Location-Lock is enabled, location is checked in addition to Quote
   7. Along with attestation approval, the encrypted master-key is sent back to EVE
   8. In the mean time, configuration task keeps requesting config from EVC (expected to fail till attestation goes through)
   9. Attest task, once attestation request is approved, gets the master-key and Integrity-Token and passes it to Vault Mgr
   10. Config task now picks up the right Integrity-Token and Config request is now accepted by EVC, and full configuration is sent back
   11. Info task reports the encrypted master-key back to EVC, for backup purposes

Module Level Interaction - EVE Startup Sequence (Initial Onboarding)

Image Added

Fig. Module Level Interaction in EVE - Startup Sequence (Onboarding)

1. Device-steps starts client.go (the provisioning client) which will check and do the following:
   1. First fetches EVC Certificates
   2. Registers the device certificate
   3. Retrieves UUID from EVC
2. Device-steps starts Vault Mgr
   1. Vault Mgr creates new vault: /persist/vault
   2. Seals the master-key into TPM with PCR values
   3. Publishes vault status (unlocked)
   4. Waits for Integrity-Token from zedAgent
   5. Once received, rotates the master-key if requested, and also copies the new Integrity-Token to /persist/vault/itoken file
3. Device-steps starts TPM mgr
   1. TPM manger retrieves the attestation certificate and publishes to Zedagent
   2. Waits for Quote requests on pubsub channel from Zedagent
4. Device-steps starts Zedagent (and Zedagent starts 3 concurrent tasks: attest, info and config)
   1. Attest task picks up the attestation certificate and publishes to EVC
   2. Attest task requests for a nonce from EVC (to prepare PCR quote)
   3. Attest task sends the nonce back to TPM Mgr and waits for PCR quote
   4. Attest task, once notified about the quote readiness, creates a random nonce value for Integrity-Token
   5. Attest task sends { Quote, Location, Event Log, Integrity-Token, Image Version } to EVC
   6. EVC, if quote is the same as previous quotemaster-key is not found for the EVE, approves the attestation requestPCR quote as the baseline
      1. If Location-Lock is enabled, location is checked in addition to Quote
      Along with attestation approval, the encrypted master-key is sent back to EVE
      1. also approved as baseline (provided the EVE device is not in manufacturing account)
   7. In the mean time, configuration task keeps requesting config from EVC (expected to fail till attestation goes through)
   8. Attest task, once attestation request is approved, gets the master-key and Integrity-Token and passes it to Vault Mgr
   9. Config task now picks up the right Integrity-Token and Config request is now accepted by EVC, and full configuration is sent back
   10. Info task reports the encrypted master-key back to EVC, for backup purposes

Module Level Interaction - EVE Startup Sequence (Running an Unknown Software)

Image AddedFig. Module Level Interaction in EVE - Startup Sequence (Running Unknown Software)Device-steps starts client.go (the provisioning client) which will check and do the following:

1. Device-steps starts client.go (the provisioning client) which will check and do the following:
   1. If certificates from EVC are not yet fetched,  fetches them 
   2. Retrieves UUID from EVC
2. Device-steps starts Vault Mgr
   1. Vault Mgr tries to retrieve the master decryption key from TPM with Unseal operation, and Unseal operation fails since the PCR values have changed
   2. Publishes vault status (as "locked")
   3. Waits for Integrity-Token and/or master-key from EVC - it will block here forever
3. Device-steps starts TPM mgr
   1. TPM manger retrieves the attestation certificate and publishes to Zedagent
   2. Waits for Quote requests on pubsub channel from Zedagent
4. Device-steps starts Zedagent (and Zedagent starts 3 concurrent tasks: attest, info and config)
   1. Attest task picks up the attestation certificate and publishes to EVC
   2. Attest task requests for a nonce from EVC (to prepare PCR quote)
   3. Attest task sends the nonce back to TPM Mgr and waits for PCR quote
   4. Attest task, once notified about the quote readiness, creates a random nonce value for Integrity-Token
   5. Attest task sends { Quote, Location, Event Log, Integrity-Token, Image Version } to EVC
   6. EVC, since the quote is different, tries to compare EventLog entries with its known hashes against the version reported. Since this is some arbitrary software, there will not be a match.
      1. Even if Location-Lock is enabled, location can not be trusted here, since the software reporting the location is not trusted.
   7. EVC sends an error back to EVE, to retry attestation.
   8. In the mean time, configuration task keeps requesting config from EVC (expected to fail till attestation goes through).
   9. EVC replies to configuration request, sends partial configuration (only BaseOS upgrade config is sent), and indicates attestation failure (due to no or invalid Integrity Token)
   10. Config task communicates to Attest Task to re-trigger attestation

Securely Upgrading EVE Software

When EVE goes through a software upgrade, the PCR values might change depending on what is new in the upgraded version. However, during the upgrade window, an attacker might boot a different software as well, and try to present the compromised software as the upgraded version of EVE. Therefore, it is important that we measure the boot sequence after the upgrade and validate that the new software is indeed the new image that was pushed by the EVC. This is done through the following steps:

...