AuthenticatorReset "confusion" on devices with "dependant storage"

[My1]

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.

https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#authenticatorReset

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]

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 fido-dev+u...@fidoalliance.org.
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]

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.