the communication between the device and the resin.io services is secured via standard secure web communication.
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
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:
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?
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.
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?
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!