QODIQA Security and Cryptographic Profile
for Runtime Consent Enforcement

#Purpose and Security Scope

QODIQA Core v1.0 defines a deterministic consent enforcement layer for AI runtime systems. This Security and Cryptographic Profile extends that standard by specifying the cryptographic substrate required to make QODIQA's deterministic properties tamper-resistant, verifiable, and auditable under adversarial conditions.

1.1 Scope of This Profile

This profile governs the security requirements applicable to the QODIQA enforcement layer — specifically the runtime components responsible for consent token issuance, artifact production, policy evaluation, registry consultation, and audit ledger maintenance. It applies to all software, hardware, and operational components that implement or host QODIQA enforcement functions.

1.2 Relationship to Core Standard

QODIQA Core v1.0 defines the logical architecture of enforcement: consent gates, frozen evaluation contexts, decision artifacts, replay verification, and fail-closed semantics. This profile defines the cryptographic mechanisms that make those logical properties provably enforceable. Where Core defines what must be enforced, this profile defines how that enforcement must be anchored.

1.3 Relationship to Conformance Test Suite

The Conformance Test Suite references this profile for cryptographic verification test cases. Implementations that pass all Core conformance tests but fail cryptographic profile requirements SHALL be classified as non-conformant at any profile level above Baseline Security.

1.4 System Under Protection

Components external to the above SUP definitions — including model weights, inference engines, application-layer logic, and data stores — are out of scope for this profile's cryptographic requirements.

#Threat Model Definition

The following threat categories represent realistic, high-impact adversarial scenarios against the QODIQA enforcement layer. All are grounded in known attack classes against cryptographic infrastructure, distributed systems, and audit mechanisms. Speculative or theoretical threats are excluded.

#Security Invariants

The following invariants are formal properties that MUST hold at all times across all conformant implementations of the QODIQA enforcement layer. An invariant violation is not a configuration error — it is an integrity failure. Any condition that causes an invariant to be false MUST trigger an integrity violation event, a fail-closed enforcement state, and an audit ledger entry recording the breach.

These invariants are not derived from policy preferences. They are derived from the structural requirements of deterministic, verifiable, tamper-resistant consent enforcement. They hold regardless of deployment profile tier.

// INV-01: Artifact Signature Invariant
∀ artifact ∈ ARTIFACT_STORE:
  artifact.signature IS VALID
  ∧ artifact.signing_key ∈ TRUST_REGISTRY
  ∧ artifact.signing_key.status = ACTIVE
  → INVARIANT: No unsigned or unverifiable artifact SHALL exist

// INV-02: Write-Before-Execute Invariant
∀ decision ∈ {PERMIT, DENY}:
  LEDGER.contains(decision.ledger_entry) = TRUE
  ∧ LEDGER.committed(decision.ledger_entry) = TRUE
  ∧ decision.ledger_entry.timestamp ≤ decision.response_timestamp
  → INVARIANT: No PERMIT response SHALL be returned before its ledger entry is committed

// INV-03: Registry Validation Invariant
∀ token ∈ PRESENTED_TOKENS:
  REGISTRY.consulted(token.kid) = TRUE
  ∧ REGISTRY.snapshot_age ≤ CONFIGURED_TTL
  → INVARIANT: No valid token SHALL bypass live registry validation

// INV-04: Revocation Invariant
∀ key ∈ REVOKED_KEYS:
  ¬∃ token: VERIFY(token.sig, key) = ACCEPTED
  → INVARIANT: No revoked key SHALL produce an accepted signature

// INV-05: Clock Certainty Invariant
∀ enforcement_decision:
  CLOCK.sync_error ≤ PROFILE.drift_tolerance
  ∧ CLOCK.source = AUTHENTICATED_NTP | GPS | PTP
  → INVARIANT: No enforcement decision SHALL execute under clock uncertainty exceeding tolerance

// INV-06: Deterministic Evaluation Invariant
∀ evaluation_invocation:
  evaluation.external_callouts = ∅
  ∧ evaluation.random_in_path = FALSE
  ∧ evaluation.context = FROZEN
  → INVARIANT: No enforcement decision SHALL execute without a deterministic evaluation path

// INV-07: Artifact Chain Invariant
∀ artifact_n ∈ ARTIFACT_STORE:
  artifact_n.prev_artifact_id = SHA256(artifact_{n-1})
  ∨ (n = 0 ∧ artifact_n.prev_artifact_id = ZERO_BYTES_32)
  → INVARIANT: The artifact hash chain MUST be unbroken from genesis

#Attack Surface Mapping

