...

Assuming that EVE provides a capability to store some files in an encrypted filesystem., we can foresee the following use cases: 

 a) A user might want to run the Edge Containers out of this secure file system, so that data that is stored by these Edge Containers is stored in encrypted form at rest.   A user might do this is to prevent an attacker from reading the application data if the EVE node is stolen or drive is taken out.

...

 c) A user might also want to be able to create secure file stores and be able to associate an arbitrary Edge Contrainer Container with such a secure file store. 

...

 e) A user might want to control security policies for such file stores using user-defined policies, e.g. whether key is protected by IP fencing, TPM attestation etc.  He might also decide whether key for the vault is to be provided from Controller or it can be from the TPM on the EVE platform.

Proposed Interface between EVE and EVC

We are proposing to have a user visible construct called “Vault”.  A Vault is a secure file system, protected by native file system encryption.  Therefore the interface has 2 3 parts to it:

a) Lifecycle management of a “Vault” - How user can create, change, delete a given Vault and its associated policies. 

       - This wil be at root level configuration for EdgeDevConfig, consists of a list of vault parameter detail.

b) Association of Edge Containers with a Vault - To control data at rest requirements of a Edge Container

       - The app instance detail will include a reference to a defined vault. 

c) Attestation of the device through pcr quote and nonce and/or geo-location/ip information. 

       - This will be used for remote attestation on reboot of a device and periodic challenges.

Same API that carries other config, handled by zedAgent

...