docs(legal): evidence chain roadmap
This commit is contained in:
@@ -0,0 +1,135 @@
|
||||
# Evidence chain · roadmap
|
||||
|
||||
The evidence chain is the set of cryptographic + procedural mechanisms that make a Blocao clip **third-party verifiable** as an authentic, untampered record of what happened at a specific time and place.
|
||||
|
||||
This is a separate workstream from the MVP. See [ADR-0007](../../decisions/0007-evidence-chain-postpone.md) for the rationale.
|
||||
|
||||
## Two layers
|
||||
|
||||
The roadmap is split into:
|
||||
|
||||
- **Layer 1 (MVP)**: enough to demonstrate good-faith integrity. Ships in the demo path.
|
||||
- **Layer 2 (post-MVP)**: third-party-verifiable, eIDAS-aligned, suitable for legal proceedings.
|
||||
|
||||
## Layer 1 (MVP) — Good-faith integrity
|
||||
|
||||
Ships by end of Sprint 4 in the basic flow, end of Sprint 7 fully polished.
|
||||
|
||||
### What it provides
|
||||
|
||||
For every recorded clip:
|
||||
|
||||
- **SHA256** computed at write time, stored in the manifest.
|
||||
- **Manifest JSON** with: cam_id, sha_clip, sha_keyframe, ts_local, ts_nts, model_sha, site_id, operator_id (when manually pinned).
|
||||
- **Cell-local signature** over the manifest, using a key generated at first boot.
|
||||
- **NTS-anchored timestamp** (Network Time Security, RFC 8915) so the clock is trustworthy.
|
||||
- **Append-only manifest log** in the Cell, replicated to the hub.
|
||||
|
||||
### What it doesn't provide
|
||||
|
||||
- Timestamp not from a third-party TSA (just NTS — better than naive NTP, less than RFC 3161).
|
||||
- Signature key not customer-controlled (BYOK is L2).
|
||||
- No transparency log replication to a third party.
|
||||
- No FIDO2-attested operator actions.
|
||||
|
||||
### Sufficient for
|
||||
|
||||
- Internal investigations.
|
||||
- Insurance claims (most insurers).
|
||||
- "Show me what happened" forensic playback.
|
||||
- Customers who trust Blocao Labs as the issuer.
|
||||
|
||||
### Not sufficient for
|
||||
|
||||
- Court evidence in jurisdictions requiring eIDAS-qualified TSA.
|
||||
- Adversarial proceedings where the evidence will be challenged.
|
||||
- Regulated industries with specific evidence-chain requirements.
|
||||
|
||||
## Layer 2 (post-MVP) — Legal-grade
|
||||
|
||||
Targeted for end of Year 1 / start of Year 2.
|
||||
|
||||
### What L2 adds
|
||||
|
||||
- **RFC 3161 TSA timestamps**: each manifest is signed by a third-party Time Stamp Authority (eIDAS-qualified TSA in EU; ANSSI-recognized for FR; equivalent in other jurisdictions).
|
||||
- **Transparency log replication**: manifests append to a public-or-private transparency log (Sigstore-style or custom). External parties can verify "this manifest was published by date X".
|
||||
- **BYOK (Bring Your Own Key)**: customer-controlled root key, sealed with Tang+Clevis or HashiCorp Vault. Blocao Labs never sees the key.
|
||||
- **FIDO2-attested operator actions**: when an operator pins a clip to a case or exports an evidence pack, the action is attested with a FIDO2 hardware token. Provides non-repudiation.
|
||||
- **Tamper-evident export packages**: evidence packs are sealed with a reproducible hash chain that any verifier can check independently.
|
||||
|
||||
### What this enables
|
||||
|
||||
- Court-grade evidence in EU jurisdictions accepting eIDAS qualified electronic signatures.
|
||||
- Defensible chain of custody in adversarial proceedings.
|
||||
- Regulated-industry compliance (banking, healthcare with specific evidence rules).
|
||||
- Independent third-party verification ("I have this clip, was it created by Blocao on date X?" verifiable without trusting Blocao Labs or the customer).
|
||||
|
||||
### What it still doesn't provide
|
||||
|
||||
- Proof that what's recorded is not staged or manipulated *at the source* (no AI/CGI detection).
|
||||
- Identity of people in frame (separate workstream — facial recognition, with its own legal complexity).
|
||||
|
||||
## Implementation notes
|
||||
|
||||
### TSA selection
|
||||
|
||||
For EU operations: select a qualified TSA from the EU Trusted List (e.g., one of the certificate authorities recognized under eIDAS). Multiple TSAs supported for redundancy.
|
||||
|
||||
For Argentina / LATAM: ONTI-recognized TSA where available, fall back to international TSA with documented basis.
|
||||
|
||||
### Transparency log
|
||||
|
||||
Two options:
|
||||
|
||||
1. **Public log** (Sigstore-style Rekor instance): maximum transparency, but exposes site_id metadata.
|
||||
2. **Private log** (customer-operated or Blocao-operated, audited): reasonable transparency, less metadata exposure.
|
||||
|
||||
Default: customer-operated private log on the hub, with optional mirror to public log when customer policy allows.
|
||||
|
||||
### BYOK key custody
|
||||
|
||||
Three patterns:
|
||||
|
||||
1. **Customer-managed root** with Tang+Clevis: customer holds the unlock policy, Cells decrypt at boot.
|
||||
2. **HashiCorp Vault** integration: customer's Vault server provides unsealing.
|
||||
3. **HSM-based** (rare): customer has a hardware HSM, Cells request signatures over network.
|
||||
|
||||
Pattern 1 is the default and easiest to operate. Pattern 2/3 for higher-security customers.
|
||||
|
||||
### FIDO2 attestation flow
|
||||
|
||||
Operator clicks "PIN TO CASE" → console requests FIDO2 attestation from operator's hardware token (YubiKey or platform authenticator) → attestation included in the action's MQTT publish + manifest annotation.
|
||||
|
||||
Without FIDO2 token: action is logged but not attested. Higher-tier customers may require FIDO2 for all sensitive operations.
|
||||
|
||||
## Roadmap timing
|
||||
|
||||
| Phase | Milestone | Target |
|
||||
|---|---|---|
|
||||
| L1 basic | SHA + manifest + Cell signature | End of Sprint 4 |
|
||||
| L1 polish | NTS-anchored ts in manifest, append-only log replicated to hub | End of Sprint 7 |
|
||||
| L2 alpha | RFC 3161 TSA integration, single TSA | Year 1 Q4 |
|
||||
| L2 beta | Transparency log replication, BYOK | Year 2 Q1 |
|
||||
| L2 GA | FIDO2-attested operator actions, full eIDAS alignment | Year 2 Q2 |
|
||||
|
||||
## Sales conversation patterns
|
||||
|
||||
**Customer asks**: "Are your clips court-admissible?"
|
||||
|
||||
**Today**: "We sign every clip with a manifest including content hash and trusted-time anchor. For most use cases — internal investigations, insurance claims, civil proceedings where evidence isn't strenuously challenged — that's been sufficient. For criminal proceedings or aggressive civil challenges, evidence chain v2 with RFC 3161 timestamps and transparency log is on our Year 2 roadmap."
|
||||
|
||||
**Customer asks**: "Can the customer hold their own keys?"
|
||||
|
||||
**Today**: "BYOK is on our Year 2 roadmap. Today, the keys are managed by the Cell with a customer-recoverable seal. Discuss your specific requirements with us."
|
||||
|
||||
**Customer asks**: "Do you support eIDAS qualified electronic signatures?"
|
||||
|
||||
**Today**: "Not yet at the qualified-TSA level. Our Year 2 roadmap is explicitly building toward eIDAS alignment. If this is a deal requirement, let's discuss whether we can prioritize for your deployment."
|
||||
|
||||
## Why L1 is enough for MVP
|
||||
|
||||
The vast majority of forensic use cases don't go to court. Most surveillance recordings are reviewed internally, used for insurance, or for operational decisions. L1 is sufficient for these.
|
||||
|
||||
Going to court is rare; when it happens, courts increasingly accept "best-effort cryptographic chain" with appropriate expert witness explanation. L1 supports that.
|
||||
|
||||
L2 is the fortress version, for the customers who need it. We build it as a platform feature available on demand, not as a prerequisite.
|
||||
Reference in New Issue
Block a user