Each SUP component defined in Section 1.4 presents a discrete attack surface. The following table maps each component to its primary attack vectors, associated threat class, normative mitigation control, and the enforcement point at which the control is applied. This mapping is structural: it does not add requirements beyond those stated in the corresponding normative sections. It exists to provide a deterministic traceability reference between threat classes and controls.

#Failure Mode Enumeration and Deterministic Response

Failure modes are conditions under which one or more security invariants defined in Section 2.1 cannot be satisfied. For each failure mode, the system response MUST be deterministic and fail-closed. No failure mode permits a PERMIT decision to be issued when the condition rendering the enforcement environment unverifiable remains unresolved. The following table enumerates the primary failure conditions, their detection mechanisms, required system responses, enforcement outcomes, and audit obligations.

#Cryptographic Algorithm Requirements

3.1 Approved Signature Algorithms

Implementations SHALL use only the following signature algorithms for consent token signing, registry snapshot signing, and audit chain anchoring. Algorithm selection MUST be recorded in the implementation's cryptographic configuration manifest.

3.2 Hashing Algorithms

3.3 Forbidden Algorithms

The following algorithms are unconditionally forbidden in all QODIQA implementations regardless of deployment context, legacy compatibility claims, or performance justifications. No conformance exception is available for these prohibitions.

3.4 Cryptographic Agility and Deprecation Model

Cryptographic algorithms are subject to continuous cryptanalytic pressure. A static algorithm selection, however conservative at time of adoption, requires a structured lifecycle to remain valid over time. This section defines the mandatory review, deprecation, and migration framework for all algorithms approved under Section 3.

Algorithm Deprecation Lifecycle

3.4.1 Emergency Algorithm Withdrawal

In the event of a critical cryptographic break — defined as a publicly demonstrated attack reducing effective security below 80-bit equivalent — the affected algorithm SHALL be withdrawn immediately, bypassing the staged deprecation lifecycle. Emergency withdrawal SHALL: (1) add the algorithm to the forbidden list within 48 hours of NIST or equivalent advisory publication; (2) trigger the Key Compromise Response procedure (Section 13.1) for all keys using the affected algorithm; (3) require immediate dual-signature transition for any artifacts produced under the withdrawn algorithm.

3.4.2 Dual-Signature Transition Model

During algorithm migration from a Stage 2 (Restricted) algorithm to an approved replacement, implementations MUST employ a dual-signature transition period. During this period, consent tokens, registry snapshots, and audit ledger anchors SHALL carry signatures from both the outgoing algorithm and the replacement algorithm. A verifying enforcement gate MUST accept a token as valid only if BOTH signatures verify correctly against their respective keys. This period SHALL terminate when all enforcement gates in the deployment have confirmed support for the replacement algorithm exclusively.

// Phase 0: Detection — algorithm enters Stage 1 (WARNING)
ADVISORY_ISSUED(algorithm_id)
→ document_migration_plan()
→ identify_replacement_algorithm()  // MUST be from approved list Section 3.1

// Phase 1: Preparation — algorithm enters Stage 2 (RESTRICTED)
generate_replacement_keypair()      // in HSM
publish_replacement_key_to_registry()
configure_dual_sig_mode()

// Phase 2: Dual-Signature Active
for each token | snapshot | anchor:
  sig_legacy    = SIGN(payload, outgoing_key)
  sig_new       = SIGN(payload, replacement_key)
  token.signatures = [sig_legacy, sig_new]

// Phase 2 verification requirement
assert VERIFY(sig_legacy, payload, outgoing_pubkey) = TRUE
assert VERIFY(sig_new,    payload, replacement_pubkey) = TRUE
if either fails → DENY

// Phase 3: Cutover — all gates confirm replacement support
when ALL_GATES.replacement_verified() = TRUE:
  disable_legacy_sig_generation()
  outgoing_key → REVOKE
  algorithm_id → PROHIBITED (Stage 3)

// Phase 4: Post-migration validation
assert ARTIFACT_STORE.no_active_outgoing_sigs() = TRUE
run_full_conformance_suite()

#Consent Token Structure Security

Consent tokens are the primary credential presented to the QODIQA enforcement gate. Their cryptographic integrity is the first line of defense against consent forgery and replay manipulation. The following requirements define the minimum structural and cryptographic properties for all conformant consent tokens.

4.1 Canonical Serialization

Token payloads MUST be canonically serialized prior to signing. Canonical serialization eliminates signature malleability arising from equivalent representations of the same semantic content. Implementations SHALL use JSON Canonicalization Scheme (JCS, RFC 8785) or a formally specified binary serialization format documented in the implementation's cryptographic configuration manifest.

