...

1. A new device state,  “Unknown Update Detected” (Abbreviated as UUD) will be introduced in EVC, to indicate to in EVC that software running on a given device is not one of the intended/certified images
2. An optional feature, "Location-Lock" may be introduced in EVC, to additionally check the Geo-Location reported by device, and flag if the location has changed since its last-seen location. This feature may be critical in some deployments, where a given EVE node may be mounted permanently, and any change in its physical location should be flagged, and optionally considered along with software measurements to conclude if the EVE node is trusted. In this regard, another new device flag, “Unknown Movement Detected” (Abbreviated as UMD) will be introduced in EVC, to indicate that a change in the location of the device has been detected.  
3. EVC maintains a central database of all the supported EVE software images, and their hash values, indexed with the EVE image version tag
4. EVC also maintains a central database of mostly used BIOS firmware images, their signatures, and the certificate provided by the BIOS vendor for validating the signatures, indexed by a combined tag of BIOS version string + Manufacturer 
5. On every reboot, EVE sends PCR quote to EVC, along with optional Geo-Location information, along with its EVE image version and BIOS firmware version.
6. After normal reboot operation of EVE, EVC checks PCR Quote against the baseline value. If there is a change, the edge-node is marked as “UUD”.  If "Location-Lock" feature is enabled and the location of the EVE node has changed, EVE node is marked "UMD"
7. After EVE software upgrade, it is expected that the baseline value will change for the PCR values. However, after comparing the reported values with the expected values(since EVC knows about the new image version and its hash values), EVC makes a decision: If the reported values match, the baseline for the EVE node is updated. If they don’t, it is a UUD detection.  Optionally, if administrator enables “Location-Lock” feature,  Geo-Location of the device will also be included in the checks, before sending the latest configuration.
8. If edge-node is in “UUD” or "UMD" state, only the “last-seen” EVE configuration, along with the only the latest baseOS configuration is sent as config request response, all other new configuration items will be omitted in config response. This is to protect any new sensitive  images/credentials from getting exposed to the compromised device. Here "last-seen" refers to the configuration last received by EVE from EVC.The response from EVC in such cases will carry an error code to indicate that there was an attestation failure, and hence partial configuration is being sent.  EVE, upon receiving such error codes, will apply the latest baseOS configuration, and also schedule re-attestation immediately (instead of waiting for the next attestation timer to expire)
9. If EVE node is not in “UUD" or "UMD" state, all the latest configuration If EVE node is not in “UUD" or "UMD" state, all the latest configuration items are included. 
10. Frequency of attestation: EVE node will be required to periodically attest itself via attestation requests. The interval is fixed to be every 4 hours, or whenever the device connects back to the cloud again, or after the next reboot, whichever is earlier. This 4 hours is a tentative interval, and can be changed based on deployment requirements.
11. If EVE reboots with a different software image from the configured version, EVC should be able to detect as quickly as possible and force attestation. To this effect a new token is introduced, called "Integrity Token". This token is a random nonce that will be stored in EVE under an encrypted folder. The master-key to decrypt this folder will be sealed against the TPM PCRs.  Therefore, if EVE reboots with a different software, unsealing of this key will fail, and hence the new software will not be able to recover the Integrity Token inside it.
12. This token is sent during attestation requests, and if the attestation is successful, the provided token value is locked against the EVE node. 
13. Every configuration request from EVE will include this Integrity Token. If there is a token mismatch, HTTP code 403 - Forbidden will be sent to the device as the response, indicating that device should do re-attestation. 

...

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. 
5. In case of mobile gateways, there will be an option to turn-off Geo-Fencing(i.e. Locking of Geo locationFencing(i.e. Locking of Geo location)

Updated EVE Startup State Transition

Image Added

Fig 4. State Diagram for EVE Startup, with Attestation enabled

During Startup, EVE performs the following logical steps:

1. Fetches certificates used by EVC. e.g. X.509 certificate chain used in signing AuthContainers
2. Tries to retrieve UUID provisioned in the EVC for this EVE instance
3. Attempts to unseal the key in TPM. If unsuccessful, retries in regular intervals
4. Sends Attest request periodic intervals, containing new Integrity-Token value, PCR Quote, Event Log and Image version
5. Whenever attestation response is successful, opens the vault and reseals the key with new PCR values, and populates the Integrity-Token
6. Configuration is requested in periodic intervals, with the Integrity-Token(or without that).
7. If config response contains attestation error, triggers attestation request immediately.

The next section presents the same steps, but at more functional level, with interaction among various EVE microservices.

Module Level Interaction - Startup Sequence (Post onboarding)

Image Added

Fig. Module Level Interaction in EVE - Startup Sequence

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)

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 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 (Running an Unknown Software)

Securely Upgrading EVE Software

...

Fig 3.  Overview of flow of events during Secure Software Update

Updated EVE Startup State Transition

Image Removed

Fig 4. State Diagram for EVE Startup, with Attestation enabled

Module Level Interaction - Startup Sequence

Image Removed

Fig. Module Level Interaction in EVE - Startup Sequence

Managing Firmware Upgrades

...

Fig 4.  Firmware Upgrade Management

Handling non-TPM devices

User Interface Options