...

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. 

Possible Approaches

The Security Policy can be at applied at EVE Node level or, Application Level. For easier mangeability,  we are proposing the security policy application at the Node level.

We are exploring multiple options for implementing such an interface, and we will discuss them in detail below.

Option 1:  Separate REST API, completely handled by Vault Manager

Option 2:  Same API that carries other config, handled by zedAgent

...

 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

Option 1:  Separate REST API, completely handled by Vault Manager

Table of Contents

Current Workflow in Provisioning EVE

...

The user has to ensure that, proper configuration is stored in the USB Stick or inputs them through to Keyboard.

Key rotation policy

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 vaultThis will define the key rotation activation. The key rotation policy will be in the controller and will not be intimated to EVE. 

Keys

This consists of  set of Keys information( max. 2). 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.

...