Skip to content
Portada » Blog » Pico Fido Version 8

Pico Fido Version 8

Pico FIDO 8

Portable passkeys. Stronger guarantees. A much more capable authenticator.

Pico FIDO 8 is a major step forward from the v7.6 baseline. It brings authenticated passkey portability through the open-source Pico Vault workflow, broader FIDO 2.3 coverage, more resilient encrypted storage, and a much deeper validation and conformance story.

Highlights

Export and import credentials with Pico Vault

The headline feature is opt-in passkey mobility.

Pico Vault lets an authorized operator export a selected resident credential as an authenticated, opaque PKV1 package and import it onto another enrolled Pico FIDO device. This enables backup and replacement-device recovery without cloning the whole authenticator and without handing routine desktop software a plaintext private key.

  • Enrollment is protected by PIN authorization and a physical-button ceremony.
  • Vault enrollment supports certificate-backed device identity and board binding.
  • Credential metadata is exported alongside the credential because it cannot be reconstructed from the private key alone.
  • Imported credentials are kept distinct from native credentials and do not transplant or advance the destination device’s native signature counter.
  • Four authenticated encryption profiles are available: ChaCha20-Poly1305, AES-GCM, and both two-layer combinations.
  • Legacy Vault commands have been removed in favor of the consolidated flow.

Pico Vault is deliberately a gated vendor capability, not a change to ordinary WebAuthn or CTAP credential behavior. Keep the Vault key, exported packages, PIN, and enrollment material under the same care as any other recovery asset.

FIDO and WebAuthn improvements

  • FIDO 2.3 is now announced and exercised by the test suite.
  • Added or expanded coverage for `thirdPartyPayment`, `uvm`, `minPinLength`, `maxPINLength`, and related authenticator configuration behavior.
  • Added configurable PIN complexity rules that can require uppercase letters, lowercase letters, digits, symbols, or combinations of these patterns.
  • Added configurable `alwaysUv`, `makeCredUvNotRqd`, and non-resident-credential policies, with matching `getInfo` reporting.
  • Added a configurable policy to deny creation of resident/discoverable credentials when only non-resident credentials are permitted.
  • Added per-credential expiration and revocation controls: credentials can be automatically rejected after expiry or explicitly revoked.
  • Improved credential management, including RP/token binding and support for large credential sets.
  • Improved large-blob validation, integrity checking, authentication, and transfer-state cleanup.
  • Improved HID channel handling, cancellation, selection, and next-assertion behavior.

Security and reliability

Sensitive state now has clearer boundaries and stronger failure behavior.

  • Resident credentials, OATH credentials, and OTP slots use authenticated object containers with compatibility handling for existing layouts.
  • RP identifiers and OATH/OTP secrets receive stronger at-rest protection.
  • Imported credentials use a dedicated resident-container path with atomic persistence and recovery-oriented fault handling.
  • Added operation-scoped object authorization evidence and tighter filesystem publication ordering.
  • Hardened length, bounds, transport-array, CBOR, protocol, and credential-ID validation across FIDO, OATH, OTP, backup, configuration, and Vault paths.
  • PIN retry state survives power loss more reliably; failed PIN operations regenerate authorization tokens and stale authorization state expires correctly.
  • Configuration writes, backup restore, password-safe reads, and sensitive OATH operations require the appropriate authentication and physical presence.
  • Corrected reset, U2F/`alwaysUv`, credential-counter, and error-reporting edge cases.

OATH and OTP

OATH and OTP handling received both feature work and defensive hardening:

  • Encrypted storage now covers complete OTP slots and protected OATH access.
  • HOTP operations enforce touch and authorization requirements consistently.
  • HOTP verification, decrement behavior, slot swaps, access-code checks, and password-safe reads are more strictly validated.
  • OATH and OTP data now use the same authenticated container direction as the FIDO credential store.

Conformance and testing

The release includes a substantially expanded test program covering FIDO 2.3, credential management, silent authentication, metadata, HID, OATH, OTP, object containers, storage compatibility, and Pico Vault.

The recorded internal FIDO Alliance Conformance Test App run reports **251 passes and 0 failures**. Some checks were skipped by the test environment, and the result is test evidence—not FIDO Alliance certification. Certificationtill requires the separate FIDO Alliance process.

Pico Vault tests cover all four encryption profiles, malformed and tamperedackages, wrong-vault rejection, enrollment protection, credential metadata,nd live export/import round trips when an enrolled device is available.

Under the hood

  • Refreshed the bundled PicoKeys SDK with versioned filesystem envelopes, bounded authenticated object records, atomic transactions, namespace-aware handles, policy checks, separate integrity roots, and legacy-layout access for migration.
  • Expanded the shared filesystem for multi-sector files, 32-bit lengths, dynamic indexing, and cache draining, supporting larger and more resilient encrypted stores.
  • Hardened shared APDU, USB, CCID, and secure-messaging paths with stricter length checks, safe response chaining, bounded buffers, timeout handling, and safer flash publication and commit behavior.
  • Resident, OATH, and OTP data moved onto the PicoKeys SDK object-container infrastructure, including authenticated manifests, migration compatibility, and crash-safe updates.
  • Credential key derivation now uses stable resident identifiers, preserving related key material across supported operations.
  • PKV1 uses a vault-derived identity, authenticated headers, per-credential key separation, and X448/HKDF-based enrollment support.
  • The emulator and build system gained better MSVC and RP2040/RP2354 support, refreshed SDK and library integration, and additional Windows test launchers.
  • CI and CodeQL workflows were hardened, and metadata was updated for the v8.0 authenticator profile.

Upgrade note

Pico FIDO 8 changes internal credential storage and adds migration-aware container handling. As always, keep a tested recovery path before upgrading a device that holds important credentials. Pico Vault recovery is only possible for credentials exported while the source device is available, with the corresponding Vault material preserved.

Tags: