Skip to content
Portada » Blog » Pico OpenPGP 5

Pico OpenPGP 5

Stronger key protection. Portable keys. OpenPGP and PIV on one device.

Pico OpenPGP 5 is a major step forward from the v4.6 baseline. It introduces authenticated object-container storage for keys, an opt-in Pico Vault workflow for key portability, admin-less OpenPGP operation, and a substantially broader security and regression test program.

Highlights

Export and import keys with Pico Vault

Pico Vault provides opt-in, object-level key portability for the OpenPGP and PIV applications.

  • Enrollment is protected by the appropriate application PIN and a physical-button ceremony.
  • Selected OpenPGP private keys, the OpenPGP AES key, and supported PIV key objects can be exported as authenticated, encrypted `PKV1` packages.
  • Packages bind the vault, application, object identity, device serial, encryption profile, and key material together.
  • Four encryption profiles are supported: ChaCha20-Poly1305, AES-GCM, and both two-layer combinations.
  • Imported keys are written through the same protected key-container path as locally generated or imported keys.
  • Vault status, labels, unenrollment, malformed-package rejection, tamper detection, wrong-vault rejection, and live round trips are covered by tests.

Pico Vault is a gated vendor capability, not a change to ordinary OpenPGP or PIV command semantics. Keep the vault enrollment material, exported packages, and PINs under the same care as any other key-recovery asset.

OpenPGP improvements

  • Private and public key data now use authenticated PicoKeys SDK object containers with separate OpenPGP and PIV key domains.
  • Container updates use bounded, generation-aware transactions and recover safely from interrupted writes and power loss.
  • Existing legacy PIN, DEK, and key layouts remain migration-aware while new container-backed keys are protected by the new storage path.
  • Added non-standard Gnuk-compatible admin-less mode, including pending activation, KDF migration, PIN synchronization, reset behavior, and return to admin-full mode.
  • OpenPGP 3.4.1 data-object handling was tightened, including constructed `7F74`, complete object identifiers, fixed-size fingerprints and timestamps, and correct undefined-reference reporting.
  • Key import now rejects unsupported or malformed algorithm attributes before key creation, including invalid RSA sizes, EC scalar lengths, and RSA family aliases.
  • Key generation and import preserve the relevant public-key data and policy metadata, with safer default no-touch behavior.
  • Corrected authentication dispatch, MSE mapping, PSO signature policy enforcement, AES key preservation, cardholder certificate occurrence handling, and retired-key operations.

PIV improvements

The bundled PIV 5.7 application received shared storage, authentication, and protocol hardening:

  • Added authenticated container-backed storage for PIV private keys and public metadata, including retired slots and the attestation key.
  • Hardened management-key challenge binding, challenge expiry, algorithm matching, key provenance, and canonical certificate serial handling.
  • Corrected retired-slot metadata, default PIN and touch policies, button handling, larger-command handling, and OpenPGP/PIV termination boundaries.
  • Expanded coverage for PIN and PUK operations, management authentication, key generation and import, signing, RSA deciphering, certificates, objects, attestation, and reset behavior.

Security and reliability

  • PIN verification and retry handling now validate framing and lengths before spending retries or changing state.
  • PW1.81, PW1.82, PW3, and PIV authentication latches are kept independent and are cleared or expired at the appropriate boundaries.
  • Failed authentication and unrelated commands no longer leave stale management authorization or challenges usable.
  • PUT DATA, IMPORT, RESET RETRY COUNTER, GET CHALLENGE, certificate, cardholder, and password-status paths enforce tighter size, bounds, authorization, and parameter checks.
  • Internal filesystem records are hidden from ordinary OpenPGP selection and data access.
  • PIN and DEK updates are recoverable across power loss, including interrupted first-boot provisioning.
  • Private-key material and temporary vault buffers are cleared after use, and key export requires explicit vault authorization.

Conformance and testing

The release adds a broad automated test program covering:

  • OpenPGP PC/SC behavior, data objects, PIN and reset flows, admin-less mode, algorithm validation, key import and generation, public-key round trips, AES operations, certificates, and lifecycle commands.
  • Authenticated key-container lifecycle, authorization boundaries, corruption fallback, legacy-key collision handling, and simulated power-loss points.
  • Pico Vault enrollment, status, export/import for OpenPGP keys, all four encryption profiles, tamper and malformed-input rejection, unenrollment, and PIV dispatch.
  • PIV application, PIN, management, key, certificate/object, attestation, reset, and regression behavior across common and retired slots.

OpenPGP and PIV tests now have separate test trees, and the emulation workflow builds and exercises both applications. CI, CodeQL, nightly workflows, and the containerized test environments were updated alongside the expanded coverage.

Under the hood

  • Updated the bundled PicoKeys SDK to version 9.
  • Migrated the application to the SDK’s byte-array APIs and new TLV/object-container interfaces.
  • Added OpenPGP-specific object providers, policies, manifests, markers, and namespace-aware key layouts.
  • Added dynamic dependency resolution and refreshed Pico, ESP32, emulation, and CI integration.
  • Added a dedicated OpenPGP key-container unit test target with transaction, authorization, corruption, and power-loss checks.

Upgrade note

Pico OpenPGP 5 changes how newly written OpenPGP and PIV key material is stored and adds migration-aware handling for previous layouts. Keep a tested recovery path before upgrading a device that holds important keys. Pico Vault recovery requires the source device’s vault enrollment material and the corresponding exported package to remain available.

Tags: