Thank you Lena Boeckmann for the PSA persistent storage module. Not finding a @name for Lena. @chrysn ? I am not crazy about making it depend upon LFS, but I can live with that for now.
I am reading the code:
static psa_status_t psa_encode_key_attributes(nanocbor_encoder_t *enc, psa_key_attributes_t *attr)
and psa_status_t psa_encode_key_slot(psa_key_slot_t *slot, uint8_t *output,
after commenting out the code that cleans the keys up from the test cases, and using losetup and littlefs-fuse, I was able to dump one of the keys:
dyas-tests/sys/psa_crypto_persistent_storage mcr 10258 %cbor2diag.rb mem/3 [[3, 28994, 255, 1, [3072, 100665344]], [h’B0244F88A67D1817F5B4ECB797679032F61B83E2897F2DBD2B68EA46047EBF61’, h’CF3A70E4FEB4E1E19C99234DA9CCA57F99A0D79B2E061E85ED2EEC2A07D9C60F’]]
and this seems consistent with what I see in static psa_status_t psa_encode_asymmetric_key_pair(nanocbor_encoder_t *enc, psa_key_slot_t *slot)
but if it follows some CBOR or COSE standard, I don’t see it. Clearly, I didn’t manage to get a key stored that had a public key associated with it, because I think it would be the second element of this nested array.
Why do I care? Because I want to at least generate keypairs on devices, (possibly in factories, possibly in both via threshold cryptography), generate CSRs, and then return the certificate (IDevID) to the device. This would ideally be done via a custom firmware load (to do the key generation) where the mtd is preserved across flash operations.
I think that keyslots names "1’, “2”, “3” … on the littlefs is not a good plan. At least, it should be a directory? To be consistent with (PSA) devices that have a secure element and do not store the private key in the MTD, I think the public key should be in a different file. And we should have a convention for storing an IDevID certificate.
