There as a side meeting this morning on using PSA as an API; here are notes taken from it (sorry for the gaps):
RIOT summit 2022: Security break-out
MCR taking the moderation goggles.
MCR: Care about ubiquitous cryptography, that makes maximum use of available hardware. (It’s faster, it’s more power efficient, and security advantages from storing private key deeply in hardware). Includes secure and measured boot, firmware updates, onboarding, remote attestation. All works from private keys provisioned in factory, and public keys being provisioned. Want this on RIOT independent of whether or not secure element is available. (There’s always a secure element, sometimes it’s just the whole module.) Thus, should reference private keys by reference and not value, but also load them in such a way they persist across flashes / firmware upgrades etc. I’ve noticed if people don’t use security regularly it becomes “security last”, and it stays off. Lena has done awesome job with PSA API, should accept it and go a couple steps further with it. All crypto users should use that, want cipher modules disappear. This might also simplify things.
(MCR: Also have second half, but let’s go ahead)
Lena: PR is pusehd since Friday, some more to do. Ciphers, hashes and ECs are in. […] and also nRF hardware accelerator is available, and one secure element (partially). PSA has integrated key management, identifier-based.
chrysn: Conversion APIs? Lena: Weierstrass and Montgomery are both supported, not sure about the conversion. Göran: We’re using the same keys for static-static derivation and signature. With EdDSA, these use different representations. Lena: Could store them independently. chrysn: So there’s a way; thanks, so it works by storing to keys. MCR: I understood it works even when the hardware does convert, so even better – provided the hardware can do the conversion.
MCR: For with no secure element, we need to access the secret keys to persist them.
Lena: PSA also has specs for secure storage API. Maybe look at that?
Koen: Think MCR is talking about nitty-gritty flash reservation stuff.
MCR: Yes. Describe where in flash things are, and tools we use for flashing need to work with that. Fork or upstream …, but need to mess with that.
chrysn: What does the PSA storage API need of the nitty-gritty details? Just store keys, or also signature counters / other counters?
MCR: CFG page (making EEPROM? out of interface?), but make that storing cheap. Carsten tells me, choice of CBOR indefinite map is coincidental.
Koen: There are some that erase to 0.
chrysn: It’s more complex; let’s not try not to solve it here.
Koen: back to PSA. What’s experience around porting things to PSA? Lot of code? Lena: Depends. For one module, just had to convert some drives. For hardware driver, it was more. MCR: Somewhere I saw switch statement mapping types. Lena: Design decision, so we can combine multiple backends, and different algorithms wind up in different ones. MCR: Micro-optimization, can we just make them all the same value? Koen: Yes it’s a micro-optimization.
Koen: I think we can deprecate the rest.
MCR: Do we have anything that is not crypto-agile?
chrysn: These could still go to PSA.
MCR: Where it is happening, would we inadvertently pull in a bigger chunk of code that would have been acceptable?
Koen: Maybe FIDO. MCR: That should be agile.
MCR: What’d be the impact of having at least one verification method around?
Koen: Signature would suck.
Minimal for OTA update? A hash?
Koen: If we want to go non-standard crypto way, libhydrogen is an option.
chrysn: Is per-device encrypted manifests an option? That way, asymmetric would not be necesary any more.
MCR: I’s not 2010 any more.
chrysn: We’re talking about the options we have for devices that can’t afford generic asymmetric algorithms, so…
michel: want to make sure that the decision for PSA is no lock-in to hardware manufacturers features
Koen: Write down requirements from this meeting. Plan a meeting 1month from now.
Check ARM PSA secure key storage API
?: Align with IETF hackathon in November(?)?
?: Key storage is big topic … key manager??
Thomas: Asymmetric crypto is the narrow waist here …?