AuthenticatorReset "confusion" on devices with "dependant storage"
285 views
Skip to first unread message
My1
May 11, 2025, 4:26:15 AMMay 11
to FIDO Dev (fido-dev)
So there are a few devices where the FIDO2-related storage, notably the "master key" for non-resident credentials is not independent but rather dependent of something else stored on the device (including being part of a functional backup of these devices), primarily this consists of cryptocoin wallets like Ledger with FIDO2 functionality being more like an addon than the main part of the device.
Despite the fact that at the very least the Ledger has a FIDO2-L1 certification according to the certified products list, there is no way this device does or even could implement authenticatorReset as written in the specs.
This is kinda a problem as it causes confusion for clients which might think that a reset properly occurred, but actually did not.
I would propose to:
1) add a carveout to the "MUST support" section for devices which have internal UI or other management options, especially those with dependant storage.
2) define an error code for the situation where the device cannot facilitate a reset over CTAP to tell the user to reset on the device or check the manual/documentation of the manufacturer for reset instruction.
This would help devices to not break the spec just based on how they deal with FIDO.
DUBOUCHER Thomas
May 11, 2025, 2:51:54 PMMay 11
to My1, FIDO Dev (fido-dev)
THALES GROUP LIMITED DISTRIBUTION to email recipients
Hi My1,
We’ll need more details on this topic. What you describe, as I understand, :
- allows re-identification
- contradicts the FIDO Privacy Principle that vendors have to sign during certification
- would not pass the security review event at L1
- would not pass Authr-Reset-1/P-1 of the compliance test suite
Best regards,
|
|
|
|
|
Thomas Duboucher (he/him) |
|
Embedded Security Specialist |
|
Digital Identity and Security Thales |
|
|
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[email protected].
To view this discussion visit
https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNpX3u_rKyOtg0z%2BjJaPbqfS-eZpxdk_sLpvOk_Rw7%3DJyg%40mail.gmail.com.
My1
May 11, 2025, 3:27:38 PMMay 11
to DUBOUCHER Thomas, FIDO Dev (fido-dev)
I do not know any specifics about the things vendors have to sign, the security review event or the compliance suite, but yes it allows re-identification unless you reset and setup the device anew based on the device's primary use case (usually cryptocoins).
Long story told short. When setting up eg a Ledger you get a backup phrase which gets calculated into keys for all sorts of things as a backup if the device breaks down, which can be imported into a new device to restore most things.
These keys include the master secret for non-resident keys
So to reset you would have to go into the settings on the device, reset it and either import a different backup phrase or create a new one in the setup process.
With the way this device is designed to act I do not consider this particularly of an issue in itself, but it does go against the "word of the law", one could say.
Especially as earlier revisions were a lot more ambiguous about the command (but still never stated anything about a potential technical contradiction between a device's individual functionalities.
The way this is designed it could not even go with what is needed for an authenticator reset if the device wanted to, due to a new device with the same backup phrase not being aware that such an event even happened, unless it unless it decpupled the fido master key stuff from the backup, which I would not consider the greatest solution either.
I have not tested any devices besides the ledger Nano S for this, as it's the only i have that i am aware to be listed in the certified products list.
All devices i am aware of with this specific technical setup tho do have a display and are generally updateable, so especially for certified ones, the devices could be updated to act by
1) throwing not allowed or operation denied
2) at the same time show something about the reset on the display
While at the same time opening up something for eg ctap2.3 for such devices to respond with a more proper error code and eg an info link to eg reset instructions for the whole device.
My1
Jun 30, 2025, 12:26:04 PMJun 30
to DUBOUCHER Thomas, FIDO Dev (fido-dev)
I'll rip this open again as I recently found another slightly more prominent case of a FIDO2-device not implementing FIDO2 reset, specifically the Yubikey Bio Multi-Protocol Edition.
While not widely available yet as it is enterprise only for now, Yubico is basically the headrunner for FIDO2, and I am honestly quite curious on how they passed FIDO certification and all with this flaw, especially as those cannot even be updated or anything to tell you something more specific, on how you should actually reset them.
while their idea to keep the things connected and not allow a reset TOO easily is commendable, I think the FIDO spec might wanna add something to give users guidance for a proper reset.
My1
Jul 1, 2025, 3:41:20 PMJul 1
to John Bradley, FIDO Dev (fido-dev), DUBOUCHER Thomas
might it make sense to add a response field which can be populated with e.g. a URL or something so the user knows what to look for if CTAP reset is disabled entirely and the device doesnt have a screen?
Am Di., 1. Juli 2025 um 21:25 Uhr schrieb John Bradley <[email protected]>:
Interesting question.On the topic of the Yubikey Bio Multioprotocol, those are subscryption only devices where Enterprises ordering them are made aware of the diffrences between these and the regular 5 series.The keys do support the authenticatorReset (0x07) as expected when only configured with Fido credentials.If the user or admin provisions a PIV certificate on the device, it then returns CTAP2_ERR_OPERATION_DENIED until all the PIV card slots are empty.
At that point, the PIV configuration software or Yubico Authenticator are the only things that can reset it using CCID commands.
I will try to attach a screenshot of the warning.In CTAP2.1 we made reset over some transports optional. That had the side effect of making the command required on at least one.At the time, I was not thinking about devices that had their own UX, and the ones in the working group did not mention it.In principle I would agree that a user, through some action, should be able to disable resetting from the 0x07 command if they have another way to reset.
For a device with a display, I would hope some dialogue could be displayed on device before returning sucess or denied.
For non-display devices, perhaps a new error saying a vendor tool or local UX needs to be used. Perhaps CTAP2_ERR_OPERATION_DISABELED might be enough.Those could be added to CTAP2.3. I can look at doing a pull request.Backing up the authenticator state/ master secret is a separate issue. I think that could be allowed for certification if the credentials are marked as Backup Eligible/ Backed up.Both of those should go to the Fido2 TWGOn a side note, it would be nice if managing security keys was supported on more platforms and not deeply hidden from users, on the platforms it is supported.I suspect that most users use a vendor tool to do a reset because they can't find it in the browser or platform.John B.
My1
Jul 1, 2025, 3:46:52 PMJul 1
to John Bradley, Dev FIDO, Thomas DUBOUCHER
Oh, thats a thing already? sry didnt know that.
On Tue, 1 Jul 2025, 22:44 John Bradley, <[email protected]> wrote:
That could go in getInfo. Like the link for the pin complexity explanation.
My1
Jul 2, 2025, 1:32:28 AMJul 2
to John Bradley, FIDO Dev (fido-dev), DUBOUCHER Thomas
> Backing up the authenticator state/ master secret is a separate issue. I think that could be allowed for certification if the credentials are marked as Backup Eligible/ Backed up.
absolutely, my key point is not the backup, but rather the point that the master secret for non-resident credentials literally cannot be deleted off the device as it is mathematically derived from a higher master secret on the device and that currently the fun part is that these devices at best nuke any resident credentials if enabled, but otherwise have behavior that does not exactly make sense, as in throwing a success despite it clearly not having erased a major part.
and yeah the suggestion to plonk a URL into getInfo and (if available) show stuff on screen is a useful approach.
> I can look at doing a pull request
Is there a way to look at these from the outside or is that members-only?
Am Di., 1. Juli 2025 um 21:25 Uhr schrieb John Bradley <[email protected]>:
Interesting question.On the topic of the Yubikey Bio Multioprotocol, those are subscryption only devices where Enterprises ordering them are made aware of the diffrences between these and the regular 5 series.The keys do support the authenticatorReset (0x07) as expected when only configured with Fido credentials.If the user or admin provisions a PIV certificate on the device, it then returns CTAP2_ERR_OPERATION_DENIED until all the PIV card slots are empty.
At that point, the PIV configuration software or Yubico Authenticator are the only things that can reset it using CCID commands.
I will try to attach a screenshot of the warning.In CTAP2.1 we made reset over some transports optional. That had the side effect of making the command required on at least one.At the time, I was not thinking about devices that had their own UX, and the ones in the working group did not mention it.In principle I would agree that a user, through some action, should be able to disable resetting from the 0x07 command if they have another way to reset.
For a device with a display, I would hope some dialogue could be displayed on device before returning sucess or denied.
For non-display devices, perhaps a new error saying a vendor tool or local UX needs to be used. Perhaps CTAP2_ERR_OPERATION_DISABELED might be enough.Those could be added to CTAP2.3. I can look at doing a pull request.Backing up the authenticator state/ master secret is a separate issue. I think that could be allowed for certification if the credentials are marked as Backup Eligible/ Backed up.Both of those should go to the Fido2 TWGOn a side note, it would be nice if managing security keys was supported on more platforms and not deeply hidden from users, on the platforms it is supported.I suspect that most users use a vendor tool to do a reset because they can't find it in the browser or platform.John B.
On Monday, June 30, 2025 at 10:26:04 AM UTC-7 My1 wrote:
John Bradley
Jul 2, 2025, 2:43:42 AMJul 2
to FIDO Dev (fido-dev), My1, FIDO Dev (fido-dev), DUBOUCHER Thomas
Interesting question.
On the topic of the Yubikey Bio Multioprotocol, those are subscryption only devices where Enterprises ordering them are made aware of the diffrences between these and the regular 5 series.
The keys do support the authenticatorReset (0x07) as expected when only configured with Fido credentials.
If the user or admin provisions a PIV certificate on the device, it then returns CTAP2_ERR_OPERATION_DENIED until all the PIV card slots are empty.
At that point, the PIV configuration software or Yubico Authenticator are the only things that can reset it using CCID commands.
I will try to attach a screenshot of the warning.
At that point, the PIV configuration software or Yubico Authenticator are the only things that can reset it using CCID commands.
I will try to attach a screenshot of the warning.
In CTAP2.1 we made reset over some transports optional. That had the side effect of making the command required on at least one.
At the time, I was not thinking about devices that had their own UX, and the ones in the working group did not mention it.
In principle I would agree that a user, through some action, should be able to disable resetting from the 0x07 command if they have another way to reset.
For a device with a display, I would hope some dialogue could be displayed on device before returning sucess or denied.
For non-display devices, perhaps a new error saying a vendor tool or local UX needs to be used. Perhaps CTAP2_ERR_OPERATION_DISABELED might be enough.
For a device with a display, I would hope some dialogue could be displayed on device before returning sucess or denied.
For non-display devices, perhaps a new error saying a vendor tool or local UX needs to be used. Perhaps CTAP2_ERR_OPERATION_DISABELED might be enough.
Those could be added to CTAP2.3. I can look at doing a pull request.
Backing up the authenticator state/ master secret is a separate issue. I think that could be allowed for certification if the credentials are marked as Backup Eligible/ Backed up.
Both of those should go to the Fido2 TWG
On a side note, it would be nice if managing security keys was supported on more platforms and not deeply hidden from users, on the platforms it is supported.
I suspect that most users use a vendor tool to do a reset because they can't find it in the browser or platform.
John B.
On Monday, June 30, 2025 at 10:26:04 AM UTC-7 My1 wrote:
John Bradley
Jul 2, 2025, 2:43:51 AMJul 2
to My1, Dev FIDO, Thomas DUBOUCHER
That could go in getInfo. Like the link for the pin complexity explanation.
Mumbere Anold
Jul 2, 2025, 2:44:18 AMJul 2
to My1, John Bradley, Dev FIDO, Thomas DUBOUCHER
Good morning here
Reply all
Reply to author
Forward
0 new messages