...

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

Current Workflow in Provisioning EVE

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

Image Removed

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.

Image Removed

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 details, are specified in [Ref.1].

...

Same API that carries other config, handled by zedAgent

In this approach, security policies are Vault related configuration would be pushed along with other config (by /api/v1/eddgedev/config), and parsed by zedagent. But zedagent will prioritise handling of security config over the rest of the config  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.  Zedagent would interact with Vault Manager service for implementing file system encryption requirements. 

Option 3:  Same API, handled by Vault Manager at boot time, and ZedAgent at runtime

It is a mix of Option 1 and Option 2. It uses the same REST API that is used for pulling the device configuration (/api/v1/eddgedev/config). But Vault Manager will extract security config parts during pillar launch, to set up any filesystem encryption etc.  Once ZedAgent takes over, any further change in security config can be driven from zedAgent, by passing the configuration to Vault Manager through pubsub mechanism.

Break-up of the proposed security config (Applicable to all the Approaches)

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 cover, the following aspects,

• encryption algorithm
• data handling policy
• data recovery 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

Break-up of the proposed Vault Config

• Attestation Challenge
• Data handling policy
• Key Information

Attestation Challenge

This is to challenge 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

Data handling policy

Data handling policy will define, sensitive storage data handling, on encryption algorithm change, 

• 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 known policy configuration.

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

to decrypt the data vault, 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.

...

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. 

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.

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

Currently, the data in transit is secured through TLS 1.2 framework,  for configuration/ status/ information exchange  between the controller and EVE.  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.  The scope of data in transit security policy, will be applicable for the sensitive object level configuration data in transit between the controller software and the end user (downloader) inside EVE, viz., data store credentials. This will be done 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 downloaderIf there is no key rotation configured, both old and new key fields in the configuration will be the same.

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

...