4.2 Required Token Claims

4.3 Deterministic Verification Sequence

The enforcement gate MUST execute token verification in the following deterministic sequence. Deviation from this sequence SHALL be treated as a verification failure, producing a DENY decision.

// Step 1: Structural validation
assert token.iss IS PRESENT AND RESOLVES
assert token.sub IS PRESENT
assert token.scope IS PRESENT AND NON-EMPTY
assert token.iat, token.exp, token.kid, token.jti ARE PRESENT

// Step 2: Key resolution
public_key = REGISTRY.resolve_key(token.kid)
if public_key IS NULL OR REVOKED → DENY

// Step 3: Signature verification
canonical = JCS(token.claims)
if not VERIFY(token.sig, canonical, public_key) → DENY

// Step 4: Temporal validation
now = MONOTONIC_CLOCK.now()
if now < token.iat - DRIFT_TOLERANCE → DENY
if now > token.exp → DENY

// Step 5: Anti-replay (Hardened + High-Assurance)
if JTI_CACHE.contains(token.jti) → DENY
JTI_CACHE.add(token.jti, ttl=token.exp)

// Step 6: Context hash verification
expected_ctx = SHA256(FROZEN_CONTEXT.canonical())
if token.ctx_hash != expected_ctx → DENY

// Step 7: Scope authorization
if not POLICY.permits(token.scope, REQUEST.operation) → DENY

// All checks passed
→ PERMIT

4.4 Maximum Token Lifetime by Profile

4.5 Distributed Replay Protection Model

In deployments where multiple enforcement gate nodes operate concurrently — whether in active-active clusters, federated deployments, or geographically distributed configurations — single-node JTI cache semantics are insufficient. A token accepted by one node and rejected by another creates an inconsistent enforcement posture exploitable for replay. The following requirements define cluster-wide replay protection semantics.

// Single-node flow (Baseline only)
if CLUSTER_SIZE = 1:
  if LOCAL_JTI_CACHE.contains(token.jti) → DENY
  LOCAL_JTI_CACHE.add(token.jti, ttl=token.exp)

// Cluster flow (Hardened and High-Assurance — MUST)
if CLUSTER_SIZE > 1:

  // Step 1: Verify cache reachability
  if not CLUSTER_JTI_CACHE.reachable() → DENY + ALERT

  // Step 2: Atomic check-and-set with linearizable consistency
  result = CLUSTER_JTI_CACHE.set_if_absent(
    key   = token.jti,
    value = { gate_id, timestamp: NOW() },
    ttl   = min(token.exp - token.iat, 2 * PROFILE.registry_ttl),
    consistency = LINEARIZABLE
  )
  if result = ALREADY_EXISTS → DENY   // replay detected
  if result = WRITE_FAILED  → DENY   // fail-closed on uncertainty

  // Step 3: Verify replication lag is within bound
  if CLUSTER_JTI_CACHE.replication_lag() > PROFILE.registry_ttl:
    ALERT(severity=HIGH, event="JTI_REPLICATION_LAG_EXCEEDED")
    → DENY   // SHOULD for Hardened; MUST for High-Assurance

  // Step 4: Commit ledger entry (linearizable, before PERMIT)
  LEDGER.write_commit(decision_entry)   // fail-closed if write fails

→ PERMIT   // only after both JTI cache and ledger are committed

#Trust Anchor and Key Management Model

5.1 Root Trust Anchor Model

The QODIQA trust model is anchored in a verifiable public key registry. Each signing key used to issue consent tokens MUST be traceable to a root trust anchor through a verifiable chain. Self-signed tokens with no trust chain are unconditionally rejected.

5.2 Key Rotation Requirements

5.3 Key Compromise Response

In the event of confirmed or suspected private key compromise, the following actions MUST be executed in order. No deviation from this sequence is permitted.

5.4 Public Key Discovery

Public keys MUST be discoverable through a signed key manifest served over TLS 1.3. The key manifest MUST include each key's kid, algorithm identifier, active status, rotation schedule, and validity period. Key manifests MUST themselves be signed by the root trust anchor.

#High-Assurance Key Management Model

At the High-Assurance deployment profile, key management is not a configuration decision — it is a structural requirement. The following subsection defines the mandatory key hierarchy, offline root anchor requirement, quorum activation model, key ceremony obligation, and blast radius containment model that collectively constitute the High-Assurance key management architecture. These requirements extend and make concrete the normative controls established in SEC-KEY-01 through SEC-KEY-03.

5.5.1 Key Hierarchy: Root, Intermediate, and Issuer Separation

