I would even go as far and say from a security POV the best security key is the key which has 0 storage. Because in my experience any protocol which injects and stores a secure token into a security key/enclave/whatever instead of deriving it from shared secrets etc. has serious flaws. Sometimes it's fundamentally security flaws (like TOTP). Sometimes it's complexity flaws. Similar you don't really EVER want to share a secure key for HSK/2FA across multiple devices. It means if one device leaks it it's corrupted for all of them. Instead you want a separate key (oversimplified) on _each_ device. Login provider/server side wise the overhead for this is negligible in the bigger picture.
it's prone to MITM attacks when being used (in a way you are very unlikely to detect if done well)
it's MITM attack vectors are not just usable with "on the wire" MITM but can be archived with social engineering making them IMHO pretty bad
it's also prone to certain kinds of brute-force attacks in certain situations and protecting against them without making your login trivially DDOSable is very very hard
from a security POV it's better then SMS but still a pretty bad design
The storage for resident keys would not need to be tamper proof. All that needs to be tamper proof is the processor that operates on unencrypted sensitive data and the storage for the private keys of the device.
The resident keys would be encrypted using a device private key before being saved to mass storage.
There is also something a bit more auditable about a smaller storage. Though, even the small sizes are probably pushing the bounds of what can realistically be audited nowadays.
If you look at TPMs, basically each time you want to sign something, your input is the data you want to sign and a sealed private key. The sealed key is the private key that was generated by the TPM and then symmetrically encrypted with the key embedded in the TPM. You store the sealed key in your mass storage, and provide it to the TPM for each signing operation. This design allows you to have as many keys as your mass storage will allow you to save.
Or, if you think you are describing resident keys, then you need to reconcile,
> This design allows you to have as many keys as your mass storage will allow you to save.
with the OP: the article states that to be roughly "20", and people tend to have more than 20 logins, and that is the reason the person you're responding to is asking the question they're asking.
I think what I'm saying here is that resident means resident to the client, not necessarily resident to the enclave. I took a peek at the spec and they define resident keys as being part of the "client platform" which they take care to clarify as "A single hardware device MAY be part of multiple distinct client platforms" https://www.w3.org/TR/webauthn-2/#client-platform
When a security key is plugged into the slot the thumb drive provides storage for the security key and appears to the computer as a security key.
When a security key is not plugged into the slot the thumb drive functions as an ordinary thumb drive.
You would ordinarily keep the security key plugged into the slot, but if you ever decided you needed more storage you could by a bigger storage module, remove the security key from your old storage module, plug the old module into the computer, copy the encrypted files, plug in the new module, copy the files to it, then plug in the security key.