aipackage/specs/001-enterprise-experience/contracts/installer-threat-model.md

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.