Environment Variable Security


#1

I’m wondering how secure Environment Variables are generally speaking?

For example, Let’s say that I store a password in an Environment Variable…

  • I assume the transmission of that Envt Variable to the Resin image is secure, correct?
  • Once the variable hits the image, how is it stored, in memory or on the file system?
  • If it’s on the file system, is it somehow encrypted on the file system?

Thanks


#2

Hi @rmoore, great question!

  1. the communication between the device and the resin.io services is secured via standard secure web communication.
  2. the variable is stored in the file system, so the supervisor can inject it into the user container whenever the container is started, and so that this can happen after reboots and without further access to the internet
  3. on the file system they are not encrypted, as if they were, the system needs to be able to decrypt them without network, so the decryption key would need to be there, completely negating the encryption in the first place

Thus to protect the data within your environment variables, you need to have physical security for the device (i.e. making sure that others don’t have access to it for example to remove and clone the SD card).

We are evaluating other paths as well, for example using secure enclaves, such as TrustZone on ARM devices or TPM for platforms that have that, but it’s a tough nut.

You can also check out this other thread regarding secrets management:


#3

Thanks much for your quick response!

So if I understand correctly, since a hacker could (somehow) access the unencrypted file-system with physical access, there is currently no way to secure a password on a Resin image running on a Raspberry Pi, even if that Pi is modified to use EMMC rather than SD, correct?


#4

eMMC (for example as it is the case for the BeagleBone line of devices already) would pose as a hurdle, but it would just make it more difficult, not impossible for bad actors to access the file system data.

Other setups have similar weaknesses, such as requiring internet access to decrypt some secret then used by the device - the device have to identify itself that it is authorized to get the decryption key - which authorization needs to be then kept safe from bad actors so they couldn’t replicate the authorization, thus back to square one.

Physical access in most security scenarios is considered “game over”, unfortunately. But there are still ideas to be explored and we are constantly looking at new solutions, to provide the best in class security within our service.


#5

Out of curiosity, does the Resin support for Intel Nuc support any higher level of security?


#6

Not at the moment, but I see that there are some ideas being developed internally to make use of the TPM for some way to secure and authenticate the system and updates. No concrete outcome of that yet.

What sort of use case do you have in mind, or what sort of scenario you are thinking to protect against?


#7

At the end of the day, we just want to understand the security considerations 100% and what steps we can take to minimize them.


#8

Got it! We have a security whitepaper coming out soon, that should answer a bunch of related issues, as far as I’ve seen. In the meantime please let us know if you have any questions whatsoever, we take security issues and concerns seriously!


#9

Sounds great - if you remember, please update this thread when the whitepaper comes out so we can stay up to date.

Thanks!


#10

yeah you are right


#11

@imrehg what is the state of the security whitepaper? Thanks a lot!


#12

The security whitepaper should be available in the next few weeks, its currently in the final round of reviews.


#13

Hi @everyone ,

Just a quick update to let you know that the security white-paper is available as a distinct section in our docs at https://docs.resin.io/learn/welcome/security/.

This should address the most common questions, including environment variable security. If you have more questions, please let us know.

Thanks!