Motivation
Currently, EVE does not have capability to provide data security at rest. This is being designed and implemented [1]. With this, EVE will provide capabilities like file system encryption, but it is up to the EVE Controller to make use of these capabilities to to achieve a security goal. For this EVE needs to define its interface towards EVE controller, and provision a way to define security policies from the Controller. This proposal focuses more on the interaction between EVE and EVE controller in the context of realising a use case that the user might have to secure data processed on the EVE platform.
Sample Use Cases
Assuming that EVE provides a capability to store some files in an encrypted filesystem.
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.
b) A user might also wish to store sensitive parts of EVE configuration (e.g. Image data store credentials), under this secure file system, so that it stays encrypted at rest.
c) A user might also want to be able to create secure file stores and be able to associate an arbitrary Edge Contrainer with such a secure file store.
d) He can choose to use a separate file store for each of his Edge Containers on an EVE node - so that compromising one vault does not lead to access to data of all the Edge Containers
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.
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 parts to it:
a) Lifecycle management of a “Vault” - How user can create, change, delete a given Vault and its associated policies.
b) Association of Edge Containers with a Vault - To control data at rest requirements of a Edge Container
Same API that carries other config, handled by zedAgent
Vault related configuration would be pushed along with other config (by /api/v1/eddgedev/config), and parsed by zedagent. Zedagent would interact with Vault Manager service for implementing file system encryption requirements. Any file system interaction to setup/unlock the vault directory will have to be done by Vault manager according to the security config received, and then signal others that vault directory is now ready for use. Zedmanager will synchronise with Vault Manager to make sure the vault is ready to use before any Edge Container that needs this vault is created by domain manager. Other services can listen to this to perform any task they need to do on top of the vault directory.
Break-up of the proposed Vault Confi
- Data handling policy
- Key Information
Data handling policy
Data handling policy will define, sensitive storage data handling, on encryption algorithm change,
- RETAIN
- DESTROY
RETAIN: This is the normal mode of operation.
DESTROY: This indicates Vault Manager to destroy the given Vault. (Probably due to a security breach detected by EVC)
Key Information
Fscrypt provides a way to change the master key associated with an encrypted folder, without re-encrypting the contents. This is possible due to the protectors and policies constructs used by fscrypt (master key protects the protector, and protector in turn protects the final key used for encryption). Please see here for more details.
We can use this fscrypt feature to periodically rotate the master keys used for a given vault. The key rotation policy will be in the controller and will not be intimated to EVE. For a key rotation scheme, a maximum of two keys will be intimated to the EVE node. Controller will store and publish, the last published key along with the most current key. This will cover cases, when the EVE node is not able to communicate with controller. If there is no key rotation configured, both old and new key fields in the configuration will be the same.
Attestation Challenge by EVC
This is to challenge EVE to provide a requested information, to prove EVE's software/physical location states are untampered. On successful response, further config updates will have Vault section with appropriate Vault config like keys. Failing to provide a satisfiable response, EVC will not send the vault configuration to EVE, and will keep sending Attestation Challenge in place of Vault configuration. Attestation Challenge can be:
a) PCR quote with nonce included
b) Geo location along with the IP address
Attestation Challenge will be handled by TPM manager, after zedagent publishes the config to TPM Manager.
References
- https://wiki.lfedge.org/display/EVE/Encrypting+Sensitive+Information+at+Rest+at+the+Edge
- The pull request corresponding to this proposal: https://github.com/lf-edge/eve/pull/186