The QODIQA High-Assurance key hierarchy MUST be structured as a three-tier chain. The Root Trust Anchor is the ultimate trust source and MUST NOT be used for day-to-day signing operations. The Intermediate Signing Authority is an HSM-resident key used to authorize issuer keys and to sign key manifests. The Consent Token Issuer is the operational signing key whose public key is published in the trust registry and whose private counterpart signs consent tokens at runtime. This tier separation ensures that compromise of any operational key does not transitively compromise the root, and that blast radius is bounded to the scope of the compromised tier.

5.5.2 Offline Root Key Requirement

The Root Trust Anchor private key MUST be stored offline. An offline root key is one that is not connected to any network, is not accessible from any running system, and is only activated through a formal key ceremony procedure under dual-control conditions. The offline root key MUST be used only to: sign the intermediate key at initial deployment, rotate the intermediate key on its scheduled rotation interval, and respond to confirmed intermediate key compromise. All other signing operations MUST use the intermediate or issuer tier keys.

5.5.3 Dual Control and Quorum Requirement

All root key operations — including generation, activation, signing, rotation, and destruction — MUST require a minimum quorum of two authorized personnel, each presenting independent authentication credentials. The quorum MUST be enforced at the HSM hardware level. No software-layer access control satisfies this requirement in substitution for hardware-enforced quorum. The quorum size MUST be documented in the implementation's key management policy and verified as part of conformance assessment.

5.5.4 Key Ceremony Requirement

Initial generation of the Root Trust Anchor key and each new intermediate key MUST be performed as a formal key ceremony. A key ceremony is a documented, witnessed procedure in which: the HSM is in a known-clean state verified before the ceremony begins; all ceremony participants are authenticated and their identities are recorded; the generation procedure is executed according to a pre-approved script; the generated key is verified to be non-exportable; and a signed ceremony record is produced and retained as part of the implementation's security configuration record. The ceremony record MUST be retained for the lifetime of the key plus 7 years.

5.5.5 Blast Radius Containment

The three-tier key hierarchy is designed to contain the operational impact of key compromise. Compromise of an issuer key requires immediate revocation of that key and rotation to a new issuer key, but does not invalidate the intermediate or root tier. Compromise of the intermediate key requires rotation of all issuer keys authorized under it, but does not require root key replacement provided the root key remains uncompromised and offline. Compromise of the root key constitutes a full trust anchor failure requiring a complete key hierarchy rebuild under new ceremonies. Implementations MUST document the blast radius for each tier in their security configuration record.

#Revocation Registry Security

The revocation registry is a critical component of the QODIQA enforcement layer. Its integrity directly determines whether revoked consents can be re-presented fraudulently. The following requirements govern its protection.

6.1 Anti-Downgrade Protection

The enforcement gate MUST verify that the registry snapshot sequence number presented is equal to or greater than the highest sequence number previously observed. A snapshot with a lower sequence number than the locally stored high-water mark SHALL be rejected as a potential downgrade attack.

6.2 Registry Authenticity Verification

On each registry read, the enforcement gate MUST: (1) verify the snapshot signature against the registry root public key; (2) verify hash chain continuity from the previous accepted snapshot; (3) verify sequence number monotonicity; (4) verify timestamp recency within configured TTL bounds. Failure of any verification step MUST produce a registry consultation failure, triggering fail-closed behavior.

#Artifact Hashing and Integrity Model

Decision Artifacts are the cryptographically bound records of enforcement decisions produced by the QODIQA consent gate. Their integrity guarantees the verifiability of the Replay Invariant defined in QODIQA Core v1.0. The following specifies the canonical artifact hash model.

7.1 Formal Artifact Hash Model

// Canonical artifact hash construction
artifact_id = SHA-256(
    canonical_context  // JCS-serialized frozen evaluation context
  || decision          // "PERMIT" | "DENY" (UTF-8 encoded)
  || policy_version    // policy document hash at evaluation time
  || consent_ref       // token jti or stable consent identifier
  || timestamp         // enforcement timestamp (monotonic, Unix epoch, 8 bytes)
  || prev_artifact_id  // SHA-256 of preceding artifact (hash chain)
  || model_binary_hash // SHA-256 of model binary at enforcement time
                       // MUST: High-Assurance | SHOULD: Hardened | OPTIONAL: Baseline
                       // When absent in Baseline/Hardened: substitute ZERO_BYTES_32
)

// Policy version component
policy_version = SHA-256(policy_document_canonical)

// Canonical context component
canonical_context = SHA-256(JCS({
  model_id, model_version, operation_id,
  subject_id, scope, data_classification,
  enforcement_gate_id, environment_fingerprint
}))

