...

Secure Boot is a security standard where each software layer in the booting sequence measures the next layer, and starts the next layer only if the signature of the software is verified by a certificate rooted to one of the known certificates embedded in the firmware by OEM. Software updates are done through uploading signatures and certificates of the new binary.  Since each layer starts the next software layer only if the signature verification is successful, boot process is stopped when one of the stages fail the signature verification.  For secure boot to work, all the software layers should be capable of measuring and verifying the next software layer. 

Measured Boot, is another security standard, where the measurements are recorded into TPM PCRs but the boot process can be allowed to complete. The measurements can be later read back from TPM and the Audit log of all the measurements can also be fetched.  Thus measured boot does not make any judgement about the integrity of the boot stages, but gives opportunity for an external server to inspect the TPM Audit Log and PCR values in a detailed manner to see which components were measured, what their measurements are etc., and make a decision.

...

Please note: There are some measured boot solutions which behave more like secure boot, there are some secure boot solutions which behave more like measured boot, but the reader is advised to stick to the above definitions, for the purpose of discussions in this document.

...

1. A new device state,  “Unknown Update Detected” (Abbreviated as UUD) will be introduced in EVC, to notify that measurements of software running on a given device didn't match expected measurements.
2. EVC maintains a central database of all the supported EVE software images, and their hash values, indexed with the EVE image version tag
3. 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
4. On receiving attestation request EVE,  attestation service module checks PCR Quote against the baseline value. If there is a change, the EVE node is marked as “UUD”.  When there is no software change, the PCR quote is expected to be the same across reboots. However, after an 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, EVE node is marked as UUD. 
5. 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.  
6. If EVE node is not in “UUD" or "UMD" state, EVC includes all the latest configuration in reply to config request from EVE.
7. If edge-node is in “UUD” or "UMD" state, any config request from EVE will be responded with response code 403 - Forbidden. This is to protect any new sensitive  images/credentials from getting exposed to the compromised device. 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 MUST schedule re-attestation immediately.
8. 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. This token is sent during attestation requests, and if the attestation is successful, the provided token value is sealed against PCR values. This is usually implemented by storing the token inside an encrypted folder, with the master-key protected by TPM with Seal operation.
9. 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. 
10. Frequency of attestation: EVE node will be required to periodically attest itself via attestation requests. It is up to the EVC to schedule the frequency of attestation. Whenever EVC replies with Error 403, EVE MUST re-attest.  EVC can trigger this either periodically (say every few hours) or when it sees any discrepancy in the Integrity-Token.

Protecting

...

ECO Instances by Sealing ECO Volumes

All the app images and container volumes ECO Volumes would be inside the encrypted folder (/persist/vault), with the master key sealed inside TPM, against a set of PCR values. Without access to this master-key, the encrypted folders can not be accessed. Essentially this means that the contents of the user-provisioned volumes are sealed against PCR values.

If EVE or BIOS image was changed during boot, then unsealing of this storage will fail, since the PCRs have changed. Since ECO Volumes are inside the sealed storage, ECO volumes are locked till re-attestation happens with the EVC.

To implement this, ECO which will implicitly disable all the apps from getting launched, since all the app images and container volumes would be inside the encrypted folder (/persist/vault), with the master key sealed inside TPM. 

To provide some flexibility to the EVE node administrator, when deploying app instances ECOs on the EVE platform, there will be 3  security modes for app deployment:

1. No-Lock Mode - app images will ECO Volumes will not be in encrypted folder (not recommended, unless there is a compelling need to run any app instance ECO unconditionally e.g. service apps like SD-WAN, DHCP Server)
2. Software Lock Mode - app images ECO Volumes will be in encrypted folder - with key from TPM, sealed with PCRs (the default option)
3. Software Lock + Location Lock Mode  - app images ECO Volumes will be encrypted folder - with key from TPM, sealed with PCRS + a key provided after Geo-Location check from the EVC.  This will work only when device is connected to EVC

...

With the approach to seal the key(s) needed for fscrypt under the TPM, this means that if the PCR values have not changed (e.g., a normal reboot, or a reboot due to a power outage) the EVE node will be able to unseal those keys and start the app instances ECOs without any controller connectivity.

...

1. Device-steps starts client.go (the provisioning client) which will check and do the following:
   1. If EVC is not reachable, uses certificates from the last download
   2. If EVC is not reachable, uses UUID already present in /config/uuid
2. Device-steps starts Vault Mgr
   1. Vault Mgr retrieves the master decryption key from TPM with Unseal operation. Unseal is successful since the PCR values are the same since last reboot.
   2. Unlocks /persist/vault with the master-key.
   3. Publishes vault status (unlocked)
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 Zed Manager, Domain Mgr microservices - these services are responsible for launching the Edge App InstancesECOs
5. Device-steps starts Zedagent (and Zedagent starts 3 concurrent tasks: attest, info and config)
   1. Configuration task, since EVC is not reachable, uses the configuration from the last download, and publishes to Zed Mgr and Domain Mgr
   2. Since the Vault is unlocked, Domain Mgr can access Edge App Images, and hence launches the app instancesECOs.

Module Level Interaction - EVE Startup Sequence (Reboot with a change)

...