lf-edge
Securing Sensitive Information in Transit and at Rest
Securing Sensitive Information in Transit and at Rest
In Transit
It is imperative that sensitive information while getting exchanged between Cloud Controller and EVE is not in plain text but in encrypted form. For increased level of security, object level encryption should be used end to end instead of only relying on the TLS. (Note that there are no TLS level proxies; merely support for http proxies which can not see the payload).
Approach
Zedagent microservice is responsible fetching the configuration from Controller, periodically. Controller will encrypt configuration with device public key before sending it to zedagent. Zedagent will decrypt using device private key before processing the configuration. In future, a key refreshing mechanism can be brought in place. I.e. instead of using a fixed keypair, we can rotate the keypair on a periodic basis. This will be investigated in later phases.
At Rest
It is also imperative to store sensitive information on desk in encrypted format, instead of plain text. This is required in addition to disk/partition/directory level encryption, so that even in case of a hacker getting root access to the device, can access the file system, but the contents of the file can not be decoded without getting access to the decryption access. I.e.
-
File system level encryption ensures security in case the disk is physically stolen/compromised
-
Encrypting sensitive information before storing on the disk ensures that even if some hacker/malware gets root access on the device, the sensitive information stored in the file is not in plain text.
Approach:
Zedagent microservice is responsible for parsing the configuration from controller, and passing the configuration to other microservices using pubsub infrastructure. In the process, zedagent writes device config under /persist/config/checkpoint and /persist/config/GlobalConfig. While writing to these directories, sensitive information like VncPassword, S3 Storage credentials will be encrypted using public key of the device. Accordingly the readers/subscribers who are processing this config will also be modified to decrypt using device.key.pem(for devices without TPM) or with device key inside TPM.
Staging Plan for Implementation
Since this activity involves code changes in Controller as well as in EVE, the following transition plan is proposed:
-
First implement a POST api in controller for fetching device config. This is in addition to existing GET method
-
In the POST method, send device config after encrypting it using device’s public key
-
Change EVE code to do a POST instead of GET, and from reply to the POST message decrypt the device config sent from Controller using device’s private key
-
Devices running old code will still do a GET and Controller will reply to GET with device config in plain text - This is till all devices are upgraded to use POST instead of GET
-
Once all devices are upgraded to new method, stop processing GET in Controller
Hi Hari,
Is this document being sent for review? The REST API semantics are completely off. A POST API is used for posting something to the REST API endpoint. You seem to be using it for fetching the device configuration. You might want to use GET verb but with different REST API endpoint, to differentiate from the existing GET device config API, instead of POST.
Chirag Kantharia Zededa India
On Mon, Jul 8, 2019 at 4:42 PM cshari-zededa [email protected] wrote:
Securing Sensitive Information in Transit and at Rest In Transit
It is imperative that sensitive information while getting exchanged between Cloud Controller and EVE is not in plain text but in encrypted form. For increased level of security, object level encryption should be used not relying on the underlying transport security (which may involve a TLS level proxy, thus exposing the object in clear form in the middle). Approach
Zedagent microservice is responsible fetching the configuration from Controller, periodically. Controller will encrypt configuration with device public key before sending it to zedagent. Zedagent will decrypt using device private key before processing the configuration. In future, a key refreshing mechanism can be brought in place. I.e. instead of using a fixed keypair, we can rotate the keypair on a periodic basis. This will be investigated in later phases. At Rest
It is also imperative to store sensitive information on desk in encrypted format, instead of plain text. This is required in addition to disk/partition/directory level encryption, so that even in case of a hacker getting root access to the device, can access the file system, but the contents of the file can not be decoded without getting access to the decryption access. I.e.
File system level encryption ensures security in case the disk is physically stolen/compromised 2.
Encrypting sensitive information before storing on the disk ensures that even if some hacker/malware gets root access on the device, the sensitive information stored in the file is not in plain text.
Approach:
Zedagent microservice is responsible for parsing the configuration from controller, and passing the configuration to other microservices using pubsub infrastructure. In the process, zedagent writes device config under /persist/config/checkpoint and /persist/config/GlobalConfig. While writing to these directories, sensitive information like VncPassword, S3 Storage credentials will be encrypted using public key of the device. Accordingly the readers/subscribers who are processing this config will also be modified to decrypt using device.key.pem(for devices without TPM) or with device key inside TPM. Staging Plan for Implementation
Since this activity involves code changes in Controller as well as in EVE, the following transition plan is proposed:
First implement a POST api in controller for fetching device config. This is in addition to existing GET method 2.
In the POST method, send device config after encrypting it using device’s public key 3.
Change EVE code to do a POST instead of GET, and from reply to the POST message decrypt the device config sent from Controller using device’s private key 4.
Devices running old code will still do a GET and Controller will reply to GET with device config in plain text - This is till all devices are upgraded to use POST instead of GET 5.
Once all devices are upgraded to new method, stop processing GET in Controller
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lf-edge/eve/issues/127?email_source=notifications&email_token=AHI2LU6IARSST53K6EE6LP3P6MOKDA5CNFSM4H62SHRKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G52LBPQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AHI2LU344347BWSYHODD2ATP6MOKDANCNFSM4H62SHRA .
Hi Chirag, Thanks for reviewing. my bad, I wasn't explicit in explaining the intent behind the POST API.
With POST, we will actually be posting of a hash of last received configuration. Only if the configuration for the device has changed, Controller will respond with the new configuration. This is to save sending the same bits unnecessarily over the network, when there is no change in the configuration. As part of this exercise(subject of the issue), we will also be encrypting the configuration with device key, whenever POST has to reply with the new configuration.
I question if a POST is the best approach here? You can use etags in a GET request to indicate what the latest version you have (define versioning how we want; hashing is fine). It has several nice advantages:
- It is an RFC standard
- It can be controller-optional. A controller that doesn't implement it can choose simply to ignore it
- It is arbitrary. As long as the etag is sent with the original config, EVE can send it back with the next one without knowing or caring what it means, leaving it entirely up to the controller.
Practically, we will need to have some understanding when we start breaking down the config into its parts, but in principle, it is opaque to the client: receive with one GET, send with the next. Controller decides whether that warrants a full new send or just nothing to update.
I think there are 3-4 issues here, each of which should get its own. I am quite glad you got it all in here, @cshari-zededa ; they needed to be brought up and begun to be attacked in a public place.
May I suggest that we break these into separate issues and address each separately?
- encryption at rest
- encryption in transit
- efficient caching of configuration
Each definitely deserves its own conversation.
Hey @cshari-zededa to add on top of what others have said let me first publish a set of project requirements #123 and then we can see how to split this proposal of yours.
Makes sense?