// Model binary hash component
model_binary_hash = SHA-256(model_binary_content)
// model_binary_content = the exact byte sequence of the model file(s)
// at the time enforcement is invoked. Multi-file models: SHA-256(SHA-256(file_1)
// || SHA-256(file_2) || ... || SHA-256(file_n)) in deterministic sort order.
// Implementations MUST pre-compute and cache this value at model load time.
// model_binary_hash MUST be recomputed upon any model reload or version change.

7.2 Replay Verification via Artifact Hash

To verify that a historical enforcement decision is reproducible under the same conditions, a verifier SHALL: (1) reconstruct the canonical context from available records; (2) recompute the artifact hash using the same formula; (3) compare against the stored artifact ID. A mismatch indicates either context drift, context manipulation, or artifact tampering — all of which constitute enforcement integrity violations.

#Audit Ledger Integrity Requirements

8.1 Hash Chain Format

The audit ledger MUST be maintained as a hash chain. Each ledger entry MUST include the SHA-256 hash of the preceding entry, forming an unbroken sequence from ledger initialization. The ledger chain provides tamper evidence: any modification to a historical entry invalidates all subsequent entry hashes.

ledger_entry = {
  seq_num:        uint64,          // monotonically increasing
  timestamp:      unix_epoch_ns,   // nanosecond precision, monotonic clock
  event_type:     "PERMIT" | "DENY" | "REVOCATION" | "KEY_ROTATION" | "INTEGRITY_VIOLATION",
  artifact_id:    bytes32,         // SHA-256 of Decision Artifact
  gate_id:        string,          // enforcement gate identifier
  subject_hash:   bytes32,         // SHA-256 of subject_id (privacy-preserving)
  prev_entry_hash:bytes32,         // SHA-256 of preceding ledger entry
  entry_sig:      bytes            // Ed25519 signature over canonical entry
}

entry_hash = SHA-256(canonical(ledger_entry_without_entry_sig))

8.2 Append-Only Storage

The audit ledger storage backend MUST enforce append-only semantics. The storage system MUST prevent modification or deletion of any existing ledger entry through all available interfaces. At the Hardened and High-Assurance profiles, the ledger MUST be replicated to a minimum of two geographically or logically separated storage backends.

8.3 Tamper Detection

A tamper detection procedure MUST be executable on demand and MUST run automatically at a frequency no less than the Ledger Integrity Verification interval for the applicable profile (Baseline: 24h; Hardened: 1h; High-Assurance: 15min). The procedure SHALL verify: hash chain continuity, signature validity for each entry, sequence number monotonicity, and timestamp monotonicity.

8.4 Archival Requirements

Audit ledger entries MUST be retained for a minimum of 7 years. Archived entries MUST retain their hash chain continuity with active entries. Archival storage MUST maintain integrity verification capability equivalent to active storage.

#Time and Clock Security

Temporal integrity is a foundational property of the QODIQA enforcement layer. Token expiry, artifact timestamps, audit ledger ordering, and TTL enforcement all depend on reliable, manipulation-resistant time. The following requirements govern clock security at all profile levels.

When clock synchronization error exceeds the configured drift tolerance for the applicable profile, the enforcement gate MUST enter fail-closed state for all decisions requiring temporal validation. The gate MUST remain in fail-closed state until synchronization is restored and verified.

#Network and Transport Security Requirements

10.1 Certificate Validation

All TLS connections to registry, audit log, and key management endpoints MUST perform full certificate chain validation including revocation checking (OCSP or CRL). Certificate pinning SHOULD be implemented for registry and key management endpoints at Hardened and High-Assurance profiles. Self-signed certificates MUST NOT be trusted in production enforcement environments.

10.2 Mutual TLS

Mutual TLS (mTLS) authentication SHOULD be implemented for all inter-component communications within the QODIQA enforcement layer at Hardened profile, and MUST be implemented at High-Assurance profile. Client certificate validation MUST follow the same chain validation and revocation checking requirements as server certificate validation.

#Performance and Latency Constraints

The enforcement operations defined in this profile introduce measurable latency at each stage of the consent evaluation path. This section enumerates the primary latency contributors at each SUP component. It does not provide optimization guidance and does not authorize any weakening of normative requirements on the basis of performance considerations. Performance constraints are enumerated here to ensure that implementations plan for and account for the operational cost of enforcement, not to create grounds for bypassing enforcement controls.

Every operation listed in the table below is a normative requirement of this profile or of QODIQA Core v1.0. The latency it introduces is an inherent property of verifiable enforcement. No conformant implementation may eliminate any listed operation in the name of performance without simultaneously creating a conformance failure.

