Looking forward to the new OpenMV N6 
In the meantime, Im trying some things out on the STM32N6 directly regarding their secure boot support.
Will this be part of the OpenMV N6 MicroPython support with the OpenMV IDE?
We operate the N6 in secure mode all the time. Can you explain in more detail?
Normally, when you flash your code to a secure boot, you need to generate keys and sign your binary.
See https://wiki.st.com/stm32mcu/wiki/Security:How_to_install_a_trusted_application_on_STM32N6_MCUs
Besides this, the Kickstarter also mentioned future OTA updates of cellular (which is an extra complexity/functionality in case of using a secure boot). Also described in the link above.
The bootloader is signed and then can load pretty much whatever you want in various memory regions. It doesn’t look at keys. The default bootloader we provide will be USB DFU at the start. Once we have more budget, the plan is to work with Golioth to add UART update to the bootloader via the nrf9151. A customer needs to appear to make this happen, however. But you are free to modify our bootloader to implement whatever. As for full device encryption, this falls under needing a customer for the feature too.
The bootloader is signed and then can load pretty much whatever you want in various memory regions
So to be clear, atm, OpenMV N6 does not have the goal to prevent side-channel attacks such as someone trying to load their own (malicious) program onto the board?
Main reason Im asking is some industry certifications need to proof only your own code can run on a specific device.
How would one store for example api-keys on an OpenMV device? Is there a way to prevent reading the code that is running on the device?
So to be clear, atm, OpenMV N6 does not have the goal to prevent side-channel attacks such as someone trying to load their own (malicious) program onto the board?
The firmware for all parts of the system are open source and we provide tooling to modify anything. As a development board for your application it’s up to you to lock the system down at the moment. The MCU features everything necessary for you to do this. But, you need to modify our firmware at the to do such things.
How would one store for example api-keys on an OpenMV device? Is there a way to prevent reading the code that is running on the device?
There’s a secure enclave onboard, thanks to it being ARM v8 architecture. All the hardware you need is on chip. But, software enablement to make it easy to use from Python is not going to be there on product launch. ST has API for all these things though that you can customize in our firmware.
Typically, we expect serious users to fork our code base and customize the firmware after getting their application working in Python to lock down the system and customize aspects of the system as they need.
Like, if you want to disable JTAG access, you have to burn a fuse to disable this from being available. Doing so will prevent the device from ever being easily debuggable again. You can also burn encryption keys into the fuses onboard which prevent the system from running unencrypted binaries. There are plenty of features in the hardware to lock your application down, but, generally, they also can easily 100% brick your camera if not used correctly.