You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On the web manual in blob/2.1/docs/customization.md, it says:
'Usually, the attestation private key is shared between a batch of at least 100,000 security keys of the same model. If you build your own OpenSK, your private key is unique to you. This makes you identifiable across registrations: Two websites could collaborate to track if registrations were attested with the same key material. If you use OpenSK beyond experimentation, please consider carefully if you want to take this privacy risk.'
But I searched the web of FIDO, it says:
'Each device/website pairing requires separate registration and a separate cryptographic key pair. Once registered, a user can easily authenticate to multiple sites from the same device, yet each site has no knowledge of the user interactions with other sites. FIDO does not introduce any new tracking mechanism that could be used to correlate user activity online.'
I'm very confused on the privacy issue explained in OpenSK, could anyone explain it ? Does a single key pair is used across different users and different sites ?
The text was updated successfully, but these errors were encountered:
Your FIDO quote is referring to assertion, the act of proving to the website that your are the same user that registered.
The text in customization refers to attestation, the act of proving to the website that the device you use is what you claim it is. In the case of OpenSK, such proof is impossible right now. Since OpenSK is not a locked down and registered hardware authenticator, you can always pretend to run on hardware and emulate it, or extract the assertion keys.
However, some relying parties only work if you enable attestation, and send them some batch attestation. Therefore, we let users choose if they want to enable it. We have discussed some privacy preserving ways to implement fake batch attestation in #649 , but I haven't implemented any of them yet.
Thanks for your explanation.
I want to confirm that if batch attestation is the only kind of attestation? Does ant other attestation mode exist?
I do not enable this feature, so no privacy issue exist in the prospective of public key tracking?
Correct, without batch attestation, there is no privacy issue.
There are a few attestation modes [1], and we support 3 of them:
Basic Attestation: We call it batch attestation here. Discussed above.
Self Attestation: This is the standard if batch attestation is disabled. Doesn't really attest anything, and not privacy issue.
Enterprise Attestation: This mode does allow tracking individual users by design, intended for coorporate settings. An organization using OpenSK for their own security keys can enable and implement it as a customization. Not recommended for users otherwise.
On the web manual in blob/2.1/docs/customization.md, it says:
'Usually, the attestation private key is shared between a batch of at least 100,000 security keys of the same model. If you build your own OpenSK, your private key is unique to you. This makes you identifiable across registrations: Two websites could collaborate to track if registrations were attested with the same key material. If you use OpenSK beyond experimentation, please consider carefully if you want to take this privacy risk.'
But I searched the web of FIDO, it says:
'Each device/website pairing requires separate registration and a separate cryptographic key pair. Once registered, a user can easily authenticate to multiple sites from the same device, yet each site has no knowledge of the user interactions with other sites. FIDO does not introduce any new tracking mechanism that could be used to correlate user activity online.'
I'm very confused on the privacy issue explained in OpenSK, could anyone explain it ? Does a single key pair is used across different users and different sites ?
The text was updated successfully, but these errors were encountered: