# Installer Release Threat Model

## Scope and Security Objectives

This model covers production source through build, signing, publication, removable-media handling,
boot/install, Online Universal acquisition, offline license import, model/update/trust import,
activation, rollback/recovery and evidence export. It applies to all four bootable products and their
shared signed artifacts.

Security objectives are to ensure that an appliance installs and runs only authorized, intact and
compatible content; entitlement cannot be broadened; offline operation has no hidden network
dependency; customer data and secrets are not disclosed or destroyed by lifecycle operations; and
release/recovery evidence remains attributable and tamper-evident.

This contract does not claim protection against a fully compromised running OS with extracted
administrator control, invasive hardware attacks, denial through physical destruction, or malicious
firmware outside the approved hardware/Secure Boot baseline. Those risks require platform hardening,
physical controls and incident recovery beyond installer verification.

## Assets and Adversaries

Protected assets include source revisions, build inputs/outputs, release/license private keys, public
trust state, signed manifests/channel indexes/revocation lists, customer licenses and binding data,
artifact payloads, active/last-known-good platform state, model weights, customer-created data,
credentials, audit/evidence and recovery media.

Considered adversaries include:

- an internet/on-path attacker controlling DNS, proxy, mirror or download responses;
- a malicious or compromised build dependency, source account, builder, signing operator, publisher
  or support insider;
- an attacker who can replace or modify USB/removable media before or during customer use;
- a local unprivileged user, malicious administrator action, or malware attempting unsafe import;
- a customer/operator mistake, power loss, disk exhaustion or clock manipulation;
- an attacker replaying an older valid artifact, trust bundle, license or evidence package; and
- a party attempting to infer customer identity, entitlement, model use or data from diagnostics.

## Trust Boundaries and Data Flows

| Boundary | Untrusted input crossing it | Required decision before trust |
|---|---|---|
| Source/dependency to builder | Source tree, packages, images, models, toolchains | Immutable revision/digest, license and inventory approval; isolated reproducible build |
| Builder to signing boundary | Artifact, manifest, SBOM, provenance, evidence | Independent digest reconciliation and approved signing request |
| Signing to publisher/archive | Signatures, receipts, channel/trust metadata | Purpose/namespace/policy verification and immutable storage |
| Network/removable media to appliance | ISO, payload, model/update/license/trust bundle | Local fail-closed signature, schema, compatibility, capacity and object verification |
| Staging to active system | Extracted files, images, models, migrations, trust/license state | Safe archive handling, complete staged view, checkpoint, atomic activation and health validation |
| Active system to recovery | Rollback snapshot, prior tree, backup, recovery trust | Exact checkpoint identity, compatibility, authorization and restore validation |
| Appliance to evidence/support | Logs, manifests, packet capture, diagnostics | Allowlist/redaction, integrity index, actor authorization and bounded retention |

Network availability, transport encryption, a removable-media label, filename, mutable tag, local
administrator assertion or checksum delivered beside an artifact are never sufficient trust anchors.

## Threat and Control Register

