I was wondering if it is possible to reprogram a Photon that is ‘in the field’ that could have corrupted its keys. Is there a way to simulate the key presses so the unit could accept new (or correct) keys in the field should that be necessary?
I was thinking maybe a daemon could be developed; but maybe this breaks the security that is implied. I am just wondering if a unit fails in the field; and it needs keys; if there is a way to do that without having to have direct physical access to the Photon.
I haven’t looked at this closely enough except going through the ‘out-of-the-box-key-experience’ and if that were to happen in the field it isn’t acceptable for the application we had in mind here. If it is possible to develop a daemon that could detect - over a time out period - that the connection has been lost and could ‘boot in’ the keys - then that could work; obviously this takes some development and debug; and maybe defeats the key security strategy if that is a ‘hands-on’ thing for security purposes. We just don’t have access to the buttons once deployed - just not physical access.
If keys were working and then are destroyed in the field on a deployed product, then someone has damaged the flash of the device, and it’s likely the firmware has been tampered with, etc, etc. The photon has some capacity to generate and send a new key, and if the device starts sending a new key (different from what was agreed on), then the cloud has the capacity to allow it or not. We’ll certainly be adding more tools to expose this functionality, and I think product creators will have the option to allow in “devices with weird keys” or not if they want.
, the keys are definitely working as well.