...
- In some deployments, EVE devices operate in geographically remote locations e.g. top of wind turbines or in the mid-ocean oil extraction zones, where manual access to the device is limited. In such deployments, the only way to get operational information about EVE is by EVE itself shipping the operational state to the controller. Thus providing visibility of the operational status of the device to the controller at any time is a keyimportant. Even if there is an attack and the software running on EVE has been modified, it is very critical that EVE itself detects it and reports it to the controller.
- In some deployments, Internet connectivity and power supply are not reliable. There can be intermittent loss of connectivity between EVE and Controller, and EVE is expected to continue operating with the last-known configuration till it is able to reach the Controller again. There can be power outage as well, which means, once power is back, EVE is expected to boot up and get back to its last operational state and resume its Edge Container Instances (even if the connectivity is still down)
- Some of the EVE devices are also deployed in cases where the device is prone to security attacks, e.g. smart poles, Industrial factory floor etc. Therefore these EVE devices can be easily attacked by inserting USB drives, or the device itself can be physically hijacked to a different location for possible extraction of user data.
- EVE software upgrades are done remotely from the Controller. Ensuring integrity of the upgrade in a zero-trust environment is a challenge (i.e. How do we know if EVE device is running the correct version indeed ?)
...
- Implement recommendations of TCG Remote Attestation Protocol TAP - with EVE as the attester and EVC as the verifier. i.e. use TPM to measure the booting sequence using Platform Configuration Registers (PCR)
- On top of the TCG solution, propose a mechanism for self-locking: Seal the decryption key for using the encrypted volumes using PCRs (for self-locking during offline/tampered conditions). This is done to address unique operational requirements of EVE at the Edge.
- Escrow of the volume key with the Controller during the upgrade.
...
This means that the controller will need to store the fscrypt key(s) so it can hand it back to the EVE node. But we should be able to encrypt them under the EVE node a separate private key so from TPM so that even if the controller is compromised the fscrypt keys can not be extracted from it.
...
- 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.
- 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.
- Attempts to unseal the key in TPM. If unsuccessful, retries in regular intervals, waits for encrypted Volume Storage Key from EVC, published post-attestation by EVC through configuration response.
- Whenever HTTP Error 403 is received from EVC, starts a new attestation cycle with EVC, by sending a request with Sends Attest request periodic intervals, containing new Integrity-Token value, PCR Quote, Event Log and Image version
- Whenever attestation response is successful, opens the vault and reseals the key with new PCR values, and populates the Integrity-Token in a memory mapped file (not on the disk)
- Configuration is requested in periodic intervals, with the Integrity-Token(or without that).
- If config response contains attestation error, triggers attestation request immediately.
...