SysAdmin
7d5f9cc246
Cross-platform privacy-hardening program. Two-layer product: - SilverLABS Application Stack (cross-platform spine) - Platform Hardening Profiles (per-OS, tier-honest) Platforms: Linux (Debian/Kicksecure), Android (Pixel/Samsung/Moto/generic), Windows (LTSC IoT), macOS (profile), iOS (MDM profile). Each flavour has both a preflashed hardware SKU path and a self-apply "harden your existing device" path. Includes umbrella docs (README + threat-model, design-principles, platform-matrix, roadmap, trust-model), per-platform and per-stack- component README stubs, .gitignore, LICENSE. Linux v1 ships first; Stack v1 = Browser + VPN + Sync. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
102 lines
5.0 KiB
Markdown
102 lines
5.0 KiB
Markdown
# Trust Model
|
|
|
|
How users (and we) verify what SilverMetal ships. Trust is earned through verifiability, not asserted in marketing.
|
|
|
|
## What a SilverMetal user trusts
|
|
|
|
In rough order of decreasing necessity:
|
|
|
|
1. **The hardware** — at minimum, the CPU and TPM. Coreboot-supported SKUs reduce firmware-level trust requirements. Commodity SKUs do not eliminate them.
|
|
2. **SilverLABS' release signing keys** — to verify a downloaded image is genuine.
|
|
3. **SilverLABS' build process** — to trust the published artefact came from the published source. Reproducible builds let users *verify* this rather than just trust it.
|
|
4. **The platform vendor** — for Windows / macOS / iOS, we cannot eliminate trust in Microsoft / Apple. We say so explicitly.
|
|
5. **SilverLABS' server infrastructure** — for hosted SilverVPN nodes, SilverSync, SilverChat. Self-hosting alternatives are documented.
|
|
6. **Themselves** — to not negate the protections.
|
|
|
|
## Reproducible builds
|
|
|
|
Every SilverMetal release artefact is built reproducibly:
|
|
|
|
- Pinned toolchain versions
|
|
- Pinned dependency hashes
|
|
- Stripped of build-environment metadata (timestamps, paths, host info)
|
|
- CI re-builds from a clean checkout and verifies identical output
|
|
|
|
The reproducibility procedure is published per-component. Anyone can:
|
|
1. Clone the repo at the release tag
|
|
2. Run the documented build command
|
|
3. Compare SHA256 of their artefact to the published one
|
|
|
|
Mismatch = supply chain anomaly. Report channel: `security@silverlabs.uk`.
|
|
|
|
## Signing keys
|
|
|
|
| Key | Purpose | Storage | Rotation |
|
|
|---|---|---|---|
|
|
| **SilverMetal Release** | Signs ISO/ROM/installer artefacts | Offline (HSM, ceremony-only access) | Major-version |
|
|
| **SilverMetal Update Channel** | Signs OTA / apt updates | Online but isolated; sub-key model | Yearly or on compromise |
|
|
| **SilverMetal Code Signing — Linux** | Signs `.deb`, kernel modules | Offline | Major-version |
|
|
| **SilverMetal Code Signing — Windows** | Authenticode cert for `.exe`/`.msi` | HSM or signing service | Per-cert lifetime |
|
|
| **SilverMetal Code Signing — macOS/iOS** | Apple Developer ID cert | Apple-managed | Per-cert lifetime |
|
|
| **SilverMetal MOK (Linux Secure Boot)** | Our Machine Owner Key for Secure Boot | Offline | Major-version |
|
|
| **SilverMetal AVB (Android verified boot)** | Android verified-boot key | Offline | Per-device-generation |
|
|
|
|
Key fingerprints are published in `shared/signing/KEYS.md` (to be populated at first key generation).
|
|
|
|
### Key ceremony policy
|
|
- All offline keys generated in air-gapped environment
|
|
- Multi-party control where feasible (M-of-N for the most critical keys)
|
|
- Rotation procedure documented before keys are first used
|
|
- Compromise procedure documented before keys are first used
|
|
|
|
## SBOM (Software Bill of Materials)
|
|
|
|
Every release publishes a complete SBOM in CycloneDX format:
|
|
|
|
- All packages with version, source, license, hash
|
|
- Build-time vs. runtime dependencies distinguished
|
|
- Reproducible-build attestation linked
|
|
|
|
SBOMs live in the release-page's `sbom/` directory.
|
|
|
|
## Vulnerability response
|
|
|
|
| Severity | Triage | Fix | Disclosure |
|
|
|---|---|---|---|
|
|
| Critical (active exploitation) | < 24h | Out-of-band release | Coordinated, then public |
|
|
| High | < 72h | Next scheduled release | Coordinated, then public |
|
|
| Medium | < 2 weeks | Next scheduled release | With release notes |
|
|
| Low | Best-effort | Backlog | With release notes |
|
|
|
|
Reports: `security@silverlabs.uk`, GPG key in `shared/signing/`.
|
|
|
|
## What we publish (transparency)
|
|
|
|
- **All source code** for our own components — open repos on `git.silverlabs.uk`
|
|
- **Threat model** — `docs/threat-model.md`, updated when scope changes
|
|
- **Reproducibility procedure** per-component
|
|
- **SBOMs** per release
|
|
- **Signing key fingerprints** and ceremony summaries
|
|
- **Security advisories** — signed, dated, public archive
|
|
- **Subpoena / law enforcement transparency report** — annual; we publish counts and what we had/didn't have
|
|
- **Audit reports** — third-party audits published in full when commissioned
|
|
|
|
## What we do *not* publish (and why)
|
|
|
|
- **Active investigation details** — until coordinated disclosure window closes
|
|
- **Per-user data** — we do not have most of it (minimum-data architecture); what we do have, we do not publish
|
|
- **Server-side credential material** — for obvious reasons
|
|
|
|
## Governance
|
|
|
|
- This is a SilverLABS project; final calls rest with SilverLABS leadership
|
|
- Security-critical decisions are documented (ADR-style) in `docs/decisions/` (to be created when first decision is needed)
|
|
- Community contributions accepted via standard PR review with security-sensitive changes requiring a second reviewer
|
|
|
|
## Honest acknowledgements
|
|
|
|
- We are a small organisation. We will not match the auditor count of a Fortune-500 vendor
|
|
- We use external upstream code (Kicksecure, GrapheneOS, Chromium, etc.) and inherit their trust assumptions
|
|
- We cannot defend against every adversary; see [`threat-model.md`](threat-model.md) for what we do and do not target
|
|
- Trust grows with track record; we expect to be audited and judged over time
|