Versions Compared

Old Version 3

changes.mady.by.user srinibas@zededa.com

Saved on

compared with

New Version Current

changes.mady.by.user Hari C S

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Problem Statement

  1. Currently sensitive configuration blocks for an EVE-node, not all-inclusive, are data store credentials, WLAN credentials, cloud-init (containing Azure/AWS credentials) etc.
  2. EVE Controller posts these sensitive  configuration, in clearThe Datastore Credentials, WiFi Passwords etc are currently received from Controller in plain-text format, as part of the configuration blob . And they to EVE Node. The sensitive configuration blocks are exchanged between agents in inside the EVE Node, as is through pubsub channel. The sensitive information should be stored inside the configblob in encrypted form. And a set of APIs will be provided to the agents to decrypt them, for usage.
  3. The sensitive information exchange between the controller and EVE node should be encrypted end-to-end,  in man-in-the middle proxy deployments also.
  4. There encryption methodolgy used for achiving this, should also work with third-party CA verification

Solution

Motivation

As part of data at rest/transit encryption initiative, for EVE, the sensitive configuration block should be in encrypted format during the transit from EVE Controller and EVE Node, and while at rest(pubsub channel storage) inside EVE Node, until the end-user consumer uses them. 

Proposed Solution

  1.  "Elliptic-curve Diffie–Hellman" key exchange scheme will be used to share the symmetric key used for protecting the credentials.
    An ECC Key pair is generated in the cloud. And a shared secret is generated using the private part of the ECC Key pair, and the public device cert. This shared secret is used as seed to compute an AES-256-CFB cipher. Along with this a random value is generated  to be used as a ICV. The seed and ICV is used to encrypt the sensitive data in the config blob. The public part of the ECC Key pair, and ICV is published as part of the config blob. On the device, the TPM module will use the public portion of the ECC key pair along with the device private key, along with the ICV, to compute the AES cipher.  And the derived cipher is used to decrypt the ciphertext config to clear text.

  2. Scaling challenges: One ECC Key pair per device Vs. a global Key pair for the controller. 
    How controller generates and manages the ephemeral key is up to the controller implementation .e.g. if there is a scaling concern, one such implementation may choose to share a single ephemeral pair among many edge nodes. Or it can create one pair for device and cache it for re-use in every config refresh. The only requirement from the controller is that the key pair for a given edge-node remains static and unchanged, unless there is an administrative trigger to change it.

  3.  Key Rotation : The Key rotation policy will be driven by controller. The edge-node will always get the public cert of the most recent ECC Key pair. 

  4.  Transition Plan: As of now, we will be pushing both cleat-text and cipher text configuration to the device. Once all the devices migrate to a software version that supports this feature, controller will stop sending plaintext, and send sensitive data only as ciphertext.

  5. Changes required in the go-tpm package.Currently ECDH APIs are not available in go-tpm that we vendor from github.com/google/go-tpm.  We will fork the existing the go-tpm master, add this support and vendor it, until it is upstreamed to master.

  6. Inside EVE Node, the sensitive configuration stays in encrypted format on disk (i.e., pubsub), and will only be decrypted on demand by the end consumer.
  7. The end consumer module (e.g. downloader), will unwrap/unseal the symmetric key with the help of TPM-Mgr (using the new go-tpm APIs), and construct the symmetric key first, and then use the symmetric key to decrypt the sensitive configuration block, using software crypto tools (e.g. openssl or go crypto etc.)

Image AddedA symmetric key will be used for both encryption and decryption, generated by the controller module. The configuration blob will also contain a symmetric key attribute.  The symmetric key will be used to encrypt the sensitive information inside the configuration payload. Controller will use the device certificate to encrypt a symmetric key, inside the configuration payload. The agents while invoking the decrption API for the sensitive information, will also pass the encrypted symmetric key. The symmetric key will be decrypted using the on-chip TPM module, using device private key. The decrypted symmetric key will be used, in turn, to decrypt the sensitive information.