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.