| ID | Threat / abuse case | Required prevention or detection | Acceptance evidence |
|---|---|---|---|
| TM-01 | Source or dependency substitution | Exact revision/digest inventory, approved licenses, SBOM/provenance, independent rebuild comparison | Tampered/mutable input rejected; inventory and rebuild reconcile |
| TM-02 | Builder injects undeclared content | Builder cannot sign; signed manifest covers every object; extracted artifact reconciled independently | Undeclared/missing/changed object negatives fail |
| TM-03 | Signing key theft or misuse | Separate trust domains, purpose constraints, offline root, dual control, receipts, rotation/revocation | Wrong-domain/purpose/operator/approval cases fail; ceremony evidence exists |
| TM-04 | Publisher, mirror, DNS or proxy substitutes bytes | Appliance verifies embedded root, signature, manifest and object digests; signed channel mapping | MITM/mirror replacement and TLS/customer-CA cases fail before mutation |
| TM-05 | USB is altered, partially written or mislabeled | Whole-media published digest/signature before use plus independent embedded-payload verification | Bit flip, truncation, wrong product/architecture/tier rejected |
| TM-06 | Replay/downgrade of valid old content | Monotonic trust sequence, security floor, compatible from/to ranges and explicit break glass | Old artifact/trust/license replay cases fail or require evidenced recovery authority |
| TM-07 | Malicious archive escapes staging or exhausts resources | Non-executable quarantine, path/link/device checks, declared size/count limits and reserved space | Traversal, link, device, duplicate path and decompression-limit vectors fail |
| TM-08 | Category/tier/license bypass | One canonical entitlement evaluation, required binding, explicit staging allowlist, no compatibility default as entitlement | Wrong tier/category, absent binding, expired/revoked and staging abuse fail consistently |
| TM-09 | Hidden network dependency or data egress | Exact zero-network contract, attempted-fetch capture, local-only required payloads, remote connectors unavailable | No-route plus air-gap runs classify attempts; any dependency fetch attempt fails acceptance |
| TM-10 | Partial activation creates mixed trusted state | Side-by-side staging, complete verification, atomic switch, durable operation and health-gated commit | Power loss at every mutating boundary yields declared prior/new/recovery state |
| TM-11 | Rollback restores incompatible or incomplete state | Full affected-surface checkpoint, schema/data compatibility, last-known-good retention and restore evidence | Rollback and rollback-failure cases reconcile application, data and trust state |
| TM-12 | Shared model object deleted while referenced | Exact-digest reference graph, transactional decrement, holds and reconciliation | Shared/dependent pack uninstall and interrupted GC preserve all references |
| TM-13 | Revocation or withdrawal bricks recovery/destroys data | New activation fails closed; signed behavior directive; diagnostics/export/recovery preserved | Stale/revoked/emergency cases preserve declared recovery and customer data |
| TM-14 | Secrets/customer data leak through logs or evidence | Allowlisted fields, redaction at source/export, role-based access, retention/privacy policy | License, credentials, binding secrets, prompts and model data absent from evidence corpus |
| TM-15 | Evidence is forged, omitted or reassigned | Signed/hash-indexed evidence, durable operation IDs, executor/reviewer separation, failed-run retention | Modification/missing-item/wrong-reviewer checks fail evidence gate |
| TM-16 | Insider alone builds, signs and publishes | Separation of duties and two-person stable-release approval bound to exact digests | Role-conflict and approval-mismatch release requests fail |
| TM-17 | Clock manipulation bypasses expiry/not-before | Signed policy, clock confidence/rollback detection, monotonic sequence and explicit disconnected-time rules | Future/expired/rollback/uncertain-time matrix produces identical fail-closed decisions |
| TM-18 | Unsupported GPU/architecture is advertised as ready | Architecture boundary, hardware-adaptive profiles, signed compatibility rules and truthful degradation | AMD64/ARM64 mismatch and unsupported accelerator profiles cannot claim supported acceleration |

## Security State Invariants

At every durable operation boundary:

1. Active content maps to verified signed manifests and a non-revoked permitted trust path.
2. No staged/quarantined object is runtime-visible.
3. Entitlement can restrict signed content but signed content cannot broaden entitlement.
4. Active, last-known-good, dependency and evidence-held objects cannot be garbage-collected.
5. Trust/security-floor sequence never decreases through an ordinary import or rollback.
6. A failure before activation leaves the prior state active; a failure after the switch either rolls
   back to an evidenced checkpoint or visibly enters `recovery_required`.
7. Customer data, recovery access and non-secret evidence survive license/artifact rejection unless
   an approved, signed emergency rule explicitly requires a narrower action.
8. Product readiness never hides unavailable required capability or an attempted external dependency.

## Abuse and Interruption Test Set

Gate evidence MUST include automated fixtures where possible and controlled physical runs where the
boundary is physical. Minimum cases are:

- compromised/mutable dependency and undeclared build output;
- tampered, truncated, unsigned, unknown-key, wrong-purpose, revoked, expired and replayed artifacts;
- wrong product/category/tier/architecture/platform/runtime and insufficient disk/RAM/VRAM;
- hostile archives, partial removable media and content-size mismatch;
- DNS/proxy/mirror interception for Online Universal and no-route attempted-fetch capture offline;
- license signature, binding, time, staging, expiry, revocation, replacement and rehost abuse;
- power loss at verification, extraction, checkpoint, activation, reboot, validation and rollback;
- model dependency/reference/GC failure and update rollback failure;
- evidence tampering, role conflict, secret injection and missing independent review; and
- signing subordinate compromise and compromised-root tabletop recovery.

Each case records threat ID, precondition, exact artifact/policy identities, expected safe state,
observed state, non-secret reason code, packet/storage/service evidence, executor and independent
reviewer. A failed control blocks the relevant artifact gate; manually repaired runs are not accepted.

## Residual Risks and Required Decisions

The following remain owner decisions rather than assumed controls:

- approved Secure Boot/firmware/TPM baseline and whether measured boot/remote attestation is required;
- production build isolation, dependency-mirror governance and reproducibility target;
- signing hardware, custody, revocation age and compromised-root recovery design;
- administrator/root threat boundary, disk encryption and physical media chain-of-custody expectations;
- offline evidence signing device/key and support evidence transport/privacy rules;
- maximum archive object/count/expansion limits and quarantine quotas;
- anti-rollback floor ownership and break-glass authorization; and
- incident severity, notification, forensic retention and mandatory deactivation criteria.

Gate 1 cannot pass until Security, Platform, Release, Product and Support owners accept or amend the
threat register, assign each residual risk, and approve the minimum test inventory.