This profile defines deterministic enforcement constraints that SHALL NOT be bypassed, relaxed, or conditionally disabled for performance optimization under any deployment scenario.

#Side-Channel and Non-Deterministic Risk Mitigation

The QODIQA enforcement gate is a deterministic decision function. Its determinism is a specification requirement, not an implementation preference. The following requirements protect this property from erosion through side-channels, non-deterministic dependencies, and evaluation contamination.

11.1 Evaluation Function Isolation

The enforcement gate's policy evaluation function MUST be isolated from external network callouts, file system reads, database queries, and inter-process communication during the evaluation window. Any external dependency required for evaluation (policy document, registry state) MUST be resolved before the evaluation window opens and frozen in the evaluation context.

11.2 Dependency Isolation Rules

• No outbound network calls during the enforcement evaluation window.
• No reads from mutable file system paths during the evaluation window.
• No shared mutable state between concurrent evaluation invocations.
• No JIT compilation or dynamic code loading within the evaluation function.
• No access to environment variables within the evaluation function.
• Evaluation function dependencies MUST be resolved, validated, and immutably bound before evaluation begins.

11.3 Constant-Time Comparison

All cryptographic comparisons within the enforcement gate — including signature verification results, hash comparisons, and token claim validation — MUST use constant-time comparison functions where the compared values could reveal information through timing side-channels. Variable-time string comparison functions (e.g., strcmp, operator == on byte arrays) MUST NOT be used for security-sensitive comparisons.

#Secure Deployment Profiles

Three tiered security deployment profiles are defined. Each tier inherits all requirements of the preceding tier and adds incremental cryptographic and operational constraints. Profile selection MUST be documented in the implementation's security configuration manifest and verified by conformance testing.

#Compromise and Incident Response Model

The following response procedures are mandatory for the categories of security events most likely to affect QODIQA enforcement layer integrity. These procedures are procedural requirements, not legal guidance.

13.1 Key Compromise Response

• Immediately revoke the compromised key in the registry within the Emergency Rotation SLA for the applicable profile.
• Propagate revocation to all enforcement gates before issuing replacement key. Verify propagation through active monitoring.
• Flag all Decision Artifacts produced under the compromised key as requiring manual integrity review.
• Generate replacement key in HSM or secure enclave. Assign a new, distinct key identifier. Do not reuse any attribute of the compromised key entry.
• Notify QODIQA certification authority within 24 hours if the implementation holds a QODIQA certification.
• Produce a Post-Incident Report (PIR) within 72 hours identifying root cause, timeline, and remediation actions.

13.2 Registry Compromise Response

• Immediately suspend enforcement gate operations. Enter fail-closed DENY-ALL state.
• Restore registry from the most recent verified signed snapshot. Validate hash chain continuity from restoration point.
• Verify snapshot signature authenticity before restoration. Do not restore from an unsigned or unverifiable snapshot.
• Audit all enforcement decisions made between the last verified snapshot and the compromise detection point. Flag as requiring manual review.
• Rotate registry signing keys as per the Key Compromise Response procedure above.

13.3 Artifact Mismatch Detection Response

When replay verification produces a hash mismatch — i.e., the recomputed artifact hash does not match the stored artifact ID — the following response SHALL be initiated: (1) the mismatched artifact is quarantined and flagged for investigation; (2) an integrity violation event is written to the audit ledger; (3) any active enforcement session associated with the artifact is terminated; (4) the incident is escalated for forensic review. Mismatches SHALL NOT be silently discarded or treated as benign data drift.

13.4 Audit Chain Corruption Procedure

If tamper detection identifies a broken audit chain (hash discontinuity), the following procedure applies: (1) isolate the enforcement gate to prevent further audit writes; (2) preserve a forensic copy of the current ledger state; (3) identify the last valid hash chain segment; (4) restore from the last verified archive checkpoint; (5) recover entries between the checkpoint and compromise point from secondary replicas if available; (6) document the corrupted segment in the restoration metadata. Under no circumstances SHALL a repaired audit chain suppress evidence of the tampering event itself.

#Non-Coverage Disclosure

This profile explicitly delimits its scope. The following classes of security concern are outside the boundary of this document. Transparency on these exclusions is essential to prevent misrepresentation of QODIQA's security posture.

Organizations deploying QODIQA enforcement infrastructure MUST treat this profile as one component of a broader security architecture. The enforcement layer's cryptographic guarantees apply only within the System Under Protection boundary defined in Section 1.4. Security properties outside that boundary require independent architectural controls.

14.1 Additional AI-Specific Exclusions

