Commit Graph
5 Commits
Author SHA1 Message Date
Matthew Jackson bce5f36ef2 aacs: honor allow_p256 in up-front cert-skip gate + zeroize key material
Fix two re-audit findings:

1. LOW (correctness): run_cert_handshake_with_anchors computed the
   up-front cert-skip has_v2 gate WITHOUT allow_p256, unlike
   attempt_one_cert. In production (allow_p256=false) a dead-v1 cert
   carrying v2 creds was not skipped up front, reached the drive, failed
   the step-7 self-verify, and consumed a MAX_CERT_ATTEMPTS slot -- so
   [dead+v2 x3, valid] exhausted the cap and never tried the valid cert.
   Mirror attempt_one_cert's gate exactly. Add a regression test.

2. LOW (key hygiene): add the zeroize crate and wipe sensitive key
   material on drop -- HostCert private keys, AacsAuth/CertHandshake
   derived bus_key/volume_id/read_data_key (ZeroizeOnDrop, non-secret
   fields skipped), the ephemeral AKE scalars and raw private-scalar byte
   buffers (Zeroizing). BigUint scalars/shared-x are a documented
   best-effort residual (num-bigint exposes no zeroization). Debug
   redaction and the EC math are untouched.
2026-09-15 14:02:45 -07:00
Matthew Jackson ef3a32eca2 aacs: host-cert keypair-validity check + cert-selection fallback
Add `aacs1_keypair_matches(private_key, cert)` — true iff a stored AACS 1.0
host private key matches its certificate's public key (`priv·G ==
cert_pub_key`), reusing the live handshake's own curve math. A genuine,
LA-signed cert can still be paired in a keydb with the wrong private key,
which never establishes a bus key ("KEY NOT ESTABLISHED"); this primitive
distinguishes that DEAD pairing from a live one. Exposed for the key
service's host-cert health gate. Add `AacsHostSignVerify` (code 7016) for a
host-side self-verify guard on our own produced signature.

Also rework `run_cert_handshake` cert selection: on a rejected/revoked cert
the handshake now backs off and tries the next candidate instead of failing,
with a `cert_host_id_hex` helper and DriveEmu extensions + tests covering
single-valid, back-off-to-second, and roll-past-revoked paths.
2026-09-14 23:25:39 -07:00
Matthew Jackson 407c7f59e3 fix(ld): bind drives whose reported product_id differs from the generic catalog id
find_by_drive_id gated the product-id-blind four-field fallback behind an empty
product_id in 1.7.0, so a drive reporting a specific product_id (e.g. an LG BU40N
reporting "BD-RE BU40N") no longer matched its catalog entry (generic "BD-RE"),
silently skipping the LibreDrive firmware unlocker — the rip fell through to the
AACS host-cert path (LD: no, AACS: yes).

Run the four-field fallback (vendor/revision/vendor_specific/firmware_date)
unconditionally but ambiguity-guarded: bind a UNIQUE catalog match regardless of
the reported product_id (the real-drive case), and require the exact product_id
only when catalogued siblings genuinely share the four-field identity — preserving
the anti-mis-bind protection the 1.7.0 gate intended. Regression test added.

Bump to 1.7.1.
2026-09-13 18:09:50 -07:00
Matthew Jackson 3989100820 freemkv: Identity knock must use the fixed 64-byte data-in allocation
identify() requested a 32-byte data-in allocation while the firmware commits
KNOCK_RESP_LEN (64) bytes on every subfn. The short allocation desyncs the first
command's data-in phase and wedges the drive, so the later bare 0xAD VID read
aborts (CHECK CONDITION) — the "Raw Read GOOD but no VID" failure that left the
keyserver with vid=none. Request KNOCK_RESP_LEN like every other knock; update the
CDB-shape tests. Also sync Cargo.lock to the 1.7.0 manifest.
2026-09-03 07:41:43 -07:00
Matthew Jackson 74936ad892 release: 1.7.0
Fixed
- ld/profile: find_by_drive_id no longer mis-binds a drive whose reported
  product_id is real but uncatalogued to a sibling model's profile (and its wrong
  LibreDrive microcode); the product-id-blind loose match is gated on an empty id.

Docs / CI
- Third-party NOTICE for the LibreDrive microcode bundled in profiles.json;
  cargo-deny gate (#15) and audience-based comment-guard (#17).
2026-09-02 12:27:57 -07:00