René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"FIDO2 PIN permanently blocked (CTAP error: 0x32) after accessing FIDO2 credentials from a secondary hardware profile","articleBody":"### Description\n\nUsing the FIDO2 module across different hardware profiles (Primary and Secondary/Plausible Deniability profiles) causes a critical state corruption. Accessing FIDO2 data from the secondary profile permanently breaks the FIDO2 module for the primary profile, resulting in an irrecoverable PIN_BLOCKED state.\n\nIt appears the FIDO2 module state (PIN retry counters, pinTokens, or resident keys encryption) is shared globally but gets corrupted or locked to the context of the currently active hardware profile.\n\n### Environment\n\n* OnlyKey CLI v1.2.10\n* OnlyKey Firmware Version 3.0.4-prodc\n\n### Steps to Reproduce\n\n* Unlock the OnlyKey into the Primary hardware profile.\n* Set a FIDO2 Client PIN using onlykey-cli set-pin.\n* Create some FIDO2 Resident Keys (e.g., generate an SSH key using ssh-keygen -t ed25519-sk or register on a WebAuthn site).\n* Re-plug the OnlyKey and unlock it into the Secondary hardware profile (Plausible Deniability profile).\n* Run onlykey-cli credential ls. The CLI will prompt for the FIDO2 PIN. Enter the PIN that was set in step 2.\n* Re-plug the OnlyKey again and unlock it back into the Primary hardware profile.\n* Attempt to use any FIDO2 function (e.g., run onlykey-cli credential ls or try to authenticate via SSH/WebAuthn).\n\n### Expected Behavior\n\nFIDO2 Resident Keys and the FIDO2 PIN should either be completely isolated per hardware profile, OR they should be globally shared without corrupting the CTAP state when switching between profiles. Reading credentials from the secondary profile should not break the primary profile.\n\n### Actual Behavior\n\nThe FIDO2 module stops recognizing the correct FIDO2 PIN on the primary profile. Because the internal state was altered while under the secondary profile's context, the primary profile fails to validate the PIN. This quickly triggers the CTAP brute-force protection, resulting in a permanent lockout:\n\n```python\nFile \"/usr/local/lib/python3.14/site-packages/fido2/ctap2/base.py\", line 675, in send_cbor\n    raise CtapError(status)\nfido2.ctap.CtapError: CTAP error: 0x32 - PIN_BLOCKED\n```\n\nThe only workaround is a complete onlykey-cli reset, which wipes all FIDO2 credentials and SSH keys.\n\nThis issue makes the \"Plausible Deniability\" feature fundamentally incompatible with standard FIDO2 usage (like ed25519-sk SSH keys). If a user happens to trigger any FIDO2 operation while in the secondary profile, they will lose all their FIDO2 credentials on the primary profile.","author":{"url":"https://github.com/net-fall","@type":"Person","name":"net-fall"},"datePublished":"2026-02-27T06:45:23.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/83/python-onlykey/issues/83"}