You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

Problem Statement

Currently, EVE does not have capabilities of data security at rest. This is being designed and implemented. While EVE provides capabilities or building blocks, it is up to the EVE Controller to stitch them together 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 defines such an interface.

Proposed change in the EVE Provisioning Workflow

Current Workflow in Provisioning EVE

The current user driven, device management event flow at the high level, is as follows, 


New Stage in the Workflow - The Security Policy Enforcement 

We propose a new stage/API in EVE Provisioning, where the controller can enforce the device policies on EVE, before EVE launches the pillar microservices. The reason we need this framework is because:

a) Mostly security policies have to be enforced at the time of EVE Provisioning or at the first handshake after a reboot, to setup the execution environment for launching other pillar services. e.g. one may setup disk encryption or unlock the encrypted directories for use by pillar services later on. Thus this can not be tied into regular config processing logic inside zedagent since we need access to these policies at a very early stage, immediately after "client" gets the UUID, and before any of the pillar services are launched. In other words, enforcement of security policies needs to precede launch of any business logic inside pillar.

b) This security polices contain sensitive information like encryption keys, which is best handled only in memory, and not stored on the persistent storage like other config items. Having a separate API endpoint helps handling of security policies be modular and more maintainable, without disturbing how config related to other pillar services are handled.

Therefore the proposed user driven, device management event flow, will be as follows.

Vault Manager to anchor handling of security policies

This module in EVE, will be responsible for periodic device policy fetch from controller and enforce them on the device.  More more details, are specified in [Ref.1].

Details of the Proposed API

The policies are grouped into two major categories

  • Data At Rest Policies
  • Data In Transit Policies (mostly a placeholder for now, added for future use)

Data at Rest Policy

Data at rest security is applicable for the Application Instance mutable business sensitive data and  storage for EVE sensitive configuration information.Application instance mutable business sensitive data will be stored in a reserved partition/directory and the security policy configuration will be applied on it.

The data at rest security policy will be applicable to application business sensitive data, covering the following aspects,

  • encryption algorithm
  • data handling policy
  • offline activation policy
  • key rotation policy
  • key Information

Encryption Algorithm

This specifies, the encryption algorithm to be used for data at rest security. [Ref. 1].

  • NONE
  • AES256
  • ADIANTUM

Data handling policy

Data handling policy will define, how the sensitive data will be handled, when user changes encryption algorithm. 

  • RETAIN
  • DESTROY
  • DESTROY_ON_SECURITY_BREACH

RETAIN: The application business sensitive data will be retained on encryption algorithm change.

DESTROY: The application business sensitive data will be destroyed on encryption algorithm change.

DESTROY_ON_SECURITY_BREACH: can be initiated by the user, on compromised device detection or, by

some user defined policy in the controller module.

Data Recovery Policy

When an EVE node faces network outage, it will keep operating, using the last configuration received.

On power recycle, followed by network outage, for an EVE node, the EVE node may require physical access/user intervention,

with the following options.

  • None
  • USBKEY
  • KEYBOARD

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

Key rotation policy

This will define the key rotation activation. The key rotation poilcy will be in 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. Controller will store and publish, the last published key along with the most current key. This will cover cases, when EVE not able to communicate with controller.

Data in transit policy (Mostly a placeholder for now, details added for brevity)

The data in transit security policy, will be applicable for the sensitive configuration data in transit between the controller software and the end user (downloader) inside EVE.

Data in transit security, is applicable for controller and EVE Module data exchange. The data in transit security for Application instance data traffic will be prerogative of the application software and, is out of scope for the current proposal. Currently, TLS 1.2 is used for data in transit security, for configuration/status/information exchange between the controller and EVE.Additionally, sensitive object level configuration information, viz. data store credentials,  will be secured end-to-end between the controller and downloader(inside EVE), by using the device cert/key pair. The sensitive configuration for EVE, will be stored in encrypted form (cypher text), till it is ready for use by the end user. viz., data store access credentials. Currently, the data in transit is secured through TLS 1.2 framework,  between the controller and EVE.

References

  1. https://wiki.lfedge.org/display/EVE/Encrypting+Sensitive+Information+at+Rest+at+the+Edge
  2. The pull request corresponding to this proposal: https://github.com/lf-edge/eve/pull/186
  • No labels