Lena and co. have written a very nice paper proposing that the PSA API become the standard crypto-API for all the RIOT-OS supported boards. (I don’t have permission to post the link yet). I hope that we will spend some time at the Summit discussing this.
I’m a bottom-up person, and I care a lot about having crypto everywhere, and not just places where there is a secure enclave or a TPM or a secure element.
So I’m interested in making sure that there is a way to store private keys on every single board, even they aren’t really “secure”. For me, this means a few things:
a place to store the private key which is not (by default) wiped out by reflashing or upgrading the device. I worked on a eeprom-variables mechanism last year, which I’d like some review on.
a way to get the device to generate a private key and put a Certificate Signing Request into memory, and then we need update the various flashing utilities to be able to round trip this. In some environments factory generation of private keys might be better. If using ECDSA, we could also discuss threshold cryptography, which has the device and the factory each contribute to a key. There is also the possibility of leveraging a silicon fab provisioned symmetric seed that some manufacturers do.
software-only secure-element-like drivers that make the low-level PSA mechanism happy.
I would like to do this well enough that the other embedded OS entities decide to just adopt our tooling.
To provide a base for the discussion, I just submitted a PR with my PSA implementation including a link to the paper.
So anyone interested in talking about this can take a look at the code (for some reason I can’t post a link to the PR, but the number is #18547).
I agree that PSA is a candidate for a general API, provided a soft-implementation is possible.
If the soft-PSA needs persistence across updates or re-flashes, I think that needs some brokering through the bootloader. Whether that’s through a dedicated partition, or whether there’d be a marker in the image metadata from which the new image can deduce that the old image had keys stored and the new image can now copy them over (after any conversion) I don’t know – maybe we should put “How do we persist $FOO” on the whiteboard for summit breakout sessions. (Key storage persistence is one aspect of it, but I suspect that flash-persisting device identity might have more than just the key facet that is expressed through PSA.)
this is really 97% of everything I care about.
I’d like to have 97% coverage for all boards/CPUs with soft-implementation, and with a soft/insecure element for the private keys. (Better being the enemy of good enough)
I think that we might have boards/CPUs where we’d have a marker and include keys to be copied, and other boards/CPUs where we have a dedicated partition.
That’s an interesting thing to say. Tell me more.
I see at least three levels here, but you might be thinking on an orthogonal axis.
I want my boards to persist the identity that I assigned to it across R&D cycles.
I want the boards I/we/Mike-From-Canmore bought from Adafruit (e.g.) to persist the identity that they assigned to the board across Mike’s R&D cycles, and/or software-update cycles.
I want the boards I had manufactured by XYZ.co.tw to persist the identities that I arranged to have embedded in them across software-update cycles even though the boards/products were drop-shipped to the end-customer, and I never even touched them.d