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

Compare with Current View Page History

« Previous Version 18 Next »


Problem Statement

  1. 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. 
  2. The sensitive information should be in encrypted format inside the configuration blob for EVE node during the transit and at rest in pubsub storage.
  3. The sensitive information exchange between the EVE Controller and EVE Node should be encrypted end-to-end.

Proposed Solution

  1. The sensitive configuration blocks for an EVE-node, not all-inclusive, are data store credentials, WLAN credentials, cloud-init (containing Azure/AWS credentials etc.)
  2. Every sensitive configuration blok will contain a set of attributes storing the encryption configuration (symmetric key value in cypher text, key size and encryption algorithm .e.g., "keySize": "256" bits, "algorithm": "AES-256" etc.)
  3. EVE Controller will generate a symmetric key for every sensitive block of configuration. Alternatively, The EVE controller can use the same key for all the sensitive configuration blocks.
  4. EVE Controller will use symmetric Key(s) to encrypt these above mentioned sensitive configuration blocks, using standard encryption methods ( AES-256 etc.) using standard software ctypt tools ( e.g. openssl or, go crypto etc.)
  5. EVE controller will wrap/seal the  symmetric key(s) using device certificate of an EVE node, for each sensitive configuration block, before posting them to the EVE-Node.
  6. These symmetric key(s) generation/rotation can be driven by user defined policies, which is beyond the scope of this document. EVE controller can also generate these symmetric keys, while constructing the configuration blob for an EVE node, and discard them after that.
  7. Inside EVE-node, the senstive configuration stays in encrypted format on disk (i.e., pubsub), and will be decrypted on demand by the end consumer. 
  8. The end 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 etc.)



  • No labels