danielinux
Security of multiple keys?
Some questions now I've played with the source a little
If multiple keys were constructed from one certificate (via mkcert.sh) and one was stolen would this not potentially compromise the remaining keys?
Similar question if a uf2 was released for general use (probably a lot worse)
In the first case wouldn't the use of a pico2 with encryption be safe regardless of the loss of one?
Would a fido2 version be possible / preferable ?
Hi @peardox, The certificate is only used as proof of origin (i.e. manufacturer), and does not contain any secret. The only secret on the device is the 'master key' that's created on first run, and it's used to derive the keys for each server. Losing one device with the cert will not compromise the secret of the second device.
The attack surface on a rp2040 is: if you lose possession of the device, even temporarily, an attacker may dump the flash and easily steal the master key. (Reason why I don't like to expose the bootsel button by default, it makes this attack much easier and less detectable than wrapping the board in PLA and leaving a user button exposed).
The above attack could be mitigated by storing the master key in a secure vault. I do have a prototype using rp2040 and an external vault, e.g. I was looking into integrating this chip.
Securing the key would prevent the flash dump attack, but clearly the device can still be used to perform authentication when stolen, so it must be revoked the moment you cannot locate it. This is a known issue even with the expensive commercial fido keys.
I do have a rp2350 and I'm planning to add secure boot + trustzone + move the crypto in secure mode as mitigation.
I haven't looked into FIDO 2.0 details yet, but I wish we could update the protocol at some point (would need to integrate CBOR/COSE library).
So a uf2 of a default build is actually equally safe as compiling it yourself. A default cert would therefore not an issue (and could even be supplied in the source?)
In terms of user safety then an unprotected (BOOTSEL available) would be considered 'home/hobby' safe whereby if the key went missing the key would require revocation whilst an external vault / rp2350 with trust would be considered 'professional/commercial' safe regardless of BOOTSEL.
In regard to BOOTSEL would an alternate bootloader mitigate the security issues at all?
Yes, the cert could be supplied in the source, but I thought it would be nice to customize/recreate since it's just a simple procedure.
In terms of user safety then an unprotected (BOOTSEL available) would be considered 'home/hobby' safe whereby if the key went missing the key would require revocation whilst an external vault / rp2350 with trust would be considered 'professional/commercial' safe regardless of BOOTSEL.
I have multiple fido keys registered, I can revoke one from all services using the others when it goes missing. Normally you would do that with security ~~keys~~ codes, if you only have one.
In regard to BOOTSEL would an alternate bootloader mitigate the security issues at all?
Yes, but on rp2040 this is not allowed, and connecting a debugger would still be possible. The interesting thing about rp2350 is that the boot process can be reworked to integrate secureboot and a hw-assisted TrustZone configuration can protect the private key. I still have to check if it can be protected/fused against debugging/flash reading afterwards, but I would expect so looking at the device.
Yes, the cert could be supplied in the source, but I thought it would be nice to customize/recreate since it's just a simple procedure.
Well, particularly if you were using Windows as a dev host then having the default key would simplify things greatly (converting it to VSCode ATM - I admit I can't abide the IDE though)
IMHO having a default which would be overriden by mkcert would be an improvement
Yes, but on rp2040 this is not allowed,...
There are numerous alternative bootloaders for RP2040
IMHO having a default which would be overriden by mkcert would be an improvement
Feel free to submit a PR in that sense
There are numerous alternative bootloaders for RP2040
For later stages, yes, but you cannot replace the ROM bootcode at 0x00000000, and AFAIK there is no way to protect the flash against readout or avoiding to boot a custom firmware, overwriting your second stage and reading out the key partition
More suitable to this issue...
https://arstechnica.com/security/2024/09/yubikeys-are-vulnerable-to-cloning-attacks-thanks-to-newly-discovered-side-channel/