#875
Issues/betrusted-io/xous-core/#875

Feature request: `usb-bao1x` — add first-boot provisioning personality and CCID OpenPGP support

OpenSupermagnumopened 5mo ago

Repository: betrusted-io/xous-core Affects: services/usb-bao1x/ Feature gate: ccid-openpgp (no effect on existing builds)

Summary

The Galdralag-firmware project (https://github.com/Supermagnum/Galdralag-firmware) implements an OpenPGP card security token on the Baochip-1x (Dabao) platform. The firmware-side CCID class, OpenPGP protocol handlers, vault backend, and first-boot PIN provisioning are complete. What is missing is the usb-bao1x integration in xous-core.

Two things are needed:

  1. A first-boot USB provisioning personality so an operator can set User PIN and Admin PIN before CCID activates.
  2. CCID OpenPGP support wired into the usb-bao1x poll loop alongside the existing HID, FIDO, and serial classes.

What Galdralag-firmware provides

  • crates/usb-personality — CcidClass and ProvisioningClass (CDC-ACM first-boot PIN setup)
  • crates/baochip-openpgp — vault backend, open_or_provision_backend, write_provisioning_pins, HalError::NeedsProvisioning
  • host-tools — galdralag-provision CLI for operator PIN setup over serial

What xous-core needs to add in services/usb-bao1x/

  • Optional dependencies on baochip-openpgp, usb-personality, and trng under a ccid-openpgp feature flag
  • First-boot detection via HalError::NeedsProvisioning — run ProvisioningClass until operator commits PINs via galdralag-provision, then switch to CCID
  • CcidClass added to the device.poll call in composite_handler
  • ccid.reset() called on USB reset and unplug events

Constraints

  • Provisioning personality only reachable on first boot; subsequent boots go directly to CCID
  • No display dependency — provisioning is handled over CDC-ACM serial by the host tool
  • No effect on existing HID, FIDO, or serial functionality

References

  • docs/RRAM_LAYOUT.md — PIN provision slot layout
  • docs/HARDWARE_BRINGUP_TEST_PLAN.md — bring-up sequence including provisioning step
  • libs/bao1x-hal/src/usb/driver.rs — CorigineWrapper, QUIRK_SET_ADDRESS_BEFORE_STATUS

Activity

2
Supermagnum3mo ago

Caller authentication requirement for CCID transport opcodes (640/642)

Galdralag tracks CCID IPC as CcidRxDeferred (640) and CcidTx (642) in application code (usb_bao_ipc.rs), mirroring the existing U2F wire types (U2fMsgIpc / U2fCode).

Requirement before merge: both CCID opcodes must enforce on-device caller authentication equivalent to the existing U2F first-PID-lock pattern already implemented in services/usb-bao1x/src/main.rs for U2fRxDeferred (129) and U2fTx (128):

  • On first use, record msg.sender.pid() as the CCID listener owner.
  • Subsequent messages from other PIDs must fail closed (U2F returns U2fCode::Denied in the IPC buffer; CCID should return CcidCode::Denied or reject without side effects).
  • Do not rely on host-side session-token verification alone; Galdralag threat model T7 treats host session-token checks and on-device PID lock as independent, both required.

Prior art in the same server: fido_listener_pid handling around Opcode::U2fRxDeferred and Opcode::U2fTx (approx. lines 403–535 in current main.rs).

Current vendored snapshot in Galdralag: api.rs has no 640/642 variants yet; unknown opcodes still hit the _ arm (log + continue). Please add CCID opcodes with auth at implementation time, not as a follow-up.

Reference: Galdralag docs/THREAT_MODEL.md section "IPC access control (userspace audit refresh, 2026-06)".

Supermagnum3mo ago

Caller authentication requirement for CCID transport opcodes (640/642)

Somewhat related: Galdralag tracks CCID IPC as CcidRxDeferred (640) and CcidTx (642) in application code (usb_bao_ipc.rs), mirroring the existing U2F wire types (U2fMsgIpc / U2fCode).

Requirement before merge: both CCID opcodes must enforce on-device caller authentication equivalent to the existing U2F first-PID-lock pattern already implemented in services/usb-bao1x/src/main.rs for U2fRxDeferred (129) and U2fTx (128):

  • On first use, record msg.sender.pid() as the CCID listener owner.
  • Subsequent messages from other PIDs must fail closed (U2F returns U2fCode::Denied in the IPC buffer; CCID should return CcidCode::Denied or reject without side effects).
  • Do not rely on host-side session-token verification alone; Galdralag threat model T7 treats host session-token checks and on-device PID lock as independent, both required.

Prior art in the same server: fido_listener_pid handling around Opcode::U2fRxDeferred and Opcode::U2fTx (approx. lines 403–535 in current main.rs).

Current vendored snapshot in Galdralag: api.rs has no 640/642 variants yet; unknown opcodes still hit the _ arm (log + continue). Please add CCID opcodes with auth at implementation time, not as a follow-up.

Reference: Galdralag docs/THREAT_MODEL.md section "IPC access control (userspace audit refresh, 2026-06)".