This topic comes up from time-to-time, but I haven't seen a satisfactory answer.
I need a way to encrypt the source code on the micro SD card so that the card is useless if someone pulls it out and tries to make off with my IP. Obviously, some type of encryption key would be required by the loader to decrypt flows.
Extra credit: Allow the encryption to be applied at the flow or node level.
Has any thought been given to such a feature? What are others doing?
One possible route is to encrypt a partition on the SD card. The downside is that you would have to enter a password every time you boot. Some idea of how to do it:
Interesting, but the password at boot time is not workable because my devices are deployed "headless".
It is difficult to think of a simple alternative. If the data is not encrypted in a way that requires manual entry of a password then if someone has a Pi similar to the one the card is running in then if they removed the card from the original Pi and put it in there own one then the Pi would boot and from there they would be able to access the files.
One solution I can see to that would be to have some hardware on the original Pi which cannot be easily replicated and encrypt the data using a key derived from something in the hardware, so effectively a hardwired password built into the original Pi or a daughter board attached to it.
Another solution would be to have the password on the local network somewhere and have the Pi access it on boot and decrypt the node-red partition using that. But if this person is able to get access to the Pi to get the card out then perhaps he has access (at least temporarily) to the local network too.
You cannot have full headless, hands-off encryption without specialist hardware which isn't likely available for the Pi.
The best I can think of would be to create a trap that, on boot, checks for some known entity or value from your local network and, if not present, destroys the data. Of course, that will only work if the card is booted up. To help mitigate that, you can use an encrypted partition with the key buried as deep as possible in a root accessible only file. Come to think of it, if the startup check fails, you only need to trash the key file not the partition.
Needless to say, keep backups! And keep them offsite - if someone gets access to your Pi - they will take EVERYTHING including local backups. I know it happened to me a couple of decades ago.
There is a raspberry pi serial number that could be used as an encryption key. That seems workable for the case where the SD card has wandered off.
What if flows could be loaded over the network and never saved to local storage? That would safeguard the code and facilitate the distribution of updates, which is another challenge we face with IoT devices. Two for the price of one.
You can create custom storage plugins for the runtime - so yes, that would be doable. Although how would you know it was an authorised device requesting the flows and not someone who has accessed your device and got any certificates/keys off it and reused them?
This is a hard problem to do right. As Julian said, short of using purpose-made secure hardware, all you can do is make it inconvenient to access your flows rather than make it impossible.
If someone has access to the Pi to grab the SD card, what makes you think they won't just pocket the Pi?
I keep a record of authorized devices in the cloud using the serial number.
Network loading would be the best option for my use case, I think. Sounds like a non-trivial effort.
In my case, the pi is attached to other hardware in a way that it makes it pretty hard to remove. But we expose the SD card slot for field software updates.
An Atmega32u4 in USB key format programmed to act as a USB device could handle a simple handshake to act as a hardware dongle like they used to use to protect software licenses. You could do something drastic like glue the Atmega to the case itself so it couldn't be removed. or something like that.. Just spitballing here.
It looks like this and can be programmed to connect as a USB device of your choosing.
Here is one more by Infineon
I’ve never heard of Zymbit but well familiar with Infineon, its TPM chip is installed in my toughbook and was active when I used it for work.
I would definetly go for this one
I'm facing the same problem and I feel comfortable with your suggestion being the loss of all node-red flows a minor problem for my project instead of having the flows stolen by someone. I'm wondering in reading at the beginning of the node-red flows some sort of password stored within an I2C EEPROM chip hidden somewhere in the Pcb board the RASPBERRY is connected to. In case the password check will not be completed (for instance because the PCB with the I2C EEPROM has not been stolen togheter with the RASP/microSD) the node-red flows itself launch a BASH shell command to delete the flows.json file and other python scripts required to run correctly the system. In other words - if the password check against what is written within the I2C EEPROM chip is not passed, the node-red flow destroy itself....I'm not an expert and I don't know if the flows.json file can be modify when Node-Red is up and running....Or as an alternative the logic within the flows.json file should modify some other files node-red uses to launch what inside the fows.json file, so making not possible flows.json file to be started anymore. What about this option?
If the SD card (or pi) is stolen then all someone needs to do is to plug the SD card into a card reader and read the flows file.
I know Colin but my flows are very huge and complex (about 1.2 Mb json file) and I can hide the control/erase logic in a flow that cannot be easy understand/read by a people that is not so smart.... I know that it is not a 100% safe solution but a good option. Don't you?
Having read through this thread in detail, I'd have a few suspicions about the original aim of the thread.
When whole-disk encryption was suggested (requiring a password at boot time):
To my mind, the desire to secure Node-RED data (presumably as it contains a plethora of credentials for IoT cloud services?) is a noble one, and undoubtedly a common one.
But this comment above, combined with the earlier stated goal of wanting to make sure nobody runs off with the SD card of a Pi, I would argue makes this one a niche case.
I expect the majority of users would want to protect against online attack, but the point being discussed is the (very reasonable) possibility of physical theft. Given this, the salient point would be:
to which the response was:
This makes the enquiry even more niche. Maybe I'm jumping to conclusions here but the idea that you couldn't do software updates over SSH presumably means that Pis are being installed without network connections. And this is why the SD slot needs to be exposed. i.e. someone has actually built this update procedure into their business plan, or somesuch.
Also to be concerned with theft of data from an SD card, but NOT be concerned with the theft of the Pi itself, that's even more niche. i.e. someone who already has physical access to the room or location where the Pi is.
i.e. someone known to you.
Sounds like @dennishvo has already identified from whom this genuine risk of theft comes from. Someone who works with the unit, know what it does, and knows how to recover raw data from an SD card, knows where to look for Node-RED configuration files, and knows how to build a Node-RED server to import / inspect them to steal his work. For example, an IT Engineer. Or those people who are charged with the job of updating SD cards.
Sounds to me like someone who is in need of a security consultant for their specific use case.
Again, hope I haven't jumped to too many conclusions here, but I am somewhat bemused by the original questions "what are others doing" or "I haven't seen a satisfactory answer" 
I have no such requirement, the questin is whether it is a good option for you. You said you wanted a method of deleting the flow file if the board is stolen, and suggested a way of doing that, but now you say that you don't care if someone can just take the card and read that. It doesn't make sense.
Sorry Colin where did you read in my reply that I don't care if someone read (and modify and eventually reuse) the flows.json? This pseudo "auto-distruction" method is intended for make impossibile for an unauthorised user to modify and run the node-red flows. I mean....If you cannot protect (for instance obfuscating the code) its's better to destroy it!
In the case an unauthorised user stole the MicroSD and copy the flows.json file (cedentials file and the othe files required for node-red to start) and the start node-red, the program inside node-red will do the following:
A. create a script that do the following:
In case, instead, the unauthorised user just open the Node-Red IDE and look at the software he has to find the flows that perform what above and delete them.
I hope this clarify my point.
To disable the flow that autodestructs the flows file all he has to do is to write protect the flows file.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
