Threat Model

This page documents the trust boundaries of AnkaSecure, the adversaries the platform is designed against, and the mitigations in place. It is intended for security architects, compliance officers, and red-team reviewers.

Trust Boundaries

AnkaSecure operates across three trust zones:

Key principle: Long-term key material lives only inside the HSM. AnkaSecure orchestrates operations against the HSM but never persists raw private keys. Compromise of AnkaSecure storage does not yield plaintext keys — wrapping is anchored in the HSM.

Adversaries Considered

A1. Network attacker (passive and active)

Capability: Observe traffic, attempt MITM, replay requests, inject traffic.

Mitigations:

• TLS 1.2/1.3 enforced for every endpoint (HSTS, certificate pinning available)
• Optional ML-KEM transport layer (PQC handshake) for sensitive deployments
• JWT tokens are short-lived, signed and validated on every call (iss, aud, exp, nbf claims required)
• Replay protection via JWT jti and nonce/timestamp checks on streaming uploads

Residual risk: Customer-side TLS interception by the customer's own egress proxy. Out of scope for AnkaSecure.

A2. Malicious tenant (multi-tenant SaaS)

Capability: Authenticated tenant attempting to access another tenant's keys, audit logs, or policies.

Mitigations:

• Tenant ID is bound to JWT claims and validated on every request (no X-Tenant-ID override accepted)
• Database queries are scoped by tenant ID at the JPA layer (@Where clause) — cross-tenant access is rejected at the data layer, not just the controller
• Per-tenant keystores: keys for Tenant A are physically isolated from Tenant B (different HSM partitions or different KEKs)
• Audit logs are tenant-partitioned (HASH PARTITION BY tenant_id)
• Per-tenant rate limits prevent a noisy tenant from starving others

Verification: see Multi-Tenancy & Isolation for cross-tenant access tests that return 403 Forbidden.

Residual risk: A platform admin user with cross-tenant scopes (admin.platform.*) can intentionally access multiple tenants. This is by design for support operations and is itself audited.

A3. Compromised key (single-key compromise)

Capability: An attacker obtains a single key (e.g., through application-layer compromise on the customer side).

Mitigations:

• Composite (hybrid) keys with AND-decrypt semantics: an adversary must break BOTH the classical and the PQC half to recover plaintext. See Composite Hybrid Keys.
• Per-tenant Key Encryption Keys (KEK) in the HSM: even with database access, ciphertext blobs cannot be decrypted without the HSM
• Immediate key rotation API: revoke and replace a key in seconds; downstream applications continue using the same logical key ID
• Re-encryption without exposure: AnkaSecure can re-encrypt existing data from a compromised key to a new key without ever exposing plaintext

Residual risk: Operations performed with the compromised key prior to detection cannot be retroactively undone (audit trail records them).

A4. Downgrade attack against the policy engine

Capability: An attacker tries to force the platform to use a weaker algorithm (e.g., MD5 signatures, RSA-1024) by manipulating request parameters.

Mitigations:

• Algorithm policy is enforced server-side, not client-side. The client requests a key by ID, not by algorithm. The active algorithm is determined by tenant policy.
• Policy is signed and cached with a tamper-evidence mechanism (HMAC envelope in Redis)
• Deprecated algorithms (MD5, SHA-1, RSA <2048) are blacklisted at the cryptographic primitive layer; they cannot be enabled even via direct policy edit without breaking integrity validation
• All policy changes are logged with the actor, timestamp, and previous/new value
• "FIPS-only mode" tenant setting rejects any request that would invoke a non-FIPS-approved primitive

Residual risk: An attacker who compromises the platform admin role can edit policy to enable weaker algorithms going forward (this is logged and detectable).

A5. Compromise of the AnkaSecure control plane

Capability: An attacker gains code execution or database access on the AnkaSecure control plane.

Mitigations:

• Key material is not in the control plane. Long-term keys live in the HSM. The control plane stores only wrapped key references and metadata. Decryption requires HSM cooperation.
• The HSM enforces its own access controls (PKCS#11 PIN/role/quorum). A compromised control plane cannot extract HSM key material; it can only request operations that the HSM authorizes.
• Audit logs are HMAC-signed (9-field canonical format) and replicated to a separate audit store. An attacker rewriting the operational database cannot silently rewrite the audit trail without breaking signatures.
• For SaaS: secrets are stored in Docker Swarm secrets / cloud KMS, not in environment variables. Secrets rotation is supported.
• For on-premise: the customer operates the control plane. The threat surface is the customer's responsibility per the deployment model.

What an attacker who fully owns the control plane CAN do:

• Refuse service (denial of service)
• Use the HSM to perform operations the HSM authorizes for the platform principal (e.g., encrypt new data, sign new artifacts) — but not extract historical keys
• Insert new keys, new policies, new tenants — all of which are audit-logged

What an attacker CANNOT do:

• Recover historical key material (HSM-resident, not exfiltratable by control-plane access)
• Decrypt past traffic stored elsewhere (forward-secrecy via per-session ML-KEM in optional PQC transport)
• Silently modify the audit log (HMAC mismatch detected on read)

Residual risk: Operations performed by the attacker during the compromise window are valid from the HSM's perspective. Detection relies on audit log review and behavioral anomaly detection. Customers operating in high-assurance environments should deploy on-premise and apply their own monitoring on the control-plane host.

A6. Harvest-now-decrypt-later (HNDR)

Capability: A future quantum-capable attacker decrypts data captured today.

Mitigations:

• ML-KEM-768/1024, ML-DSA-65/87, SLH-DSA, FALCON for new keys today
• Re-encryption tooling: existing RSA-encrypted data can be re-encrypted to ML-KEM without decrypting during the transition
• Composite hybrid keys (RSA + ML-KEM with AND-decrypt) for defense-in-depth during the transition period
• Algorithm policy templates aligned with NSA CNSA 2.0 (2030 deadline) and GSA PQC Buyer's Guide

Out of Scope

The following are explicitly outside AnkaSecure's threat model:

• Customer-side application security: SQL injection in the customer's app, XSS, etc. AnkaSecure provides crypto APIs; the customer's application is responsible for its own input validation.
• Endpoint security on customer machines: malware on a developer laptop that steals JWTs is the customer's problem; AnkaSecure provides short-lived tokens and the ability to revoke immediately.
• Physical attacks on the HSM: handled by the HSM vendor's FIPS 140-2/140-3 module certification.
• Quantum cryptanalysis of FIPS 197 AES-256: considered out of scope per NIST guidance (AES-256 is quantum-resistant against Grover's algorithm at sufficient security margin).

Reporting Vulnerabilities

If you believe you have found a vulnerability in AnkaSecure, please email [email protected] with:

• A description of the issue
• Steps to reproduce
• The AnkaSecure version affected
• Your contact information

Please allow up to 90 days for triage and remediation before public disclosure. We do not currently operate a paid bug bounty program, but we credit researchers in release notes.

Last updated: 2026-04-29