-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provisioning roadmap #446
Comments
Some updates from a recent voice chat with @kaspar030:
|
Concrete sketch of a plan:
This does not need any support from the programmers in that all binaries we flash are safe to flash onto any device, and then the key-management part will "just" overwrite the keys we had for the device (OK, revoke, we don't delete data just so -- but in this case, we just accidentally erased the device, so it's OK that its keys are revoked too :-) ). I think that that kind of provisioning should be run once at programming time. Next stage provisioning can then run from those keys unless it's the simplest case where only a public key is reported publicly. |
Contributes-To: future-proof-iot#446
Description
Around the flashing step we should have an option to customize what is on the device.
Whether that is part of the built source code (eg. through environment variables), linked in, flashed to a dedicated memory address, flashed through some code placed in RAM and executed there or done by the starting application while it communicates with the debugger is an implementation aspect that will need to be figured out, but may not be the same across all platforms.
Motivation
To make the usability aspects of CoAP (road map on #226) fly, we need some better provisioning.
Requirements
Concrete requirements are that
Item 1 is just security essentials1, item 2 is for practical reasons: If we want to express "All my devices may access this resource" without checking signatures, the public keys of all those devices need to be in some list, ideally distributed to other devices – which is practical for the 20-or-so distinct boards a typical developer ever flashes, but not for the 20k different boards those appear as if every flashing creates a new participant without revoking the old key. Item 3 is convenient if you don't want to limit "All my devices" to "All my devices so far", but update a device without revoking its permissions. (Using this is a trade-off, and I think that by that time one would rather use signed identities, but 1+2 enable it to the point where it is cheap enough).
Open questions
Will probe-rs or other debuggers help us?
Not immediately: Unlike in debuggers specialized to concrete series (eg. those on EFM32 devices where I've just used that for years and took it for granted), there is no concept of a device identity that a flashing or debugging process can be aimed at – some chips have registers that could be read through a debug interface, some chips have an area in their in-SoC QSPI flash for that, some have nothing but could have an identifying chip on board (eg. the MAC of the soldered-on Ethernet module).
How does such customization fit in the laze process? Will the
run
target commonly used now, instead of being flash-and-attach, become flash-and-provision-and-attach? When (which I expect can be a step on the way) binaries are customized, how does the pre-flash provisioning preparation feed data back into the build process?Are you planning to do it yourself in a pull request?
Yes
Footnotes
Protocols nowadays sometimes have mitigation in place, so eg. in EDHOC (unlike in similar protocols like earlier versions of Tox) when someone else has your key they can't impersonate anyone else to the owner that key, but that is supposed to be an extra layer of security and not relied on. ↩
The text was updated successfully, but these errors were encountered: