...
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
"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.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 upto 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.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.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.
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
- The cypher mothod will be of two steps, one for sensitive configuration data using a symmetric key, and the other for the symmetric key using EVE Node device certificate.
- Every sensitive configuration block 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.)
- EVE Controller will generate separate symmetric key(s) for every sensitive configuration block. Alternatively, EVE Controller can use one symmetric key for all the sensitive configuration blocks.
- 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 crypto tools ( e.g. openssl or, go crypto etc.)
- EVE Controller will wrap/seal the symmetric key(s) using device certificate of the EVE node, for each sensitive configuration block, before posting to the EVE-Node.
- 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, by not storing them inside any database
.
- 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.
- The end consumer module (e.g. downloader), will unwrap/unseal the symmetric key with the help of TPM-Mgr (using standard 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.)
...