-
released this
2026-08-19 06:21:15 +00:00 | 107 commits to dev since this releaseThe 2.0 host-cert handshake is now live and cert-agnostic (works when a
cert is supplied), with the same chain-of-trust hardening as 1.0; the
SECURITY note is resolved by fixing, not by leaving dead.- Remove the module-level #[allow(dead_code)]; the P-256/v2 AKE is now
reachable from run_cert_handshake. - run_cert_handshake selects the P-256 AKE per host cert: the 1.0 cert is
tried first (an AACS 2.0 drive accepts it for the VID); if the drive
refuses it AND the supplied HostCert carries AACS 2.0 (P-256)
credentials, fall back to the native P-256 AKE. No possession/feature
gate — it consumes whatever the HostCert carries, exactly as the 1.0
path consumes hc.certificate. A 1.0-attempt transport fault
short-circuits the fallback so a dead bus is not hammered. - Chain-of-trust hardening on the now-live v2 path, mirroring 1.0:
drive-cert TYPE gate (only 0x11 accepted, else rejected), cert verify
is FATAL (verify_cert_p256 under the real 2.0 LA anchor), ECDSA-P256
point validation on every attacker-supplied point (point_on_curve in
ecdsa_verify_p256 + compute_bus_key_p256), and AGID release on every
exit. - The 2.0 cert byte layout/signed-range is documented as PROVISIONAL: no
genuine 2.0 host/drive AKE cert exists to pin it, and the draft spec
implies extra Host-ID/paired-DKS fields. A wrong signed range fails
CLOSED (fatal verify rejects), never trusts. An #[ignore] slot awaits a
real cert. - Tests: synthetic test-LA-signed 2.0 certs prove accept + bus-key
derivation, bad-signature fatal reject, unknown-type reject, and
off-curve/identity rejection (each red-before-green per guard); a
genuine AACS 2.0 content cert verifies under the published CC key,
proving the P-256/SHA-256 primitive against real material.
Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- Remove the module-level #[allow(dead_code)]; the P-256/v2 AKE is now