This raises a question for me. Why are hardware keys so limited in storage? How much extra would it cost to have a secure processor that could access a mass storage device also built in to the key. This mass storage device would of course be strongly encrypted by the secure processor with a key that would be erased at the same time everything else is erased.
Because secure tamper resistend storage is expensive.
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 setting up (in a way you are very unlikely to detect if done well)
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
> Because secure tamper resistend storage is expensive
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.
I think this is a conscious design choice made to keep these devices as "dumb" as possible. As soon as you add storage, you start opening up the same surface for vulnerabilities as any other storage device, next comes compute and eventually you have a full fledged computer instead of a dumb yubikey.
I'm sure they can go up in storage, but the more you add to them the more you increase the chances of fault. And these things currently take a hell of a beating before they don't work anymore.
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.
It's less that they are limited in memory, and more so that they are designed to not have memory limits.
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.
What you're talking about seems to be what the article would call a "non-resident" key, whereas this commenter is specifically asking about "resident" keys.
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.
What I'm saying is if you look at the sequence diagram for the resident key, at step 3 there's no requirement to have the keys stored in the security key: you can save an Rp to token mapping in the client outside and it's still considered a resident key.
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
Maybe even make it modular. Sell something that looks like a thumb drive but has a slot in the back that you can plug a small security key into (think something with a form factor like a YubiKey Nano).
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.
I don't know if this is the only reason, but mass storage devices seem to have a ludicrously unacceptably high failure rate and short lifetime to be something I key large potions of my life to.
Usb drives have ludicrously high failure rates because they're optimized for cost rather than reliability. Other forms of flash memory (eg SSDs) are quite reliable, despite having much more flash chips (and thus points of failure).
Mass storage for resident keys would not need to be written to often. Just when you create an account at a new site. I'd guess that would greatly lower the failure rate.
