4 ms·
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 s
by matthewaveryusa 3y ago
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.
- deathanatos 3y agoWhat 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.
- matthewaveryusa 3y agoWhat 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 https://www.w3.org/TR/webauthn-2/#client-platform