124 lines
2.4 KiB
Markdown
124 lines
2.4 KiB
Markdown
|
# ASL/AUTH-HOST-THREAT-MODEL/1 - Threat Model
|
||
|
|
|
||
|
|
Status: Draft
|
||
|
|
Owner: Architecture
|
||
|
|
Version: 0.1.0
|
||
|
|
SoT: No
|
||
|
|
Last Updated: 2026-01-17
|
||
|
|
Tags: [ops, authority, security]
|
||
|
|
|
||
|
|
**Document ID:** `ASL/AUTH-HOST-THREAT-MODEL/1`
|
||
|
|
**Layer:** O2S - Authority host security profile
|
||
|
|
|
||
|
|
**Depends on (normative):**
|
||
|
|
|
||
|
|
* `ASL/AUTH-HOST/1`
|
||
|
|
|
||
|
|
**Informative references:**
|
||
|
|
|
||
|
|
* `ASL/OFFLINE-ROOT-TRUST/1`
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 0. Conventions
|
||
|
|
|
||
|
|
The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHOULD**, and **MAY** are to be
|
||
|
|
interpreted as in RFC 2119.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 1. Scope and Assumptions
|
||
|
|
|
||
|
|
### 1.1 In Scope
|
||
|
|
|
||
|
|
* Offline authority host
|
||
|
|
* USB-mediated intake and output
|
||
|
|
* DAM signing and admission artifacts
|
||
|
|
* PEL execution for receipt generation
|
||
|
|
* Snapshot and log sealing
|
||
|
|
|
||
|
|
### 1.2 Assumptions
|
||
|
|
|
||
|
|
1. Physical access to hardware is controlled.
|
||
|
|
2. The host is offline (no network interfaces).
|
||
|
|
3. Root keys are uncompromised.
|
||
|
|
4. Operator presence is required for authority actions.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 2. Assets
|
||
|
|
|
||
|
|
* Root authority keys
|
||
|
|
* Domain signing keys
|
||
|
|
* DAM and policy artifacts
|
||
|
|
* PER receipts and environment claims
|
||
|
|
* Domain identity bindings
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 3. Adversary Model
|
||
|
|
|
||
|
|
The adversary MAY:
|
||
|
|
|
||
|
|
* Supply malicious USB content
|
||
|
|
* Replay old requests
|
||
|
|
* Provide malformed PEL programs
|
||
|
|
* Attempt to confuse domain identity
|
||
|
|
|
||
|
|
The adversary MUST NOT:
|
||
|
|
|
||
|
|
* Access signing keys without operator approval
|
||
|
|
* Modify host binaries without physical compromise
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 4. Trust Boundaries
|
||
|
|
|
||
|
|
```
|
||
|
|
[ USB INPUT ] -> [ AUTH HOST ] -> [ USB OUTPUT ]
|
||
|
|
```
|
||
|
|
|
||
|
|
Data flows are unidirectional per phase. The host MUST treat input as untrusted
|
||
|
|
until verification succeeds.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 5. Threats and Mitigations
|
||
|
|
|
||
|
|
### 5.1 Spoofing
|
||
|
|
|
||
|
|
* Mitigation: DAM signature verification and policy hash checks.
|
||
|
|
|
||
|
|
### 5.2 Tampering
|
||
|
|
|
||
|
|
* Mitigation: hash all inputs, sign outputs, mount USB read-only.
|
||
|
|
|
||
|
|
### 5.3 Repudiation
|
||
|
|
|
||
|
|
* Mitigation: PER receipts include program hash, input hashes, and snapshot ID.
|
||
|
|
|
||
|
|
### 5.4 Information Disclosure
|
||
|
|
|
||
|
|
* Mitigation: no network, explicit publish rules, encrypted private artifacts.
|
||
|
|
|
||
|
|
### 5.5 Denial of Service
|
||
|
|
|
||
|
|
* Mitigation: operator-mediated execution, size limits, deterministic PEL subset.
|
||
|
|
|
||
|
|
### 5.6 Elevation of Privilege
|
||
|
|
|
||
|
|
* Mitigation: PEL is declarative, no syscalls or I/O primitives.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 6. Residual Risk
|
||
|
|
|
||
|
|
* Physical compromise of hardware is out of scope.
|
||
|
|
* Operator error remains a risk and SHOULD be mitigated with checklists.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 7. Versioning
|
||
|
|
|
||
|
|
Backward-incompatible changes MUST bump the major version.
|