dearsky/pico-fido
1
0
Fork 0
Code Issues 46 Pull Requests 1 Actions Packages Projects Releases 22 Wiki Activity

Authentication Fails When User Verification Is Set to Discouraged in webauthn.io #113

New Issue
Closed
opened 2025-02-23 22:18:57 +08:00 by jcodeth · 4 comments
jcodeth commented 2025-02-23 22:18:57 +08:00 (Migrated from github.com)
Copy Link

Description

Authentication may fail when the Authentication setting is set to User Verification = Discouraged in webauthn.io.
The issue appears to be caused by the PIN not being requested during the authentication ceremony, resulting in an inability to decrypt the master key.

Environment

  • Operating System: Windows 10
  • Firmware Version: pico_fido_waveshare_rp2040_zero-6.4.uf2
  • Browser: Chrome 133.0.6943.127(Official Build)

Steps to reproduce:

  1. Insert a FIDO2 USB key that has a PIN configured.
  2. visit https://webauthn.io/
  3. Enter a username.
  4. Correction: Register a new credential with the following advanced settings:
    Attachment = Cross-Platform
    →Register a new credential with the following advanced settings:
    Attachment = Cross-Platform
    Discoverable Credential = Discouraged
  5. Enter the FIDO2 USB key pin and complete the registration ceremony.
  6. Authentication with the following advanced settings:
    User Verification = Discouraged
  7. Reinsert the FIDO2 USB key.
  8. Complete the authentication ceremony.

Expected Behavior

WebAuthn authentication should succeed without requiring PIN input when User Verification = Discouraged.

Actual Behavior

WebAuthn authentication fails with the following error message:

    "This security key doesn't look familiar. Please try a different one."

Additional Context

When User Verification is set to Discouraged, the PIN is not requested during authentication, leaving session_pin[32] empty. As a result, the load_mkek() function fails to decrypt the master key encryption key (MKEK).
If the FIDO2 USB key is reinserted and the PIN is manually specified using a command-line tool (e.g., picofido-tool.py -p xxxxxxxx memory), authentication will succeed even with User Verification = Discouraged.

## Description Authentication may fail when the Authentication setting is set to User Verification = Discouraged in webauthn.io. The issue appears to be caused by the PIN not being requested during the authentication ceremony, resulting in an inability to decrypt the master key. ## Environment - Operating System: Windows 10 - Firmware Version: pico_fido_waveshare_rp2040_zero-6.4.uf2 - Browser: Chrome 133.0.6943.127(Official Build) ## Steps to reproduce: 1. Insert a FIDO2 USB key that has a PIN configured. 2. visit https://webauthn.io/ 3. Enter a username. 4. Correction: ~~Register a new credential with the following advanced settings: Attachment = Cross-Platform~~ →Register a new credential with the following advanced settings: Attachment = Cross-Platform <ins>Discoverable Credential = Discouraged</ins> 5. Enter the FIDO2 USB key pin and complete the registration ceremony. 6. Authentication with the following advanced settings: <ins>User Verification = Discouraged</ins> 7. <ins>**Reinsert the FIDO2 USB key.**</ins> 8. Complete the authentication ceremony. ## Expected Behavior WebAuthn authentication should succeed without requiring PIN input when User Verification = Discouraged. ## Actual Behavior WebAuthn authentication fails with the following error message: &nbsp;   "This security key doesn't look familiar. Please try a different one." ## Additional Context When User Verification is set to Discouraged, the PIN is not requested during authentication, leaving session_pin[32] empty. As a result, the load_mkek() function fails to decrypt the master key encryption key (MKEK). If the FIDO2 USB key is reinserted and the PIN is manually specified using a command-line tool (e.g., picofido-tool.py -p xxxxxxxx memory), authentication will succeed even with User Verification = Discouraged.
polhenarejos commented 2025-02-24 05:03:25 +08:00 (Migrated from github.com)
Copy Link

In v6.4 I introduced silent authentication, which is used to identify credentials generated by a specific key. I fixed this message (3807e239) to identify correctly however it does not recognize the bogus signature.
For silent authentication, no real signature is performed, as the real private key cannot be loaded due to the missing PIN, and thus a bogus signature is returned. After a credential is checked against the legit passkey, a full assertion with PIN should be used. I don't think Pico Fido will ever be capable of doing discouraged user verification.

BTW, which is the use case where you need discouraged user verification in contrast to preferred or required?

In v6.4 I introduced silent authentication, which is used to identify credentials generated by a specific key. I fixed this message (3807e239) to identify correctly however it does not recognize the bogus signature. For silent authentication, no real signature is performed, as the real private key cannot be loaded due to the missing PIN, and thus a bogus signature is returned. After a credential is checked against the legit passkey, a full assertion with PIN should be used. I don't think Pico Fido will ever be capable of doing discouraged user verification. BTW, which is the use case where you need discouraged user verification in contrast to preferred or required?
jcodeth commented 2025-02-24 09:09:26 +08:00 (Migrated from github.com)
Copy Link

For use cases, visit:
https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/User_Presence_vs_User_Verification.html

For use cases, visit: https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/User_Presence_vs_User_Verification.html
polhenarejos commented 2025-02-24 21:25:33 +08:00 (Migrated from github.com)
Copy Link

I pushed a fix but your setup is not possible due to the specs.
Webauthn considers Preferred Discoverable Credential as a resident key and sends a CredProtection policy to 2, which means that a User Verification is needed before the assertion.
The proper way to do a discouraged user verification assertion is first register the credential with Discoverable Credential to Discouraged. Then, the assertion will not require you to introduce the PIN if it has been already introduced previously. If you reboot the board, it will prompt you to introduce the PIN.

I pushed a fix but your setup is not possible due to the specs. Webauthn considers Preferred Discoverable Credential as a resident key *and* sends a CredProtection policy to 2, which means that a User Verification is needed before the assertion. The proper way to do a discouraged user verification assertion is first register the credential with Discoverable Credential to Discouraged. Then, the assertion will not require you to introduce the PIN if it has been already introduced previously. If you reboot the board, it will prompt you to introduce the PIN.
jcodeth commented 2025-02-24 22:32:10 +08:00 (Migrated from github.com)
Copy Link

The initial setup during registration was incorrect, so it is necessary to register with a non-resident key. Also, it seems that PIN input is required once after restarting the board. Thank you.

The initial setup during registration was incorrect, so it is necessary to register with a non-resident key. Also, it seems that PIN input is required once after restarting the board. Thank you.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something isn't working
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 question
Further information is requested
 wontfix
This will not be worked on
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dearsky
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dearsky/pico-fido#113
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?