Security Model

The SmartPoints security model is built on three trust boundaries, post-quantum cryptography by default, and defense-in-depth through onion routing and federation trust policies.

Three Trust Boundaries

The architecture enforces three concentric trust boundaries:

+--------------------------------------------------+
|  Boundary 3: Network (inter-scope)               |
|  +--------------------------------------------+  |
|  |  Boundary 2: Scope (governance)            |  |
|  |  +--------------------------------------+  |  |
|  |  |  Boundary 1: Kernel (execution)      |  |  |
|  |  |                                      |  |  |
|  |  |  sptos-nucleus, sptos-cap            |  |  |
|  |  +--------------------------------------+  |  |
|  |  sptos-scope, spt-connectors-core       |  |  |
|  +--------------------------------------------+  |
|  spt-wire, spt-wire-bridge, spt-onion          |
+--------------------------------------------------+

Boundary 1: Kernel

The innermost boundary isolates individual kernel instances. Each SPTOS kernel runs with capability-based access control (sptos-cap). No kernel instance can access another's memory, storage, or network without an explicit capability grant.

Key properties:

• Capability-based system calls (no ambient authority)
• Memory isolation via sptos-region
• Formal proofs of capability correctness via sptos-proof
• Secure boot chain via sptos-boot

Boundary 2: Scope

The Scope boundary governs what actors and connectors can do within a governance domain. The ScopePolicy enforces rules on:

• Actor creation and capability assignment
• Connector access and data sharing
• SmartPoint pair creation and revocation
• Resource budget enforcement

A Scope cannot reach into another Scope's resources. Cross-scope communication requires a bilateral SmartPoint pair established through the rendezvous protocol.

Boundary 3: Network

The outermost boundary protects communication between Scopes. Every inter-scope message is:

1. Sealed in a three-layer VectorEnvelope (encrypted + signed)
2. Transported over QUIC authenticated by DIDs via spt-crypto-provider (no X.509/mTLS)
3. Optionally routed through the onion overlay for traffic analysis resistance

Post-Quantum Cryptography

The default crypto suite (pq-v1) uses NIST-standardized post-quantum algorithms:

Function	Algorithm	Standard
Key exchange	ML-KEM-768	FIPS 203
Encryption	ChaCha20-Poly1305	RFC 8439
Signatures	ML-DSA-65	FIPS 204
Hashing	BLAKE3	--

All key material is zeroized on drop via the zeroize crate. Hardware-backed key storage is used when available (Secure Enclave, TPM 2.0).

The spt-pq-crypto crate provides the pure-Rust implementations. The spt-vault crate manages long-term key storage with hardware integration. The spt-crypto-provider crate wraps these into a rustls::crypto::CryptoProvider for QUIC authentication.

DID-Based QUIC Authentication (spt-crypto-provider)

ADR-101 replaced mTLS (X.509 certificates) with DID-based authentication for all QUIC connections. The spt-crypto-provider crate implements:

• SptCryptoProvider -- a rustls::crypto::CryptoProvider that uses ML-KEM-768 for key exchange and ML-DSA-65 for signatures
• DidVerifier -- a custom ClientCertVerifier / ServerCertVerifier that validates DIDs against the GIC Merkle DAG
• Raw Public Keys (RFC 7250) -- DID + public key encoded as raw public key certificates, eliminating the need for X.509 certificate authorities

DidVerifier authentication flow:

1. Extract DID and public key from the Raw Public Key certificate presented during QUIC handshake
2. Resolve the DID against the Global Identity Chain (GIC)
3. Verify the key is registered and not revoked
4. Check the hardware trust tier (se > tpm > sb > tee > sw) meets the Scope's minimum requirement
5. Return authenticated if all checks pass

This design eliminates certificate authorities, certificate rotation, and the entire X.509 PKI. Identity is sovereign and hardware-rooted.

Trust Boundary Diagram

+--------------------------------------------------+
|  Boundary 3: Network (inter-scope)               |
|  DID-authenticated QUIC (spt-crypto-provider)    |
|  +--------------------------------------------+  |
|  |  Boundary 2: Scope (governance)            |  |
|  |  +--------------------------------------+  |  |
|  |  |  Boundary 1: Kernel (execution)      |  |  |
|  |  |                                      |  |  |
|  |  |  sptos-nucleus, sptos-cap            |  |  |
|  |  +--------------------------------------+  |  |
|  |  sptos-scope, spt-connectors-core       |  |  |
|  +--------------------------------------------+  |
|  spt-wire, spt-wire-bridge, spt-onion          |
+--------------------------------------------------+

Crypto Suite Agility

The CryptoSuite enum allows algorithm migration without protocol changes. The suite ID is embedded in every envelope, so old and new suites can coexist during a migration window.

Onion Routing

The spt-onion crate provides multi-hop onion routing for traffic analysis resistance. When enabled, vectors are wrapped in multiple encryption layers and relayed through intermediate nodes before reaching the destination.

Properties:

• Each relay peels one layer of encryption
• No single relay knows both sender and recipient
• Route selection is configurable (random, geographic, trust-based)
• Compatible with the standard VectorEnvelope format

Dark Overlay

The spt-dark crate provides a privacy-focused overlay network for scenarios requiring stronger anonymity guarantees. It combines onion routing with cover traffic and timing obfuscation.

Federation Trust Policies

The spt-federation crate manages trust relationships between Scopes across organizational boundaries. Federation enables:

• Cross-org SmartPoint pairs: Two organizations can form pairs with negotiated policies
• Trust levels: Full trust, limited trust (specific capabilities only), or untrusted
• Policy propagation: Parent organizations can set baseline policies for child Scopes
• Revocation: Federation agreements can be revoked, triggering pair dissolution

Advisory vs Control Plane

Federation operates on two planes:

Plane	Purpose	Binding
Advisory	Recommendations, warnings, reputation sharing	Non-binding
Control	Policy enforcement, capability grants, revocations	Binding

The advisory plane shares reputation data and security advisories between federated Scopes. The control plane enforces hard policy constraints (e.g., minimum crypto suite, maximum TTL, required compliance attestations).

Hardware Trust Tiers

Identity DIDs encode the hardware trust level of their key material:

Tier	Label	Hardware	Security Level
1	se	Apple Secure Enclave	Highest
2	tpm	TPM 2.0	High
3	sb	Android StrongBox	High
4	tee	Trusted Execution Environment	Medium
5	sw	Software-only	Baseline

Scopes can set minimum trust tier requirements in their policies. For example, a financial services Scope might require Tier 1 or Tier 2 for all actors.

Security Checklist for Developers

When implementing features that touch the security model:

1. Use CryptoSuite::PqV1 as the default unless there is a specific interoperability requirement
2. Never store raw key material in non-zeroizing types
3. Always validate inbound sequence numbers for replay protection
4. Verify the terms hash on every envelope open
5. Use the rendezvous protocol for cross-scope pair formation (never form pairs directly)
6. Run cargo test in the relevant crate to verify security property tests pass
7. Ensure all new vertex types in the AIC have corresponding revocation logic

Key Types

Type	Crate	Description
SptCryptoProvider	spt-crypto-provider	rustls CryptoProvider with ML-KEM/ML-DSA
DidVerifier	spt-crypto-provider	DID-based QUIC authentication against GIC
CryptoSuite	spt-smartpoint	Algorithm suite selector
VectorEnvelope	spt-smartpoint	Three-layer sealed message
ScopePolicy	sptos-scope	Governance rules
MerkleDag	spt-aic	Identity event ledger
CircuitBreaker	spt-marketplace	Budget protection
PlatformKeyStore	sptos-host-core	Hardware key storage trait