# 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
