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>
5.0 KiB
5.0 KiB
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:
- The hardware — at minimum, the CPU and TPM. Coreboot-supported SKUs reduce firmware-level trust requirements. Commodity SKUs do not eliminate them.
- SilverLABS' release signing keys — to verify a downloaded image is genuine.
- SilverLABS' build process — to trust the published artefact came from the published source. Reproducible builds let users verify this rather than just trust it.
- The platform vendor — for Windows / macOS / iOS, we cannot eliminate trust in Microsoft / Apple. We say so explicitly.
- SilverLABS' server infrastructure — for hosted SilverVPN nodes, SilverSync, SilverChat. Self-hosting alternatives are documented.
- 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:
- Clone the repo at the release tag
- Run the documented build command
- 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.mdfor what we do and do not target - Trust grows with track record; we expect to be audited and judged over time