We have been discussing this for quite a long time. You think that the curves are rather safe, I think that they are rather dangerous.
But why don’t developers extend the scope of their solution by adding a private key for each registered service? Nothing bad will happen?
Here is how to generate a key pair for NIST-P 256:
let mut seed = [0u8; 32];
seed.copy_from_slice(syscall!(self.trussed.random_bytes(32)).bytes.as_slice());
let keypair = nisty::Keypair::generate_patiently(&seed);
So let’s call this generation several times. One such key occupies 32 bytes, the processor used in Nitrokey3 has 640 KB of flash memory, this should be enough for several such keys.
As far as I understand, during authorization, the site transfers its data to the device, for example, the name of the site. You can store name-key pairs on the device and simply find the necessary pair during authorization. The Nitrokey 3 has 2 MB GD25Q16CEIGR memory, which should be enough for a large number of such pairs. Also, this is not the largest memory in the manufacturer’s line and can be easily increased at least twice.
What you describe is called resident keys and it is part of Webauthn. The keys are generated based on the device key and a shared secret negotiated between the token and webserver.
The server decides on how the authentication should happen. Using resident keys, the token stores them. In regular mode, the server stores the parameters required to recreate the same key with data added only known by the token.
This is what worries me. Keys to different services are generated using the device key, that is, they are linked. If somebody manage to restore the secret key of the token using one of the authorizations, then you can find out everything about the person using this secret key. But if the keys are not linked, that is, a new device secret key is generated with each authorization, this will not work.
For example, I register on the site: NSA-keep-your-privacy-safe.com. An NSA corporal, knowing the secret information and using the backdoor of NISP curves, finds out the secret key of my token. If the token has only one secret key, it knows everything, if there are several, then not everything.
When a user uses Webauthn, initially the token generates an anonymous ephemeral key pair for ECDHE (Elliptic Curve Diffie-Hellman Key Exchange) and exchanges it with the site to agree on a shared secret. That shared secret is used to derive a public/private key pair.
The private key generated by the token is only used for signing nonces during authentication. Even if the curve used for ECDHE is weak, it would require lots of signatures to break the private key (otherwise it would not be a backdoor but a mathematical miracle endangering all ECC).
User presence is required for this, so a website cannot request hundreds of requests without the user knowing it. This means that if someone were to try to break the private key by watching the exchanged data, they would need to capture a large number of signatures.
That also means, that removing the token as second factor and registering it again, resets this effort and a rotation would help to mitigate against that.
Now lets assume a breach.
If the private key is breached, the device key would still be secure. The protocols used in Webauthn don’t use the device key directly, and the other party does not interact with it. The link to the device key is protected by key derivation and the introduction of either a nonce or a shared secret gathered by ephemeral keys.
