Security and Trust Model
Big Picture uses cryptographic signatures to establish trust in an untrusted environment. Clients verify signatures before trusting any guidance from Big Picture.
The Trust Problem
Section titled “The Trust Problem”Desktop software updates operate in a hostile environment:
- Networks may be compromised (MITM attacks, DNS poisoning)
- CDNs and mirrors may be tampered with
- Endpoints may be compromised
- Regulated environments may require air-gapped operation
Traditional update systems often rely on TLS alone, which provides transport security but doesn’t protect against compromised endpoints or malicious mirrors.
Cryptographic Signatures
Section titled “Cryptographic Signatures”Big Picture signs all authoritative data using Ed25519 signatures:
What Gets Signed
Section titled “What Gets Signed”- Update decisions: Responses to client update checks
- License leases: Tokens granting permission to use software
- Snapshot bundles: Complete catalog snapshots for mirrors
- Release metadata: Version information, artifact references, channel assignments
Signature Verification
Section titled “Signature Verification”Clients verify signatures before trusting any data:
- Client receives signed data (decision, lease, snapshot)
- Client verifies signature against pinned public key
- If signature is valid, client trusts the data
- If signature is invalid or missing, client rejects the data
This ensures that even if networks, CDNs, or mirrors are compromised, clients can detect tampering.
Key Management
Section titled “Key Management”Signing Keys
Section titled “Signing Keys”Big Picture uses separate signing keys for:
- Update metadata signing
- License lease signing
- Snapshot signing (for mirrors)
Keys are stored in:
- SaaS deployments: Google Cloud KMS or Cloud HSM
- Self-hosted deployments: Vendor-controlled HSM, Vault, or file-backed storage
Private keys never leave the server. Signing operations happen server-side using key management services.
Key Rotation
Section titled “Key Rotation”Signing keys can be rotated:
- Old keys remain valid for a grace period to support clients that haven’t updated
- New keys are distributed through secure channels
- Clients pin public keys and update them through secure mechanisms
Trust Boundaries
Section titled “Trust Boundaries”
Client Boundary
Section titled “Client Boundary”Clients operate in untrusted environments:
- Endpoints may be compromised
- Local storage may be tampered with
- Clients cannot trust their own execution environment
Big Picture assumes compromised endpoints and limits damage by:
- Never executing code
- Never escalating privileges
- Requiring signature verification for all decisions
Network Boundary
Section titled “Network Boundary”Networks are untrusted:
- Public internet, CDNs, and mirrors may be hostile
- Transport security (TLS) protects in transit but not at rest
Big Picture protects against network threats through:
- End-to-end signatures (not just transport security)
- Hash verification of artifacts
- Immutable, signed metadata
Service Boundary
Section titled “Service Boundary”Big Picture services are trusted:
- Signing keys are protected
- Policy evaluation is authoritative
- Audit logs are append-only
This boundary is protected through:
- Authentication and authorization
- Key management security
- Operational security practices
Threat Model
Section titled “Threat Model”Big Picture addresses these threats:
Tampering
Section titled “Tampering”Threat: Modified update catalogs, malicious mirrors, CDN compromise
Mitigation: Cryptographically signed metadata; clients verify signatures before trust
Residual Risk: Very low; attacker must compromise signing key
Spoofing
Section titled “Spoofing”Threat: Impersonated clients, tenant impersonation, token replay
Mitigation: Tenant-scoped authentication, short-lived tokens, mutual TLS (optional)
Residual Risk: Low; endpoint compromise assumed but bounded
Repudiation
Section titled “Repudiation”Threat: Undetected policy changes, unlogged decisions
Mitigation: Append-only audit logs, immutable releases, signed decision responses
Residual Risk: Low
Information Disclosure
Section titled “Information Disclosure”Threat: Cross-tenant data leakage, policy visibility across customers
Mitigation: Strict tenant isolation, catalog filtering at decision time
Residual Risk: Low
Denial of Service
Section titled “Denial of Service”Threat: Update service outage, CDN unavailability
Mitigation: Cacheable signed responses, graceful client fallback, no hard dependency for app startup
Residual Risk: Medium but non-impacting (updates paused, not broken)
Elevation of Privilege
Section titled “Elevation of Privilege”Threat: Client installs software without admin rights, policy bypass
Mitigation: Client enforces installer capability checks, policy explicitly declares allowed actions, MANAGED_BY_IT mode disables installs
Residual Risk: Very low
Zero Trust Principles
Section titled “Zero Trust Principles”Big Picture follows zero trust principles:
- Never trust, always verify: Clients verify signatures for all data
- Assume breach: System assumes endpoints and networks may be compromised
- Least privilege: Clients receive only the decisions they need, nothing more
- Explicit verification: Trust is established through cryptographic proof, not network location
Compliance Considerations
Section titled “Compliance Considerations”Big Picture’s security model supports compliance requirements:
- SOC2: Signed metadata, authentication, tenant isolation, audit logs
- Regulated environments: Self-hosting options, air-gap support, outbound-only operation
- Audit readiness: Immutable releases, append-only logs, reproducible decisions
Related Concepts
Section titled “Related Concepts”- Core Principles explains why signed metadata is fundamental
- Release Management Philosophy describes how signatures enable policy-driven updates
- See Governance for operational security practices