...
- The app instance configuration may include a reference to a defined vault.
The mutated business sensitive information for the container will be stored in the associated vault.
c) Attestation of the device through PCR quote and Nonce and/or Geo-location/IP Address information.
...
This will be done device reboot along with periodicallyas well as on periodic basis, to make sure the EVE node is not compromised.
...
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 started by domain manager. Other services can listen to Vault Manager to perform any task they need to do on top of the Vault directory(Currently only zedagents/zedmanager). .
Presence and absence of the Vault configuration below will implicitly drive creation and deletion cases for the Vault.
Break-up of the proposed Vault Config
- Identity of the Vault under consideration
- Vault Security Policy for the Vault
- Key Information for the Vault
...
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.
Association of Edge Container with the Vault
App Instance configuration will carry this information - Whether the App is protected by End-to-End Security, and if yes, what is the Vault to associate this App Instance with. Zedmanager will consume this configuration, and co-ordinate between Vault manager and Domain Manager to make sure the required Vault is ready before launch of the User Application.
...
Attestation Challenge will be handled by TPM manager, after zedagent publishes the config to TPM Manager. Details about attestation are outside the scope of this document. What concerns here is the fact that, based on attestation outcome, EVC may not (based on user configured policies) reveal the Vault Key, by not sending any Vault config to EVE.
Security Threats Addressed
| Security Threat Scenario | TPM Key | Controller Key | Controller Key with Attestation |
|---|---|---|---|
| Storage Drive is taken out and inserted into another system to read the data | Protected | Protected | Protected |
| EVE device is taken out, and booted up in another location to access its data, but no knowlede | Not Protected | Not Protected | Protected |
| Not Protected | Not Protected | Protected | |
| EVE device is not taken out, but some other malware is loaded on the system, and is used to get access from remote to access the information |
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
...