...
- The sensitive information, like datastore credentials, WiFi Passwords etc., are in clear-text format inside the configuration blob, received from EVE Controller. The sensitive information is exchanged between agents in the EVE node, as is through pubsub channel.
- The sensitive information should be in cypher text encrypted format inside the configuration blob for EVE node . A set of APIs will be provided to the EVE agents to decrypt themduring the transit and at rest in pubsub storage.
- The sensitive information exchange between the EVE Controller and EVE Node should be encrypted end-to-end, in man-in-the middle proxy deployments also.
- There encryption methodology for this, should also work with third-party CA verification
Solution
- .
Proposed Solution
a) For protecting the sensitve blocks of configuration, a symmetric key (AES-256) A symmetric key will be generated by the EVE controller module. This symmetric key will be used for both encryption and decryption. The configuration blob will contain a symmetric key attribute field, to store this symmetric key.
While preparing the configuration blob, the EVE Controller will use this symmetric key, to encrypt the sensitive information. In turn, EVE controller will use, the EVE Node device certificate, to encrypt the symmetric key.
, for every sensitive block of configuration. (e.g. data store credentials, WLAN credentials, cloud-init etc). It is up to the EVE controller to decide if it wants to use the same key for all the blocks or dedicated key for each one of them.
b) Controller can also decide to change the symmetric key(s) periodically, as per user defined policies, which is beyond the scope of this document. The only requirement here from EVE is that, EVE is given the encrypted configuration blobs along with the information to build the symmetric key required to decrypt the corresponding blobs.
c) EVE controller will wrap/seal the symmetric key with device certificate of the EVE node, before sending it across to the EVE node.
d) The senstive configuration stays in encrypted format on disk (i.e. pubsub), and will be decrypted on demand by the end consumer module while processing the configuration.
e) To decrypt the configuration from, the consumer module(e.g. downloader) will unwrap/unseal the symmetric key with the help of TPM-Mgr (using standard go-tpm APIs), and construct the symmetric key first, and then use the symmetric key to decrypt the sensitive config blob, using software crypto tools (e.g. openssl or go crypto/ package)On EVE node, the agents will also pass the encrypted symmetric key along with the encrypted sensitive information, while calling decryption method API. The symmetric key will be decrypted first, using the device private key stored inside TPM module. In turn, the clear text symmetric key will be used to decrypt the sensitive information.
