Willing to protect my flows running on remote RASP - and without a safe method to protect my MicroSD (even if gluing the MicroSD should be a possible solution) - I'm thinking about implementing a simil "self-distruction" procedure (triggered from a msg sent to the Raspberry) in order to avoid other people to take the flow.json/settings.js files that are stored within the MicroSD.
Without a deep knowledge of Node-Red I ask you if it's possible to delete the flows.json file (and the settings.js one) when the same flows - that I want to delete - is running...
In case this should not be possible, an alternative solution should be to launch - from node-red itself - an external script that will stop node-red and then delete the flows.json and the settings.js.
Is it feasible in your opinion? Or are there other valid methods to achieve that?
Rather than implement a self destruct, if your flows and data are so sensitive that they need to be destroyed on malicious access, are you sure that you’re using the right hardware for your project?
I know that Node-Red+Rasp is not the best solution for protecting my code. The development of my solution has taken months and now I'm not able to switch to another HW (expect for a RASPBERRY-like alternative solution - I need each and every GPIO, I2C, Serial, etc.. now avaialble on a Raspberry Pi Pi3**+ I used now - that will save all the code I've developed in Node-Red).
As a backup and as a last-option solution I need - for this time - just to find a way to destroy the code stored on the Raspberry.
Does - in your opinion - a solution based on alternatives Raspberry Pi compliant HW solution (such as RASP CM 3 IO Raspberry Pi - Scheda I/O Compute Module 3) with on-board EMMC storage flash (avoiding the MicroSD weakness) solve my security issues (protecting my node-red code to be stolen by someone and modified/reused without permission)?
Not by default, but it makes it a lot harder. It sounds like you need encryption at rest minimally, but even then you need a way to exchange encryption keys. If someone has physical access to the device that might be accessed regardless of your solution.
There’s a few topics out there discussing this situation, you might find more tips there. Which I see you’ve posted to already. And remember, even if you had compiled binaries, if they can be accessed chances are they can be reverse engineered with effort, expensive tools (e.g. ida pro) and time/motivation. Or interacted with through injection of code into the process, for example with Frida. Can you explain more about your use case that makes it so sensitive that your flows have to be deleted? Is it just trade secrets for competitors, or are you working in a specific sector where everything is sensitive? And think about this: it might have taken you months to create this prototyping specifically for a raspberry pi and node-red, but if the keeping it out of other people’s hands part is so important, is node-red/raspberry pi the best combination for your situation? Do a risk assessment, and figure out if the (financial) impact is worse than having to restart with what you’ve learned so far, on a platform that gives you that better protection.
PoC||GTFO is one of my favoured pastime readings. If there’s one thing I’ve learned from it as that as long as people have motivation, very few physical devices can withstand the reverse engineering efforts.
Lena, thanks for the feedback.
The reason for havnig a self-destruct functionality that delete the flows file is required because I want to have the opportunity - from remote - to delete the node-red flows in case the client of the application I've developed (that are not technical people and they are not willing to steal commercial enterprise sensitive data/secrets written in my Node-Red code) didn't respect mutual agreement that - unfortunately - are not been already formalised in written.
Waiting for formalising the agreement between me and my client I want to introduce within the software I'll provide them a way to be able - in case of Emergency - to delete the flows.json/settings.js files. I know that: the RASP have to be "online" in order to lauch the self-distruction command and that the client didn't make a backup copy of the MicroSD, etc... but I want to go in that direction.
I'll go through the reading you suggest me (also because this is - unfortunately - a period where the best to do is stay at home)... Beside that, as far as you now, is there a way to migrate alla the Node-Red flows on a more secure HW/infrastructure?
We offer a solution to what you are looking for. It is a paid service so I do not want to promote it on the public forum. PM me if you would like more information.