The following classes of concern are explicitly outside the scope of this Security and Cryptographic Profile. They are enumerated separately because they arise specifically in the context of AI systems and may be incorrectly attributed to this profile's scope in architectural or compliance contexts. No requirement in this document addresses, mitigates, or characterizes any of the following.

These exclusions are permanent and apply at all deployment profile tiers. Conformance with this profile does not imply any guarantee regarding the above properties.

#Institutional Closing Statement

Deterministic consent enforcement is not a statement of policy. It is a runtime guarantee. A guarantee is only as strong as the cryptographic substrate that anchors it. Without signature binding, hash-chained audit integrity, revocation registry protection, and clock security, the QODIQA enforcement model remains logically sound but operationally falsifiable.

This profile does not introduce new enforcement semantics. It specifies the minimum cryptographic conditions under which QODIQA Core v1.0's enforcement semantics — determinism, fail-closed behavior, replay verifiability, audit immutability — hold in adversarial conditions. An implementation that satisfies QODIQA Core's logical requirements but omits the cryptographic requirements herein provides a weaker guarantee than its certification level implies.

The threat categories in Section 2 are not hypothetical. They are operational attack classes observed against deployed runtime enforcement infrastructure. Each maps to a specific cryptographic control defined in this profile. Omission of any required control creates a specific exploitable gap, not a theoretical weakness.

The algorithms defined as approved in this profile reflect current NIST guidance and cryptographic best practice as of the document date. Implementations MUST maintain an active cryptographic configuration review process and update algorithm selections as NIST guidance evolves. This profile will be versioned in parallel with QODIQA Core Standard revisions.

#Cryptographic Trust Model

This annex specifies the hierarchical trust structure that underpins all cryptographic operations in a conformant QODIQA enforcement deployment. The trust model is not a policy construct — it is a structural requirement. Every cryptographic verification operation performed at a QODIQA enforcement gate traces to this chain. The chain MUST be complete, verifiable, and non-circular at every point during enforcement operation.

X.1 Hierarchical Trust Chain

The QODIQA trust hierarchy follows a three-tier model in which each tier signs the public key material of the tier below it. A verification at any tier is valid only if the complete chain from that tier to the Root Trust Anchor can be constructed and each link in the chain passes signature verification against the tier above it. There are no lateral trust relationships in this model. Trust flows strictly downward from root to enforcement gate.

  ROOT TRUST ANCHOR
  (offline HSM; dual-control; air-gapped)
  │
  │  Signs: Intermediate Signing Authority public key
  │  Verified by: enforcement gate on manifest load
  ↓
  INTERMEDIATE SIGNING AUTHORITY
  (online HSM; FIPS 140-2 Level 3; non-exportable)
  │
  │  Signs: Consent Token Issuer public key; key manifest
  │  Verified by: enforcement gate on key manifest fetch
  ↓
  CONSENT TOKEN ISSUER
  (online HSM; operational signing key; rotated per Section 5.2)
  │
  │  Signs: consent tokens presented to enforcement gate
  │  Verified by: enforcement gate on every token verification
  ↓
  ENFORCEMENT GATE VERIFICATION
  (runtime; stateless per token; deterministic; fail-closed)
  │
  │  Produces: Decision Artifact (PERMIT | DENY)
  │  Writes: audit ledger entry before response
  ↓
  DECISION ARTIFACT + AUDIT LEDGER ENTRY
  (immutable; hash-chained; cryptographically anchored)

X.2 Deterministic Validation Chain

At runtime, the enforcement gate executes the following trust chain validation sequence for every presented consent token. This sequence MUST be completed in the order specified. No step may be skipped or reordered. Failure at any step produces an immediate DENY decision and an audit ledger entry recording the step at which validation failed.

This five-step chain constitutes the complete trust validation path. An enforcement gate that short-circuits any step — including by caching intermediate verification results across invocations without re-verifying the chain on manifest refresh — is non-conformant. The deterministic validation chain is not optional at any deployment profile tier.

#Informative Cryptographic Reference Mapping

The normative requirements in Sections 3–12 of this document are derived from, and consistent with, a body of published cryptographic standards. This annex provides an informative mapping to those standards for implementers, auditors, and reviewers who wish to cross-reference QODIQA requirements against established standards bodies. Mapping to a standard does not constitute a claim of certification or compliance under that standard's audit regime.

A.1 FIPS 180-4 — Secure Hash Standard

