Skip to content

Bitwarden passkey vault encryption (PRF): "Error reading passkey" on the follow-up PRF read #109

Open
Open
Bitwarden passkey vault encryption (PRF): "Error reading passkey" on the follow-up PRF read#109
Labels
bugSomething isn't working

Description

@Alximik501
Alximik501
opened on Sep 6, 2026

Before filing

  • I searched the existing issues and this is not a duplicate.
  • This is not an exploitable security bug (those go to a private advisory, not here).
  • I can still reproduce it on current main.

Area

FIDO2 / U2F / passkeys / ssh-sk

Firmware build

v0.4.10 (81d8c8cb), VIDPID=Yubikey5 build (0x1050:0x0407, YubiKey 5.7.4-compatible identity) — also reproduced on the v0.4.5-era build, so not a recent regression.

Board

Waveshare RP2350-One (no display), flashed via BOOTSEL drag-and-drop.

Host environment

Windows 10 desktop, Chrome and Edge (both Chromium), Bitwarden web vault. FIDO PIN is set on the key.

What happened

Bitwarden "Log in with passkey" → register a new passkey with the "Use for vault encryption" checkbox (WebAuthn PRF). The passkey is created successfully (makeCredential with hmac-secret-mc/PRF appears to work — the "Passkey successfully created" dialog appears and the credential is stored on the key, visible in ykman fido credentials list), but then Bitwarden performs its follow-up read of the PRF key (a second user-verification prompt, as documented: "we request an assertion from the authenticator, which will provide the key") and fails with:

Error reading passkey. Try again or uncheck this option. / Ошибка чтения passkey. Попробуйте еще раз или снимите флажок с этой опции.
Same failure in Chrome and Edge, same on v0.4.5-era firmware and v0.4.10. Unchecking "Use for vault encryption" lets the passkey register fine (plain login passkey works).

Steps to reproduce

  1. vault.bitwarden.com (web vault) → Settings → Security → Master password → "Log in with passkey" → register new passkey with a hardware key.
  2. Leave "Use for vault encryption" checked (it appears because the key advertises hmac-secret / PRF capability).
  3. Complete the first user-verification prompt (PIN + touch) — passkey is created and named.
  4. Bitwarden immediately issues a second prompt (PIN again) to read the PRF output.
  5. After the second PIN, the dialog shows "Error reading passkey" and refuses to save the credential for encryption.

Expected vs actual

Expected: PRF output read succeeds, passkey saved with vault-encryption enabled (this works with a genuine YubiKey 5).
Actual: the second (read) WebAuthn ceremony fails after user verification; the passkey is left on the key but Bitwarden cannot use it for decryption.

Notes / hypothesis

  • authenticatorGetInfo advertises hmac-secret and hmac-secret-mc; registration-time hmac-secret evaluation succeeds.
  • The failure is on the follow-up assertion carrying the PRF/hmac-secret request — possibly a difference in how Chrome/Windows drives the second ceremony (salt count/length, saltAuth size, or UV-flag handling between makeCredential-mc and getAssertion) versus what a real YubiKey answers.
  • Happy to run any diagnostic build or provide logs; the key is a spare test unit.

Output / logs



Anything else


No response
Activity
  1. Alximik501
    added 
    bugSomething isn't working
     on Sep 6, 2026
  2. TheMaxMur
    added a commit that references this issue on Sep 8, 2026
    fido: the PRF value registration returns and the one an assertion rea…
    02a2bd8
  3. TheMaxMur commented on Sep 8, 2026 
    @TheMaxMur
    TheMaxMur
    on Sep 8, 2026
    Owner
    Hey, can you build firmware from develop branch and test?
  4. Alximik501 commented on Sep 9, 2026 
    @Alximik501
    Alximik501
    on Sep 9, 2026
    Author
    Tested on the develop build (flashed 0x1050:0x0407 on RP2350-One, Windows 11, Chrome + Edge):
    

    The bug still reproduces on real hardware. makeCredential with hmac-secret-mc succeeds — the passkey is created and stored and the "Passkey successfully created" dialog appears — but the follow-up assertion that Bitwarden issues to read the PRF key (a second user-verification prompt, the PIN prompt appears again) fails, and Bitwarden shows "Error reading passkey. Try again or uncheck this option."
    

    So the registration-time hmac-secret-mc value and the read-back assertion value do NOT agree in this Chrome/Windows→key path, even though the new conformance cases pass in CI. The difference must be in what this specific client stack sends for the read ceremony (salt layout, UV handling, or something on the Windows WebAuthn bridge). I can run any diagnostic build or provide USB logs if helpful.
    
Image
  5. Alximik501 commented on Sep 9, 2026 
    @Alximik501
    Alximik501
    on Sep 9, 2026 via email
    Author
  6. TheMaxMur commented on Sep 11, 2026 
    @TheMaxMur
    TheMaxMur
    on Sep 11, 2026
    Owner
    Hi, I ordered a YubiKey with firmware version 5.8.0, it supports PRF, and I’ll take a closer look at your issue this weekend.
  7. TheMaxMur
    added 4 commits that reference this issue on Sep 15, 2026
    fix(fido): up:false + hmac-secret answered UNSUPPORTED_OPTION, the re…
    b8e5c7c
    fix(fido): a degenerate hmac-secret value ended the ceremony instead …
    68ad6fd
    fix(fido): an hmac-secret value of the wrong CBOR type was ignored, n…
    51895bd
    changelog: 0.4.11 is still being made, so the unreleased entries belo…
    9f60fe1
  8. TheMaxMur commented on Sep 15, 2026 
    @TheMaxMur
    TheMaxMur
    on Sep 15, 2026
    Owner
    Hey, can you build firmware from develop branch and test?
  9. Alximik501 commented on Sep 16, 2026 
    @Alximik501
    Alximik501
    on Sep 16, 2026
    Author
    Confirmed — the bug is not in the firmware, it's a Windows 10 limitation.
    

    On this same RS-Key (develop build) and the same Chrome/Edge versions, the exact same registration flow works first try on Windows 11: passkey created with "Use for vault encryption" checked, no error, vault unlocked by the key.
    

    On Windows 10 (build 19045), every browser fails at the follow-up PRF read. The WebAuthn PRF extension needs the Windows WebAuthn API's WEBAUTHN_API_VERSION_8 / hmac-secret support, which only ships with Windows 11 25H2 + the Feb 2026 cumulative update (KB5077181). Windows 10 has none of it — Chrome 153 and Edge 153 on Win10 cannot carry the PRF read either way, regardless of what the authenticator answers.
    

    So this is a client-OS gap, not an RS-Key defect. The key, firmware v0.4.10/develop with hmac-secret + hmac-secret-mc, works correctly with a PRF-capable platform. Thanks for the help — and it was a useful exercise: your new conformance case covering the registration-vs-read PRF equality is good to have either way.
    

    Closing note for anyone else: vault-encryption passkeys on RS-Key need Windows 11 25H2+, macOS 15+, or Android/Chrome.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Metadata
Assignees
No one assigned
    Labels
    bugSomething isn't working
    Projects
    No projects
      Milestone
      No milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions