...

Based on the above constructs, we present a solution to measure and attest software integrity of EVE node. Just for recap, EVE is the open-source software from LF-Edge for Edge Virtualization, running on IoT Edge gateways. EVC is the controller for managing these EVE instances.  Adam under LF-Edge is an open source implementation of one such EVC. The APIs between EVE and EVC are specified in EVE API specification.  In the context of remote attestation, the EVC is the attesting authority and EVE reports its measurements for attestation. 

Image Added

Fig 1. Role of EVC as the verifier, and EVE as the attester

...

Updated EVE Startup State Transition

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

...

Module Level Interaction - Startup Sequence (Reboot with no change) - No EVC connectivity required 

Fig 3. Module Level Interaction in EVE - Startup Sequence (Reboot with no change; works without EVC connectivity)

...

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

Fig 4.  Module Module Level Interaction in EVE - Startup Sequence (Reboot with differing PCR values)

...

Module Level Interaction - EVE Startup Sequence (Initial Onboarding)

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

...

1. EVE encrypts the key for the encrypted volume using a TPM-based key, and sends it to EVC. EVE can send this information when the key for the encrypted volume is created for the first time, and also can include this in the periodic info message. Sending this in periodic info message also provides additional facility of rotating the key if required.
2. After the upgrade, the EVE software presents the new Event Log, along with the PCR Quote. As mentioned earlier, the PCR Extend operations are recorded in a table called TPM Event Log Table.  This is sometimes also called the Boot Log.
3. First, EVC repeats the transactions mentioned in the Event log, and the final PCR as computed from the Event Log should match the PCR Quote. If they don’t match, then Event Log can’t be trusted(say it was manipulated), and the EVE node is marked as UUD.  Please note: Event Log is stored in system memory and PCR Quote is generated by TPM. So PCR quote is the source of truth, pinned to HRoT.
4. Secondly, if PCR Quote matches the Event Log, then Event Log entries are compared between old Event Log and the new Event Log, and the differing entries are extracted
5. EVC maintains a central database of all the supported EVE software images, and their hash values, indexed with the EVE image version tag
6. EVC also maintains a central database of all the 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 
7. The differing values are compared against acceptable values stored against the given image version. Additionally, If admin has enabled “Location-Lock” feature, additionally the geo-location reported by the device is checked as well. The Geo-location reported by the device can be trusted if the software state (established through PCR quote) can be trusted.
8. If the PCR quote and the optional Geo-Location check pass, the encrypted key for the encrypted volume is given back to the EVE node. EVE decrypts the key for the encrypted volume, and unlocks the vault with the key for the encrypted volume. The key for the encrypted volume is now sealed into the TPM, against the current PCR values.
9. User will have an option to override the attestation decision taken by EVC, through a configuration in EVC portal, against the EVE node

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

...

1. BIOS/Firmware updates can be done either manually (say a person inserts USB drive with new firmware and updates it out-of-band, and reboots the device with new firmware) or can be done remotely (updates driven through remote management framework, without a physical access to the EVE node). In both the cases, the new firmware version needs to be validated by EVC, before approving the new software state.
2. In case of remote updates, firmware Upgrades will be driven through EVC. This is to make sure EVC has the access to the firmware image, the measurement values to expect from EVE node for this firmware version etc.
3. To this effect, EVC would maintain a central database of all the 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. EVC will communicate the upgrade to a dedicated agent for this purpose on EVE.
5. The Firmware upgrade agent can either be a EVE service or can be a service app deployed on EVE
6. The agent will have a platform abstraction layer and a platform dependent layer. 
7. The platform abstraction layer drives the overall logic of downloading the firmware image, validating the image using manufacturer certificates, and reporting the status back to EVC
8. The platform dependent layer will be responsible for the actual firmware upgrade, by talking to any special component on the EVE hardware, like BMC
9. To address out-of-band update of firmware, there will be an option provided in the EVC portal, where the admin (after the upgrade is done), can configure EVC to accept the new firmware as trusted. 
10. If this is a general update across many devices, admin can also configure EVC database to feed in the new hash values to expect from the new firmware version. Please note, this is almost the same as remote update workflow w.r.t. validating the new version, except that the image update is done out-of-band

Fig 48.  Firmware Upgrade Management

...