amduat-api/notes/ASL-AUTH-HOST v0-1 - Threat Model.md

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.