From b7d9ed54259e06a6d0344641bc98b8da4f75cff0 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Wed, 23 Sep 2026 03:42:38 -0400 Subject: [PATCH] FABRIC-3.7.md: settle drive-cloning defense as rejected, not undesigned Captain Bob rejected a PIN/passphrase second factor firmly and directly after it was built and live-tested on all three architectures: "nothing like a pin or a password or secret code or any bullshit... Everybody has secrets. There's only the drive." All PIN-related code (KDF, XOR keystream seed encryption, no-echo input, MINT/WIREBIND prompts, user_identity_seed_t v3 format) was reverted before commit -- none of it ever landed in git history. This project's identity model has no knowledge factor, by design: physical possession of the thumbdrive is the entire credential. A byte-for-byte clone being equivalent to the real drive is the accepted model, not a gap needing a fix. Recorded here so future work doesn't default back to a PIN/password approach. Co-Authored-By: Claude Sonnet 5 --- FABRIC-3.7.md | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/FABRIC-3.7.md b/FABRIC-3.7.md index 5024e9a8..deba8630 100644 --- a/FABRIC-3.7.md +++ b/FABRIC-3.7.md @@ -171,17 +171,20 @@ Corrected per §2's re-read above. Concretely, when Phase 8 next picks this up: 2026-09-22) — `ZUSE-ELIGIBILITY-ADD` denied by default, granted only inside `ACL-ZUSE-BOOT`'s authenticated branch. This closes the actual "grant yourself eligibility with no real drive at all" path — a real, independently-confirmed gap, unaffected by this correction. -- The Ed25519 **challenge-response** itself — proving the caller holds the *private* key, not - just presenting a pubkey that matches something in `zuse_eligibility_is_member()`'s list — is - a separate, larger piece of this same Phase 8 item and is not designed here. Today, WIREBIND/ - MINT trust whatever identity is stored on an attached thumbdrive with no challenge at all - (confirmed by grep: no `ed25519_sign`/`ed25519_verify` call anywhere in `capsule_wirebind.c` or - `capsule_mint.c`). Also confirmed this session: the private key seed itself is stored in - plaintext on the drive, read in the same devblock as the pubkey/cert — a naive - challenge-response wouldn't defend against a cloned drive, since the clone has the seed too. - Defending against drive cloning (as opposed to "no real drive at all," which the cert-signature - chain already defends against) is a separate, harder, undesigned problem — see the Phase 8 v1 - plan (`/home/rajames/.claude/plans/jiggly-cuddling-stallman.md`) for the full reasoning. +- **Defending against a cloned drive — settled, 2026-09-23: not going to happen, by design.** + Today, WIREBIND/MINT trust whatever identity is stored on an attached thumbdrive with no + challenge at all (confirmed by grep: no `ed25519_sign`/`ed25519_verify` call anywhere in + `capsule_wirebind.c` or `capsule_mint.c`), and the private key seed itself is stored in + plaintext on the drive, read in the same devblock as the pubkey/cert. **This is accepted, not + a gap.** Captain Bob, directly: *"nothing like a pin or a password or secret code or any + bullshit... Everybody has secrets. There's only the drive."* Physical possession of the drive + is the entire, deliberate credential model — a byte-for-byte clone being equivalent to the + real drive is the accepted design, not a defect to close. A PIN/passphrase second factor was + built, live-tested on all three architectures, and fully reverted before commit + (`/home/rajames/.claude/plans/jiggly-cuddling-stallman.md`, now marked rejected; memory + `feedback_no_knowledge_factor_identity`) — **do not revisit a knowledge-factor approach here.** + Any future work in this space needs a fundamentally different mechanism (not something typed + and known) or stays an accepted limitation. ## 5. What this document is not