FIPS 180-4 (Secure Hash Standard, SHS) — published by NIST — specifies the SHA family of hash functions including SHA-256, SHA-384, and SHA-512. All hash algorithm requirements in Section 3.2 and Section 7 of this document are consistent with FIPS 180-4 approved algorithms. SHA-256 is the minimum approved hash for artifact construction in Section 7. SHA-384 is required at the High-Assurance profile in certain contexts. SHA-512 is approved for use. MD5 and SHA-1 prohibitions in Section 3.3 align with NIST's withdrawal of these algorithms from approved use.

A.2 FIPS 186-4 / FIPS 186-5 — Digital Signature Standard

FIPS 186-4 (Digital Signature Standard) and the updated FIPS 186-5 specify the approved digital signature algorithms for federal use. ECDSA P-256 and ECDSA P-384 approved in Section 3.1 are directly specified in FIPS 186-4 Section 6.1 (curves P-256 and P-384). The RSA-PSS algorithm approved in Section 3.1 is specified in FIPS 186-4 Section 5.5. The prohibition on RSA < 2048-bit keys in Section 3.3 aligns with FIPS 186-4 Section 5.1 minimum key size guidance. The deterministic nonce requirement for ECDSA (RFC 6979) supplements FIPS 186-4 Section 6.3, which does not require deterministic nonce generation but permits it. Ed25519 is specified in FIPS 186-5 Section 5.1 as an approved signature algorithm.

A.3 NIST SP 800-57 — Key Management

NIST SP 800-57 (Recommendation for Key Management, Parts 1–3) provides comprehensive guidance on cryptographic key management including key generation, distribution, storage, use, and destruction. The QODIQA key management requirements in Section 5 — including key rotation intervals, HSM storage requirements, key compromise response, and prohibited storage patterns — are consistent with and informed by NIST SP 800-57 Part 1 (General) and Part 2 (Best Practices for Key Management Organizations). The dual-control key activation requirement in SEC-KEY-03 corresponds to NIST SP 800-57 Part 2 guidance on separation of duties for sensitive key operations. Key rotation intervals in Section 5.2 are consistent with NIST SP 800-57 Part 1 Section 5.6 recommendations for cryptoperiods.

A.4 NIST SP 800-63 — Identity and Authentication

NIST SP 800-63 (Digital Identity Guidelines) provides the federal standard for digital identity assurance, authentication, and federation. QODIQA's consent enforcement layer operates at the boundary between identity verification and authorization. While QODIQA does not implement identity proofing or authentication (those are upstream of the SUP boundary), the consent token structure defined in Section 4 draws from principles consistent with SP 800-63B (Authentication and Lifecycle Management) regarding token lifetime limits, session management, and revocation requirements. The registry consultation requirement (Section 6) is structurally consistent with SP 800-63C guidance on federation assertion validity and revocation. Implementers integrating QODIQA within a broader digital identity infrastructure SHOULD refer to SP 800-63 for identity and authentication controls upstream of the SUP enforcement boundary.

A.5 NIST Post-Quantum Cryptography Standardization

The NIST Post-Quantum Cryptography (PQC) standardization process has yielded initial standards in 2024. The primary PQC signature algorithms now standardized are:

The cryptographic agility requirements in Section 3.4 (SEC-ALG-AGILITY-01) directly address the PQC transition. Implementations targeting active deployment beyond 2030 MUST include a documented PQC migration readiness plan, as required by SEC-ALG-AGILITY-01. The NIST PQC migration guidance documents (NIST IR 8413, NIST SP 800-131A Rev.2, and NIST PQC Migration FAQ) provide additional implementation guidance beyond the scope of this document.

The dual-signature transition model defined in Section 3.4.2 is directly applicable to the PQC migration scenario: an implementation may produce artifacts signed under both Ed25519 and ML-DSA (Dilithium) during the transition period, satisfying both classical and post-quantum verifiers simultaneously until the deployment is fully migrated.

A.6 FIPS 140-2 / FIPS 140-3 — Security Requirements for Cryptographic Modules

FIPS 140-2 (Security Requirements for Cryptographic Modules) and its successor FIPS 140-3 (aligned with ISO/IEC 19790:2012) define four levels of cryptographic module security. QODIQA SEC-KEY-03 requires FIPS 140-2 Level 3 or equivalent for High-Assurance profile HSMs. The levels are summarized for reference:

FIPS 140-3 replaces FIPS 140-2 for new certifications initiated after September 22, 2021. FIPS 140-2 certificates remain valid until their expiration. Implementations procuring new HSM hardware SHOULD prefer FIPS 140-3 certified modules at the equivalent security level. FIPS 140-3 Level 3 satisfies the FIPS 140-2 Level 3 requirement in SEC-KEY-03.

#Document Status and Classification