292 lines
6 KiB
Markdown
292 lines
6 KiB
Markdown
Absolutely. Below is a **formal threat model write-up** for the system as it now stands. This is **not theoretical**; it is written to match your exact design choices, maturity level, and operational reality.
|
||
|
||
I’ll keep it structured, explicit, and grounded.
|
||
|
||
---
|
||
|
||
# ASL-AUTH-HOST v0.1 — Threat Model
|
||
|
||
## 1. Scope and Assumptions
|
||
|
||
### 1.1 In Scope
|
||
|
||
This threat model covers:
|
||
|
||
* **Offline ASL-AUTH-HOST**
|
||
* USB-mediated intake and output
|
||
* PEL execution
|
||
* Receipt (PER) generation and signing
|
||
* Domain admission and rescue bootstrap
|
||
* Published artifact creation
|
||
|
||
### 1.2 Explicit Assumptions
|
||
|
||
1. **Physical access = ultimate trust boundary**
|
||
|
||
* The attacker may have physical access to USB media.
|
||
* The attacker may *not* have unsupervised access to the auth host hardware.
|
||
|
||
2. **Auth host is air-gapped**
|
||
|
||
* No network interfaces.
|
||
* No radios.
|
||
* No background services.
|
||
|
||
3. **Offline root keys are uncompromised**
|
||
|
||
* Root compromise is **out of scope** (catastrophic).
|
||
|
||
4. **Operator is present**
|
||
|
||
* Console interaction is intentional and visible.
|
||
|
||
---
|
||
|
||
## 2. Assets to Protect
|
||
|
||
| Asset | Description |
|
||
| ------------------------- | ------------------------------ |
|
||
| Root authority keys | Domain trust anchors |
|
||
| Domain signing keys | Used to mint DAMs and receipts |
|
||
| Execution receipts (PERs) | Portable truth of execution |
|
||
| Published artifacts | Immutable outputs |
|
||
| Domain identity | Correct domain binding |
|
||
| Policy hash | Guarantees semantic compliance |
|
||
|
||
---
|
||
|
||
## 3. Adversary Model
|
||
|
||
### 3.1 Adversary Capabilities
|
||
|
||
The attacker may:
|
||
|
||
* Supply malicious USB content
|
||
* Replay old requests
|
||
* Attempt malformed PEL programs
|
||
* Attempt filesystem abuse via USB
|
||
* Attempt to confuse domain identity
|
||
* Attempt to exfiltrate private artifacts
|
||
|
||
The attacker **cannot**:
|
||
|
||
* Inject network traffic
|
||
* Modify host binaries (unless physical compromise)
|
||
* Access signing keys without operator approval
|
||
|
||
---
|
||
|
||
## 4. Trust Boundaries
|
||
|
||
```
|
||
[ USB ] ────(read-only)────> [ AUTH HOST ]
|
||
|
|
||
| (PEL execution)
|
||
v
|
||
[ ASL Store ]
|
||
|
|
||
└──> (write-only) → [ USB RESPONSE ]
|
||
```
|
||
|
||
**Critical principle**:
|
||
|
||
> Data flows in one direction per phase, never bidirectional.
|
||
|
||
---
|
||
|
||
## 5. Threat Analysis (STRIDE-like)
|
||
|
||
### 5.1 Spoofing
|
||
|
||
**Threat:**
|
||
Fake domain requests or forged admission.
|
||
|
||
**Mitigations:**
|
||
|
||
* Manifest + signature verification
|
||
* Policy hash enforcement
|
||
* Offline root verification
|
||
* Domain IDs generated and signed by authority
|
||
|
||
---
|
||
|
||
### 5.2 Tampering
|
||
|
||
**Threat:**
|
||
USB content modified to alter inputs or outputs.
|
||
|
||
**Mitigations:**
|
||
|
||
* Intake is read-only
|
||
* Hashes over all inputs
|
||
* Response signature covers:
|
||
|
||
* Request manifest hash
|
||
* Receipt hash
|
||
* Published artifact hashes
|
||
|
||
---
|
||
|
||
### 5.3 Repudiation
|
||
|
||
**Threat:**
|
||
Requester denies what was executed.
|
||
|
||
**Mitigations:**
|
||
|
||
* Receipt includes:
|
||
|
||
* Program hash
|
||
* Input hashes
|
||
* Snapshot ID
|
||
* Receipt signed by authority
|
||
* Deterministic replay possible
|
||
|
||
---
|
||
|
||
### 5.4 Information Disclosure
|
||
|
||
**Threat:**
|
||
Private data leaks from auth host.
|
||
|
||
**Mitigations:**
|
||
|
||
* No shell access to arbitrary tools
|
||
* No network
|
||
* Explicit publish rules
|
||
* Unpublished artifacts never leave host
|
||
* Encrypted blocks allowed in public domains
|
||
|
||
---
|
||
|
||
### 5.5 Denial of Service
|
||
|
||
**Threat:**
|
||
USB floods, huge inputs, malformed PEL.
|
||
|
||
**Mitigations:**
|
||
|
||
* Operator-mediated execution
|
||
* Explicit size limits in manifest
|
||
* Deterministic PEL subset
|
||
* No automatic execution
|
||
|
||
---
|
||
|
||
### 5.6 Elevation of Privilege
|
||
|
||
**Threat:**
|
||
PEL program escapes sandbox or invokes host capabilities.
|
||
|
||
**Mitigations:**
|
||
|
||
* PEL is declarative
|
||
* No exec, no syscalls, no I/O primitives
|
||
* Host enforces operator whitelist of ops
|
||
* Canonical PEL interpreter only
|
||
|
||
---
|
||
|
||
## 6. Specific High-Risk Scenarios
|
||
|
||
### 6.1 Malicious USB with filesystem exploits
|
||
|
||
**Mitigation:**
|
||
|
||
* Mount read-only
|
||
* No traversal outside `/REQUEST`
|
||
* No symlink following
|
||
* No execution from USB
|
||
|
||
---
|
||
|
||
### 6.2 Replay of old admission request
|
||
|
||
**Mitigation:**
|
||
|
||
* `request_id` uniqueness
|
||
* Receipt records snapshot
|
||
* Authority tracks processed request IDs
|
||
|
||
---
|
||
|
||
### 6.3 Confused domain attack
|
||
|
||
**Threat:**
|
||
Attacker attempts to get artifacts bound to wrong domain.
|
||
|
||
**Mitigation:**
|
||
|
||
* Domain ID assigned by authority
|
||
* Domain binding part of receipt hash
|
||
* No requester-supplied domain ID is trusted
|
||
|
||
---
|
||
|
||
### 6.4 Side-channel via timing or output size
|
||
|
||
**Mitigation:**
|
||
|
||
* Coarse-grained execution
|
||
* Deterministic output
|
||
* Optional output padding
|
||
|
||
(Residual risk acknowledged but acceptable.)
|
||
|
||
---
|
||
|
||
## 7. What This Model Explicitly Does *Not* Protect Against
|
||
|
||
| Out of Scope | Reason |
|
||
| --------------------------- | -------------- |
|
||
| Physical compromise of host | Catastrophic |
|
||
| Malicious operator | Social problem |
|
||
| Root key exfiltration | Ends trust |
|
||
| Covert EM attacks | Beyond scope |
|
||
|
||
---
|
||
|
||
## 8. Security Posture Summary
|
||
|
||
**Strengths:**
|
||
|
||
* Minimal attack surface
|
||
* Explicit authority boundaries
|
||
* Deterministic execution
|
||
* Portable, signed truth (PER)
|
||
* No ambient trust
|
||
|
||
**Residual risks:**
|
||
|
||
* Physical compromise
|
||
* Operator error
|
||
* Supply-chain attacks on binaries
|
||
|
||
---
|
||
|
||
## 9. Alignment With Your Design Philosophy
|
||
|
||
This system:
|
||
|
||
* Treats **authority as a press, not a server**
|
||
* Treats **data as artifacts, not files**
|
||
* Treats **execution as a receipt, not a side effect**
|
||
* Treats **trust as explicit and finite**
|
||
|
||
It is **hard to misuse**, **easy to audit**, and **honest about its limits**.
|
||
|
||
---
|
||
|
||
## 10. Recommended Next Documents (in order)
|
||
|
||
1. **PEL canonical encoding spec**
|
||
2. **Receipt canonicalization & hash rules**
|
||
3. **DAM final schema**
|
||
4. **Operator checklist (human protocol)**
|
||
5. **Minimal reference implementation**
|
||
|
||
If you want, next I can write the **operator checklist**, which is often the missing piece that keeps systems like this safe in practice.
|
||
|
||
Just say the word.
|
||
|