Security Model Threat Analysis & Mitigations

Comprehensive analysis of security threats, cryptographic mitigations, and the enforcement boundary that protects agent authority.

Core Security Principle

Exqub transforms agent authority from configuration into cryptographic commitments. Every permission, spending limit, and capability becomes a signed, verifiable object that cannot be escalated or forged.

Authority = Cryptographic_Signature(Scope, Limits, Time_Bounds)

Threat Model

Threat Attack Vector Mitigation Residual Risk
Credential Forgery Create fake credentials ML-DSA-65 signatures (128-bit quantum security) None with current technology
Privilege Escalation Modify credential attributes Merkle tree cryptographically binds all attributes None
Replay Attack Reuse captured presentations Verifier nonce + device co-signature None
Credential Theft Steal and use credentials Device binding (requires private key) Device compromise
Quantum Attack Break classical signatures ML-DSA-65 (NIST PQC standard) None known
DoS Attack Overwhelm verifier Early rejection, cheap checks first Network-level DoS
Revocation Bypass Use revoked credentials SMT proofs, monotonic snapshots Snapshot lag (minutes)
Scope Widening Sub-delegate with broader scope than parent Monotonic scope attenuation + scope_hash verification None
Delegation Chain Abuse Forge delegation chain links Per-link ML-DSA-65 signatures, depth limit (5), cascade revocation None

Critical: The Enforcement Boundary

⚠️

Important Limitation

Exqub credentials attest scope and the verifier enforces it. If a backend service does not embed the verifier SDK, the credential cannot prevent unauthorized actions.

The TLS Analogy

This is analogous to TLS: the protocol secures the channel, but only if the server requires it. A server that accepts plaintext HTTP connections bypasses all TLS security guarantees.

Without Verifier
  • • Agent presents credential (ignored)
  • • Service processes request anyway
  • • No authority enforcement
  • • Blast radius unlimited
With Verifier
  • • Agent presents credential
  • • Verifier checks scope/limits
  • • Request rejected if exceeds authority
  • • Blast radius cryptographically bounded

Device Binding: Defense in Depth

How It Works

  1. 1. Issuance: Credential includes holder's ML-DSA-65 public key
  2. 2. Binding: Issuer signs over device key (cannot be changed)
  3. 3. Presentation: Holder co-signs with private key + nonce
  4. 4. Verification: Both signatures must validate

What It Prevents

  • × Credential theft: Stolen credential useless without device private key
  • × Replay attacks: Each presentation needs fresh nonce signature
  • × Man-in-the-middle: Cannot modify or proxy presentations

Comparison with Other Systems

Exqub

Mandatory device binding on every credential and presentation

SD-JWT

Optional key binding, often skipped in implementations

W3C VC + BBS+

No device binding in standard, relies on transport security

DoS-Resistant Verification

The verification pipeline is carefully ordered to reject invalid credentials with minimal computational cost:

0.1ms

Structural Validation

Check CBOR format, field presence, type validity. Reject malformed data immediately.

0.01ms

Expiry Check

Simple timestamp comparison. Reject expired credentials before any crypto operations.

1ms

Revocation Check

SMT proof verification. Still cheap compared to signature verification.

~288µs

Signature Verification (×2)

ML-DSA-65 verification for issuer and device signatures (~144µs each). Most expensive operations last.

Result: Invalid credentials rejected in microseconds. Valid credentials verified in ~301µs on native hardware (~1–4ms on WASM). Attackers cannot exhaust CPU with signature operations.

Post-Quantum Cryptography

Why It Matters for Agents

Agent credentials persist in audit trails for decades. Financial transactions, healthcare decisions, and legal agreements signed by agents today will need to remain verifiable through 2050 and beyond.

A credential signed with ECDSA today could be retroactively forged by a quantum computer in 2035, invalidating years of audit history and destroying non-repudiation guarantees.

ML-DSA-65 (FIPS 204)

  • Security Level: 128-bit quantum
  • Signature Size: 3,309 bytes
  • Public Key Size: 1,952 bytes
  • Verification Time: ~144µs
  • Standard: NIST FIPS 204

Implementation Best Practices

For Issuers

  • ✓ Use hardware security modules for issuer keys
  • ✓ Implement strict credential type schemas
  • ✓ Publish revocation snapshots every 5 minutes
  • ✓ Log all credential issuance for audit
  • ✓ Rotate issuer keys annually

For Verifiers

  • ✓ Always check revocation before accepting
  • ✓ Generate fresh nonces for each verification
  • ✓ Cache revocation snapshots (5-minute TTL)
  • ✓ Implement rate limiting per credential
  • ✓ Log all verification attempts

For Holders (Agents)

  • ✓ Store device keys in secure enclaves
  • ✓ Never share device private keys
  • ✓ Minimize attribute disclosure
  • ✓ Refresh credentials before expiry
  • ✓ Implement credential rotation policies

For Integrators

  • ✓ Embed verifier in every service endpoint
  • ✓ Map credential types to authorization policies
  • ✓ Implement graceful degradation
  • ✓ Monitor verification performance
  • ✓ Plan for PQC migration timeline