Securing the OpenMV cam for deployment.

Putting all this out there so we can get some brainstorming going on. Im trying to lighten the work load of the maintainers of the OpenMV project. To not waste their time lets layout some ideas to pursue so we can package the solution as a cohesive plan to send to the OpenMV team.

For users concerned with device security, the OpenMV cam has issues that are yet to be addressed. Thankfully we have a good community and im sure we can figure something out. Here are some issues I foresee trying to use OpenMV in a commercial environment.
Note: these issues are not really a OpenMV specific, its actually more related to the underlying framework on which OpenMV runs. This framework is called MicroPython

  • Source Code is easily accessible, end users simply have to insert SD card in another machine

Possible Solutions


Doing “proper” security is hard and expensive. It appears that solutions are out there but the process has not yet been streamed lined.

I didn’t know about that upy module for STM32 flash protection. That is nice.

Anyway, the real question is how much of this do you want in the IDE versus just having to do it manually.

I kinda imagined it working like the this:

  • Open OpenMV IDE

  • Select Tools Menu Bar

  • Have a new folder added labeled “Deployment”

  • Then Select “Package For Deployment”

Maybe this could just call a script in the backend to package the .py file so it could then just be saved to a host machine.

For this to work in a way where it’s not a giant time sink for all we should keep in mind the next step of trying to get that “packaged” code onto the OpenMV cam itself. If it has to be done manually for every device through the IDE then that could quickly turn into an issue if you were trying to send out a large amount of devices.
Screen Shot 2020-04-12 at 12.05.19 PM.png

Yeah, I mean for scale you’d just buy cameras from OpenMV with a firmware binary you want programmed. Anything through the IDE is for development purposes.

Given that… You really need a… Deployment binary on the device.

So, I think the solution would be for us to modify the firmware to support reading OTP bits and locking itself down if those are set and only running a script from the internal upy flash drive. We can then mount the SD card under the internal flash drive in a folder called SD or something like that and then we can prepend the SD path to all file system accesses so you don’t need to modify your script to deal with this change.

Then, we have a bit to lock down the external repl, USB, and etc.

But, what features do you need to keep?

I guess that really depends on how updates of the scripts would have to be handled. Personally I plan to use the wifi shield, if OTA updates could be pushed that would be great. Then there would be no reason to allow for any periphrial access in the final product.

I really don’t know how to do OTA updates. Our firmware binary doesn’t leave space for two copies of itself in flash. I can only see you being able to update the python. This would be possible on the you flash drive.

But, you’d need the bootloader to support this as if you used the python script to allow for an update you’d be in danger of being bricked on power loss.

… Anyway, this is a lot of work to support. What could you help with?

I can contribute to the best of my ability which means I can get it done but will take me a while. Just lead me in the right direction and I’ll figure it out. Also since this is so niche maybe just put it off until we can get enough users requesting it to contract you for your time.

Yeah, so, what would help is enumerating each interface that has a hole in it and then describing actions to take for locking down that interface. This will require you to get familiar with the STM32F4/F7/H7 and our code base. Also, thinking about what interfaces might need to be left running for different use cases.

I don’t really have time to focus on this right now however. While this is a helpful feature it’s not a big sales generator at the current moment.