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.
If it has been working fine and connected to the , the keys are definitely working as well.
I don’t think that feature is supported out of the box since handshaking with the would not be successful.
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.
What’s the requirement that keys must be swapped?
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.
That sounds like a good idea even though some may not agree. But, giving the ‘creators’ the option is a good idea.