Kinetic Trust Protocol (KTP) - Cryptographic Specification

This document specifies the cryptographic requirements for the Kinetic Trust Protocol (KTP). It consolidates all cryptographic algorithms, key management procedures, credential formats, and security parameters required for conformant implementations.

The specification covers signature schemes, hash functions, key derivation, threshold cryptography, hardware security module integration, key lifecycle management, and post-quantum cryptography considerations.

Introduction

Cryptography is the enforcement mechanism for the trust model. The Zeroth Law (A ≤ E) is meaningless without cryptographic guarantees that Trust Proofs cannot be forged, trajectories cannot be falsified, and audit records cannot be altered.

This specification consolidates all cryptographic requirements from across the KTP RFC series into a single normative document.

Design Principles

KTP cryptography follows these principles:

1. CONSERVATIVE CHOICES Prefer well-studied algorithms over novel constructions. Security margins should exceed minimum requirements.

2. CRYPTOGRAPHIC AGILITY Support algorithm negotiation to enable future transitions. No algorithm is permanent; all must be replaceable.

3. DEFENSE IN DEPTH Multiple cryptographic mechanisms protect critical assets. Compromise of one mechanism should not compromise all.

4. HARDWARE ROOTS High-value keys should be protected by hardware. Software-only protection is acceptable only for Level 1.

5. POST-QUANTUM AWARENESS Design for eventual quantum computer threat. Hybrid schemes available now; mandatory transition planned.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Terminology

This document uses the following terms:

Signing Key: Private key used to create digital signatures.

Verification Key: Public key used to verify digital signatures.

Threshold Signature: Signature requiring k-of-n parties to cooperate.

Key Ceremony: Formal procedure for generating or rotating keys.

HSM (Hardware Security Module): Tamper-resistant hardware for key protection.

PQC (Post-Quantum Cryptography): Algorithms resistant to quantum computer attacks.

Hybrid Signature: Combination of classical and post-quantum signatures.

Key Epoch: Time period during which a key is valid.

Algorithm Requirements by Level

KTP defines three conformance levels with increasing cryptographic requirements.

Level 1 (Basic)

Level 1 is suitable for development, testing, and low-risk deployments. It prioritizes ease of implementation.

Signature Algorithms (one REQUIRED):
+-----------+-------------------+----------------+-------------+
| Algorithm | Curve/Params      | Security Level | Status      |
+-----------+-------------------+----------------+-------------+
| ECDSA     | P-256 (secp256r1) | 128-bit        | REQUIRED    |
| EdDSA     | Ed25519           | 128-bit        | RECOMMENDED |
+-----------+-------------------+----------------+-------------+

Hash Functions (one REQUIRED):
+-----------+-------------+----------------+----------+
| Algorithm | Output Size | Security Level | Status   |
+-----------+-------------+----------------+----------+
| SHA-256   | 256 bits    | 128-bit        | REQUIRED |
| SHA-384   | 384 bits    | 192-bit        | OPTIONAL |
+-----------+-------------+----------------+----------+

Symmetric Encryption (if needed):
+-------------+----------+----------------+-------------+
| Algorithm   | Key Size | Security Level | Status      |
+-------------+----------+----------------+-------------+
| AES-128-GCM | 128 bits | 128-bit        | REQUIRED    |
| AES-256-GCM | 256 bits | 256-bit        | RECOMMENDED |
+-------------+----------+----------------+-------------+

Key Storage:

• Software keystore acceptable
• HSM RECOMMENDED but not required
• Key encryption at rest REQUIRED

Threshold Signatures:

• NOT REQUIRED for Level 1
• Single Oracle signature acceptable

Level 2 (Standard)

Level 2 is suitable for production deployments with moderate security requirements.

Signature Algorithms (all REQUIRED):
+-----------+--------------+----------------+-------------+
| Algorithm | Curve/Params | Security Level | Status      |
+-----------+--------------+----------------+-------------+
| ECDSA     | P-256        | 128-bit        | REQUIRED    |
| EdDSA     | Ed25519      | 128-bit        | REQUIRED    |
| ECDSA     | P-384        | 192-bit        | RECOMMENDED |
+-----------+--------------+----------------+-------------+

Hash Functions (all listed REQUIRED):
+-----------+-------------+-------------------------------+
| Algorithm | Output Size | Use Case                      |
+-----------+-------------+-------------------------------+
| SHA-256   | 256 bits    | General hashing               |
| SHA-384   | 384 bits    | High-security contexts        |
| SHA3-256  | 256 bits    | Flight Recorder (recommended) |
+-----------+-------------+-------------------------------+

Symmetric Encryption:
+---------------+----------+----------------+-------------+
| Algorithm     | Key Size | Security Level | Status      |
+---------------+----------+----------------+-------------+
| AES-256-GCM   | 256 bits | 256-bit        | REQUIRED    |
| ChaCha20-Poly | 256 bits | 256-bit        | RECOMMENDED |
+---------------+----------+----------------+-------------+

Key Storage:

• HSM REQUIRED for Oracle signing keys
• Software keystore acceptable for agent keys
• Key encryption at rest REQUIRED
• Key backup procedures REQUIRED

Threshold Signatures:

• REQUIRED for Trust Proof issuance
• Minimum threshold: 2-of-3
• RECOMMENDED threshold: 3-of-5

Level 3 (Full)

Level 3 is suitable for critical infrastructure, high-security environments, and federation anchor nodes.

Signature Algorithms (all REQUIRED):
+------------+----------------+----------------+----------+
| Algorithm  | Curve/Params   | Security Level | Status   |
+------------+----------------+----------------+----------+
| ECDSA      | P-384          | 192-bit        | REQUIRED |
| EdDSA      | Ed448          | 224-bit        | REQUIRED |
| Hybrid PQC | See Section 11 | Post-quantum   | REQUIRED |
+------------+----------------+----------------+----------+

Hash Functions:
+-----------+-------------+-----------------+
| Algorithm | Output Size | Use Case        |
+-----------+-------------+-----------------+
| SHA-384   | 384 bits    | General hashing |
| SHA3-384  | 384 bits    | Flight Recorder |
| SHAKE256  | Variable    | Key derivation  |
+-----------+-------------+-----------------+

Symmetric Encryption:
+---------------+----------+----------------+----------+
| Algorithm     | Key Size | Security Level | Status   |
+---------------+----------+----------------+----------+
| AES-256-GCM   | 256 bits | 256-bit        | REQUIRED |
| ChaCha20-Poly | 256 bits | 256-bit        | REQUIRED |
+---------------+----------+----------------+----------+

Key Storage:

• FIPS 140-2 Level 3 (or equivalent) HSM REQUIRED
• Multi-person access control REQUIRED
• Geographic distribution REQUIRED
• Key ceremony with witnesses REQUIRED

Threshold Signatures:

• REQUIRED for all Oracle operations
• Minimum threshold: 3-of-5
• RECOMMENDED threshold: 5-of-7
• Geographic distribution of key shares REQUIRED

Signature Schemes

ECDSA

ECDSA (Elliptic Curve Digital Signature Algorithm) per FIPS 186-4.

Supported Curves:
+-------+------------+----------------+----------+
| Curve | Field Size | Security Level | JOSE alg |
+-------+------------+----------------+----------+
| P-256 | 256 bits   | 128-bit        | ES256    |
| P-384 | 384 bits   | 192-bit        | ES384    |
| P-521 | 521 bits   | 256-bit        | ES512    |
+-------+------------+----------------+----------+

Requirements:

1. Implementations MUST use deterministic ECDSA (RFC 6979) to prevent nonce reuse vulnerabilities.

2. Implementations MUST validate that points are on the curve before use.

3. Implementations MUST reject signatures with s > n/2 (low-s normalization) to prevent malleability.

4. Private keys MUST be generated using cryptographically secure random number generators.

Signature Format:

ECDSA signatures in KTP use the compact representation:

   signature = r || s

Where r and s are fixed-size big-endian integers (32 bytes for P-256, 48 bytes for P-384, 66 bytes for P-521).

For JWS/JWT contexts, signatures are base64url-encoded.

EdDSA

EdDSA (Edwards-curve Digital Signature Algorithm) per RFC 8032.

Supported Curves:
+---------+------------+----------------+----------+
| Curve   | Field Size | Security Level | JOSE alg |
+---------+------------+----------------+----------+
| Ed25519 | 255 bits   | 128-bit        | EdDSA    |
| Ed448   | 448 bits   | 224-bit        | EdDSA    |
+---------+------------+----------------+----------+

Requirements:

1. Implementations MUST use Ed25519 or Ed448 as specified in RFC 8032 without modifications.

2. Ed25519 implementations SHOULD use the "cofactored" variant for batch verification.

3. Implementations MUST reject non-canonical signatures.

Advantages over ECDSA:

• Deterministic by design (no nonce to leak)
• Faster signing and verification
• Smaller attack surface
• Simpler implementation

EdDSA is RECOMMENDED over ECDSA for new deployments.

Threshold Signatures

Threshold signatures require k-of-n Oracles to cooperate, preventing single-point-of-failure attacks.

Supported Schemes

+----------------+----------------+----------------+-------------+
| Scheme         | Base Algorithm | Level Required | Status      |
+----------------+----------------+----------------+-------------+
| Shamir + ECDSA | ECDSA          | Level 2+       | REQUIRED    |
| FROST          | Schnorr        | Level 2+       | RECOMMENDED |
| BLS Threshold  | BLS12-381      | Level 3        | OPTIONAL    |
+----------------+----------------+----------------+-------------+

Shamir-based Threshold ECDSA

Uses Shamir Secret Sharing to distribute the signing key, with secure multi-party computation for signature generation.

Protocol outline:

1. KEY GENERATION (one-time ceremony) - Generate master signing key k - Create n shares using Shamir (k,n)-threshold scheme - Distribute shares to n Oracles - Destroy master key (never reconstructed)

2. SIGNATURE GENERATION (per Trust Proof) - k Oracles receive signing request - Each Oracle verifies the applicable committed-state evidence and request under specifications/oracle-consensus.md - Each Oracle generates partial signature using share - Coordinator combines k partial signatures - Result is valid ECDSA signature

Security properties:

• Any k Oracles can sign
• Fewer than k Oracles learn nothing about key
• Individual shares never leave HSMs
• Master key is never reconstructed

FROST (Flexible Round-Optimized Schnorr Threshold)

FROST provides threshold Schnorr signatures with two-round signing protocol.

Advantages:

• Fewer rounds than threshold ECDSA
• Smaller signatures (single curve point + scalar)
• Provable security in random oracle model

FROST is RECOMMENDED for new Level 2+ deployments.

Threshold Configuration

+---------+---------------+-------------------+-------------+
| Level   | Minimum (k,n) | Recommended (k,n) | Max Latency |
+---------+---------------+-------------------+-------------+
| Level 1 | (1,1)         | (1,1)             | N/A         |
| Level 2 | (2,3)         | (3,5)             | 100ms       |
| Level 3 | (3,5)         | (5,7)             | 200ms       |
+---------+---------------+-------------------+-------------+

These are cryptographic signing thresholds, not consensus decision quorums. A threshold signature proves signing participation under the key's security assumptions; it does not by itself establish one committed history. In particular, k > n/2 does not prevent Byzantine split brain: with five members, two sets of three signers can overlap only at one malicious member that signs both conflicting decisions.

Oracle meshes MUST protect authoritative state through the reviewed, named and versioned consensus protocol required by specifications/oracle-consensus.md. For a membership of N distinct members tolerating at most f Byzantine members, the Byzantine profile requires f >= 1, N >= 3f + 1, and a homogeneous decision quorum q satisfying floor((N + f) / 2) + 1 <= q <= N - f. The default is N = 5, f = 1, q = 4. This requirement includes authenticated membership epochs, durable voting and locks, safe view changes, and safe membership transitions; quorum arithmetic alone is not a consensus protocol.

A 3-of-5 or 2-of-3 signing configuration MAY remain in use where permitted by the conformance level, provided honest signers verify the required underlying commit evidence before signing protected state or a proof derived from it. Its signing threshold MUST NOT be advertised as the Byzantine decision quorum. The signing configuration, consensus membership and fault budget, and any stricter operation-specific approval threshold MUST be declared separately. A single-Oracle deployment has no Byzantine consensus guarantee.

Algorithm Negotiation

KTP supports algorithm negotiation to enable future transitions.

Algorithm Identifier Format

Algorithm identifiers use the format:

   <scheme>-<curve_or_params>[-<variant>]

Examples: ecdsa-p256 eddsa-ed25519 frost-secp256k1 threshold-bls12-381-3of5

Negotiation Protocol

During zone federation or Oracle mesh formation:

1. Initiator sends supported algorithms (ordered by preference)
2. Responder selects highest-preference mutual algorithm
3. Selected algorithm used for session

Message format:

   {
     "supported_algorithms": [
       "eddsa-ed448",
       "eddsa-ed25519",
       "ecdsa-p384",
       "ecdsa-p256"
     ],
     "required_minimum": "ecdsa-p256"
   }

Algorithm Deprecation

When an algorithm is deprecated:

1. ANNOUNCE: 18-month notice before mandatory transition
2. WARN: Implementations log warnings when deprecated algorithm used
3. REJECT: Implementations reject deprecated algorithm
4. REMOVE: Algorithm removed from specification

Current deprecation schedule:

+-------------+---------------+------------------+--------------+
| Algorithm   | Status        | Deprecation Date | Removal Date |
+-------------+---------------+------------------+--------------+
| RSA-2048    | NOT SUPPORTED | N/A              | N/A          |
| ECDSA P-256 | SUPPORTED     | TBD (post PQC)   | TBD          |
| SHA-1       | NOT SUPPORTED | N/A              | N/A          |
+-------------+---------------+------------------+--------------+

Hash Functions

SHA-2 Family

SHA-2 per FIPS 180-4.

+-----------+-------------+------------+----------------+
| Algorithm | Output Size | Block Size | KTP Usage      |
+-----------+-------------+------------+----------------+
| SHA-256   | 256 bits    | 512 bits   | General        |
| SHA-384   | 384 bits    | 1024 bits  | High-security  |
| SHA-512   | 512 bits    | 1024 bits  | Key derivation |
+-----------+-------------+------------+----------------+

SHA-256 is the default hash function for Level 1 and Level 2. SHA-384 is REQUIRED for Level 3.

SHA-3 Family

SHA-3 per FIPS 202.

+-----------+-------------+----------+---------------+
| Algorithm | Output Size | Capacity | KTP Usage     |
+-----------+-------------+----------+---------------+
| SHA3-256  | 256 bits    | 512 bits | Flight Rec.   |
| SHA3-384  | 384 bits    | 768 bits | Level 3 audit |
| SHAKE128  | Variable    | 256 bits | KDF (general) |
| SHAKE256  | Variable    | 512 bits | KDF (Level 3) |
+-----------+-------------+----------+---------------+

SHA-3 provides defense in depth against potential SHA-2 vulnerabilities. SHA3-256 is RECOMMENDED for Flight Recorder chain hashing.

BLAKE3

BLAKE3 is a high-performance hash function suitable for bulk data hashing.

+-----------+-------------+-----------+------------+
| Algorithm | Output Size | Speed     | KTP Usage  |
+-----------+-------------+-----------+------------+
| BLAKE3    | Variable    | Very fast | Trajectory |
+-----------+-------------+-----------+------------+

BLAKE3 is OPTIONAL for performance-critical hashing where SHA-2/SHA-3 performance is insufficient. It MUST NOT be used for contexts requiring NIST-approved algorithms.

This optional bulk-hashing use does not change the v3 trajectory record_hash algorithm or its canonical preimage. The trajectory contract below requires SHA-256 at Levels 1 and 2 and SHA-384 at Level 3.

Hash Function Selection

+-----------------------+---------+----------+----------+
| Context               | Level 1 | Level 2  | Level 3  |
+-----------------------+---------+----------+----------+
| Trust Proof hashing   | SHA-256 | SHA-256  | SHA-384  |
| Flight Recorder chain | SHA-256 | SHA3-256 | SHA3-384 |
| Trajectory chain      | SHA-256 | SHA-256  | SHA-384  |
| Key derivation        | SHA-256 | SHA-512  | SHAKE256 |
| Agent ID generation   | SHA-256 | SHA-256  | SHA-256  |
+-----------------------+---------+----------+----------+

The trajectory row above applies to the completed v3 signed envelope defined in specifications/trajectory-signatures.md, excluding only its own record_hash field. The chosen level and algorithm MUST come from trusted configuration; a candidate record MUST NOT select its own verification strength. Flight Recorder chain hashes are a different record type and retain their separate algorithm and preimage rules.

Trajectory Signature and Hash Binding

Active trajectory records MUST declare record_version = "ktp-trajectory-v3" and follow specifications/trajectory-signatures.md. Define B as the entire top-level record except agent_signature, oracle_attestation, and record_hash, and O as the entire oracle_attestation except oracle_signature. No other state, identity, action details, evaluation-profile, or migration fields may be omitted from these projections.

The agent compact JWS embeds RFC 8785 JCS(B) as its payload and protects exactly alg, kid, and typ = "ktp-trajectory-agent-v3". The Oracle compact JWS embeds JCS({"record_body": B, "agent_signature": exact_agent_compact_JWS, "attestation": O}) and protects exactly alg, kid, and typ = "ktp-trajectory-oracle-v3". The JWS signing input includes the protected header and encoded payload under RFC 7515; it is not a concatenation of selected JSON fields or an untyped digest. Verifiers MUST reconstruct and compare the exact canonical payload bytes, validate role separation, and resolve allowed algorithms and keys from independently trusted configuration.

The final record_hash is the lowercase prefixed SHA-256 digest at Levels 1/2, or SHA-384 digest at Level 3, of JCS(completed_record excluding only record_hash). It includes both exact JWS strings and all attestation metadata. Canonicalization MUST reject duplicate object names, invalid Unicode, and out-of-profile numbers as required by the companion; ordinary lexical key sorting is not an RFC 8785 implementation.

In a mesh, the typed digest of the canonical Oracle payload is committed before Oracle signing. The final completed-envelope hash is independently committed as the unique selected head afterward, with its record_version, commit_intent, agent, zone, chain, sequence, and predecessor. These are distinct stages: a certificate over the intent does not bind a later signature envelope, and no signature may require a certificate whose digest recursively depends on that signature. Different valid ECDSA envelopes for one intent MUST NOT establish competing authoritative successors.

The reference helper's supported classical signatures and Level 3 SHA-384 checks do not implement every cryptographic profile. Required threshold participation, hybrid signatures, key protection, and other stronger deployment requirements remain binding; successful helper verification MUST NOT be presented as full Level 3 conformance.

Legacy v2 verification is archival only after the trusted cutover. Migration requires an independently authenticated checkpoint and revalidated carried state, a new v3 genesis referring to that checkpoint, and separate anchoring of the final genesis hash. Original legacy bytes MUST be preserved. Restart, key rotation, candidate-supplied versions, or fallback verification MUST NOT reset the durable format floor or single-use lineage succession.

Key Derivation

HKDF

HKDF (HMAC-based Key Derivation Function) per RFC 5869.

KTP uses HKDF for deriving keys from shared secrets:

   derived_key = HKDF-Expand(
     HKDF-Extract(salt, input_key_material),
     info,
     length
   )

Context strings (info parameter):

+------------------------+------------------------------+
| Purpose                | Info String                  |
+------------------------+------------------------------+
| Trust Proof encryption | "ktp-trust-proof-encrypt-v1" |
| Trajectory chain key   | "ktp-trajectory-key-v1"      |
| Oracle session key     | "ktp-oracle-session-v1"      |
| Agent attestation key  | "ktp-agent-attestation-v1"   |
| Federation channel key | "ktp-federation-channel-v1"  |
+------------------------+------------------------------+

Salt SHOULD be random and unique per derivation. If salt is not available, use the zone identifier as salt.

Argon2

Argon2 per RFC 9106 for password-based key derivation.

Argon2id is REQUIRED when deriving keys from human-memorable secrets (e.g., recovery passphrases).

Minimum parameters:

+---------+---------+------------+-------------+
| Level   | Memory  | Iterations | Parallelism |
+---------+---------+------------+-------------+
| Level 1 | 64 MiB  | 3          | 4           |
| Level 2 | 256 MiB | 4          | 4           |
| Level 3 | 1 GiB   | 6          | 8           |
+---------+---------+------------+-------------+

These parameters should be tuned to achieve approximately:

• Level 1: 0.5 second computation time
• Level 2: 1.0 second computation time
• Level 3: 3.0 second computation time

Key Derivation Contexts

When deriving multiple keys from a single secret, each key MUST use a unique context:

   master_secret = [from key agreement or ceremony]

   encryption_key = HKDF(master_secret, salt, "encrypt", 32)
   mac_key = HKDF(master_secret, salt, "mac", 32)
   nonce_key = HKDF(master_secret, salt, "nonce", 16)

Keys derived from the same master MUST NOT be used for different algorithms (e.g., don't use same derived key for AES and ChaCha20).

Symmetric Encryption

AES-GCM

AES-GCM per NIST SP 800-38D.

+-------------+----------+------------+----------+
| Variant     | Key Size | Nonce Size | Tag Size |
+-------------+----------+------------+----------+
| AES-128-GCM | 128 bits | 96 bits    | 128 bits |
| AES-256-GCM | 256 bits | 96 bits    | 128 bits |
+-------------+----------+------------+----------+

Requirements:

1. Nonces MUST be unique per key. Random nonces are acceptable for AES-256-GCM with 96-bit nonce (collision probability acceptable up to 2^32 messages per key).

2. For high-volume contexts, use counter-based nonces with unique prefix per sender.

3. Tag size MUST be 128 bits (16 bytes). Truncated tags are NOT permitted.

4. AAD (Additional Authenticated Data) SHOULD include context binding (e.g., agent ID, timestamp, purpose).

ChaCha20-Poly1305

ChaCha20-Poly1305 per RFC 8439.

+----------+------------+----------+-------------+
| Key Size | Nonce Size | Tag Size | Status      |
+----------+------------+----------+-------------+
| 256 bits | 96 bits    | 128 bits | RECOMMENDED |
+----------+------------+----------+-------------+

ChaCha20-Poly1305 is RECOMMENDED as an alternative to AES-GCM:

• Better performance on systems without AES-NI
• Constant-time implementation is simpler
• No weak-key classes

Both AES-256-GCM and ChaCha20-Poly1305 MUST be supported for Level 2+.

Encryption Contexts

+----------------------------+---------------+------------------+
| Context                    | Algorithm     | Key Source       |
+----------------------------+---------------+------------------+
| Trust Proof (at rest)      | AES-256-GCM   | Zone key         |
| Flight Recorder encryption | AES-256-GCM   | Audit key        |
| Agent credentials          | AES-256-GCM   | Agent master key |
| Federation messages        | ChaCha20-Poly | Session key      |
| Sensor data (in transit)   | TLS 1.3       | TLS handshake    |
+----------------------------+---------------+------------------+

Key Management

Key Types

KTP defines the following key types:

Oracle Signing Keys

Purpose: Sign Trust Proofs and trajectory attestations

Properties:

• Threshold key shares (k-of-n)
• MUST be stored in HSM for Level 2+
• Rotation: Annual or upon compromise
• Lifetime: Maximum 2 years

Format: { "key_type": "oracle_signing", "key_id": "oracle-zone-alpha-2025-001", "algorithm": "threshold-frost-ed25519-3of5", "public_key": "base64...", "created_at": "2025-01-01T00:00:00Z", "expires_at": "2027-01-01T00:00:00Z", "threshold": { "k": 3, "n": 5 }, "share_holders": [ "oracle-alpha-1", "oracle-alpha-2", "oracle-alpha-3", "oracle-alpha-4", "oracle-alpha-5" ] }

Agent Identity Keys

Purpose: Prove agent identity, sign trajectory records

Properties:

• Single-holder key (not threshold)
• May be software or HSM protected
• Rotation: Upon role change or compromise
• Lifetime: Tied to agent lifecycle

Format: { "key_type": "agent_identity", "key_id": "agent-7gen-optimized-a1b2c3d4", "algorithm": "eddsa-ed25519", "public_key": "base64...", "created_at": "2025-06-15T10:30:00Z", "expires_at": null, "lineage": "guarantor", "generation": 7 }

Zone Encryption Keys

Purpose: Encrypt data at rest within a zone

Properties:

• Symmetric key (AES-256)
• Protected by Oracle key (envelope encryption)
• Rotation: Quarterly
• Lifetime: Maximum 1 year

Federation Keys

Purpose: Secure communication between zones

Properties:

• Key agreement (ECDH) + symmetric session keys
• Tied to federation agreement
• Rotation: Per session or hourly (whichever is shorter)
• Lifetime: Session-scoped

Root of Trust Keys

Purpose: Anchor the entire key hierarchy

Properties:

• Highest-security key in the system
• MUST be stored in FIPS 140-2 Level 3+ HSM
• Created in formal key ceremony with witnesses
• Rotation: Rare (5+ years) or upon compromise
• Used only to sign subordinate keys

Key Generation

Randomness Requirements

All key generation MUST use cryptographically secure random number generators (CSPRNGs):

• Operating system: /dev/urandom (Linux), CryptGenRandom (Windows)
• HSM: Hardware random number generator
• Cloud: Cloud provider HSM RNG

Implementations MUST NOT use:

• Predictable seeds
• Low-entropy sources
• User-provided randomness without mixing

Key Generation Procedures

Level 1 (Software):

   1. Generate 256 bits from CSPRNG
   2. Use as private key directly (Ed25519) or derive (ECDSA)
   3. Store encrypted in keystore
   4. Log generation event (without key material)

Level 2+ (HSM):

   1. Initiate key generation on HSM
   2. HSM generates key internally using hardware RNG
   3. Private key never leaves HSM
   4. Export public key for distribution
   5. Log generation event with HSM attestation

Level 3 (Ceremony):

   1. Convene key ceremony with required participants
   2. Each participant provides entropy contribution
   3. HSM mixes entropy and generates key
   4. Key shares distributed to separate HSMs
   5. Ceremony recorded and witnessed
   6. Ceremony artifacts archived

Key Storage

Storage Requirements by Level

+-------+------------------+-----------------+------------------+
| Level | Oracle Keys      | Agent Keys      | Audit Keys       |
+-------+------------------+-----------------+------------------+
| 1     | Encrypted file   | Encrypted file  | Encrypted file   |
| 2     | HSM (FIPS 140-2) | Encrypted file  | HSM or encrypted |
| 3     | HSM Level 3      | HSM recommended | HSM Level 3      |
+-------+------------------+-----------------+------------------+

Software Key Storage

For software-protected keys:

1. Encrypt with AES-256-GCM using key derived from: - System entropy (hardware IDs, boot time, etc.) - Optional: Human passphrase (Argon2-stretched)

2. Store in protected location: - Linux: /var/lib/ktp/keys with mode 0600 - HSM-backed keystore if available

3. Implement memory protection: - mlock() to prevent swapping - Secure memory wiping after use

HSM Key Storage

For HSM-protected keys:

1. Generate keys on HSM (never import)
2. Keys are non-extractable
3. Access controlled by HSM authentication
4. Backup via HSM-to-HSM key transfer (if supported)

Key Rotation

Rotation Schedule

+--------------------+-----------------+---------------------------+
| Key Type           | Normal Rotation | Emergency Rotation        |
+--------------------+-----------------+---------------------------+
| Root of Trust      | 5 years         | Immediate upon compromise |
| Oracle Signing     | 1 year          | 24 hours upon compromise  |
| Zone Encryption    | 90 days         | Immediate upon compromise |
| Federation Session | 1 hour          | Immediate upon compromise |
| Agent Identity     | Role change     | Immediate upon compromise |
+--------------------+-----------------+---------------------------+

Rotation Procedure

For Oracle signing keys:

1. PREPARE (1 week before expiry) - Generate new key shares on HSMs - Distribute shares to Oracle nodes - Verify all nodes have new shares

2. OVERLAP (during transition window) - Old key still valid for verification - New key used for new signatures - Both keys published in key directory

3. COMMIT (after transition window) - Old key marked as expired - Old key retained for historical verification - New key is sole signing key

4. ARCHIVE (after retention period) - Old key material securely destroyed - Public key retained indefinitely for audit

Key Overlap Period

+-----------------+----------------+--------------+
| Key Type        | Overlap Period | Grace Period |
+-----------------+----------------+--------------+
| Oracle Signing  | 7 days         | 30 days      |
| Zone Encryption | 24 hours       | 7 days       |
| Federation      | 5 minutes      | 1 hour       |
+-----------------+----------------+--------------+

During overlap period, both old and new keys are valid. During grace period, old key valid for verification only.

Key Revocation

Revocation Triggers

Keys MUST be revoked when:

1. Compromise confirmed or suspected
2. Key holder leaves organization
3. Key holder role changes (if role-bound)
4. Cryptographic weakness discovered in algorithm
5. HSM containing key is decommissioned

Revocation Procedure

1. IMMEDIATE (within minutes) - Add key to revocation list - Broadcast revocation to all zones - Log revocation with reason

2. PROPAGATION (within hours) - All Trust Oracles update revocation lists - All PEPs refresh revocation cache - All agents receive revocation notice

3. ENFORCEMENT - Signatures by revoked key rejected - Trust Proofs signed by revoked key invalidated - Agents authenticated by revoked key demoted

Revocation List Format

   {
     "version": 1,
     "zone_id": "zone-alpha",
     "issued_at": "2025-11-25T12:00:00Z",
     "next_update": "2025-11-25T13:00:00Z",
     "revoked_keys": [
       {
         "key_id": "oracle-zone-alpha-2024-001",
         "revoked_at": "2025-11-25T11:30:00Z",
         "reason": "key_compromise",
         "replacement_key_id": "oracle-zone-alpha-2025-002"
       }
     ],
     "signature": "..."
   }

Key Escrow and Recovery

Escrow Policy

KTP does NOT mandate key escrow for agent keys. Agents that lose their keys lose their trajectory history.

KTP DOES require recovery capability for Oracle keys to prevent zone- wide lockout.

Oracle Key Recovery

Threshold keys provide inherent recovery: any k-of-n shares can reconstruct signing capability.

For disaster recovery (loss of k+ shares):

1. COLD BACKUP - Encrypted backup of key shares stored offline - Backup encrypted to recovery keys held by trustees - M-of-N trustees required to recover

2. RECOVERY CEREMONY - Convene required trustees - Decrypt backup shares - Install on new HSMs - Verify signing capability - Destroy backup shares used

Recovery keys SHOULD be geographically distributed and held by different organizational roles.

Hardware Security Modules

HSM Requirements

Certification Requirements

+---------+---------------------------------------------+
| Level   | Minimum Certification                       |
+---------+---------------------------------------------+
| Level 1 | None (HSM optional)                         |
| Level 2 | FIPS 140-2 Level 2                          |
| Level 3 | FIPS 140-2 Level 3 or Common Criteria EAL4+ |
+---------+---------------------------------------------+

Functional Requirements

HSMs used for KTP MUST support:

• Key generation using hardware RNG
• ECDSA signing with P-256, P-384 (P-521 recommended)
• EdDSA signing with Ed25519 (Ed448 recommended)
• AES-256-GCM encryption/decryption
• Non-extractable key storage
• Access control (authentication required for operations)
• Audit logging

HSMs used for Level 3 MUST additionally support:

• Multi-person access control (M-of-N authentication)
• Remote attestation
• Tamper response (key zeroization)
• Secure key backup/restore

PKCS#11 Integration

HSM integration SHOULD use PKCS#11 for portability.

Required PKCS#11 mechanisms:

+---------------------+-----------------------+
| Mechanism           | Use Case              |
+---------------------+-----------------------+
| CKM_EC_KEY_PAIR_GEN | ECDSA key generation  |
| CKM_ECDSA_SHA256    | ECDSA signing (P-256) |
| CKM_ECDSA_SHA384    | ECDSA signing (P-384) |
| CKM_AES_GCM         | Symmetric encryption  |
| CKM_SHA256          | Hashing               |
| CKM_SHA384          | Hashing               |
+---------------------+-----------------------+

For EdDSA, use vendor-specific mechanisms or CKM_EDDSA if supported (PKCS#11 3.0+).

Cloud HSM Considerations

Cloud HSMs (AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM) are acceptable for Level 2 deployments.

Considerations:

1. TRUST: You are trusting the cloud provider's HSM implementation
2. AVAILABILITY: Cloud HSM availability tied to region availability
3. KEY BACKUP: Understand cloud provider's backup mechanisms
4. MULTI-REGION: Consider cross-region HSM clusters for resilience

For Level 3, dedicated (non-cloud) HSMs are RECOMMENDED due to the Hypervisor Opaque Wall concern (see KTP-PROBLEMS).

Credential Formats

Trust Proof Format

Trust Proofs use JWS (JSON Web Signature) format per RFC 7515.

Header: { "alg": "ES256", "typ": "ktp-trust-proof+jwt", "kid": "oracle-zone-alpha-2025-001", "ktp_level": 2, "threshold": "3of5" }

Payload: { "iss": "zone:alpha", "sub": "agent:guarantor:7gen:optimized:a1b2c3d4", "aud": "zone:alpha", "iat": 1700000000, "exp": 1700000010, "nbf": 1700000000, "jti": "proof-uuid-12345",

     "e_base": 87,
     "e_trust": 74,
     "risk_factor": 0.15,
     "tier": "operator",

     "context": {
       "evidence_density": 0.12,
       "trust_trend": 0.08,
       "adversarial_pressure": 0.22,
       "moment_criticality": 0.05,
       "update_resistance": 0.18,
       "attestation_coverage": 0.10,
       "soul": 0
     },

     "lineage": {
       "type": "guarantor",
       "generation": 7,
       "trajectory_hash": "sha256:abc123..."
     }
   }

Signature:

• For single-Oracle: Standard JWS signature
• For threshold: Aggregated threshold signature

Readiness Attestation and Decision Formats

Readiness artifacts MUST follow specifications/operational-readiness.md and the unreleased readiness-v1 schemas: schemas/readiness-profile.json, schemas/readiness-attestation.json, and schemas/readiness-decision.json. The complete attestation or decision object excluding exactly signature is its JCS payload. The compact JWS protected header contains exactly alg, kid, and typ, also encoded as JCS; typ is respectively "ktp-readiness-attestation-v1" or "ktp-readiness-decision-v1". Every other field and nested value participates in the signature.

Apply the strict UTF-8, canonical JSON/base64url, signature encoding, integer-token, timestamp, low-s, and trusted key/algorithm requirements of specifications/trajectory-signatures.md. The independently trusted registry MUST authorize the signing key for the exact assessor or decision-issuer role, subject, and scope; an artifact cannot supply its own trust anchor. Key validity must cover issuance through expiry, and known revocation takes precedence. Supported classical signatures do not establish required threshold participation, hybrid signing, key custody, or full Level 3 conformance.

Digest boundaries are distinct and MUST NOT be substituted: the readiness profile uses JCS of its complete object; attestation and decision digests use JCS of the complete signed object including signature; the ordinary proof digest uses the complete ASCII compact JWS, including its header, payload, and signature; the deployment profile digest uses its exact installed bytes. The request digest uses JCS of exactly {request_id, subject, operation_id, scope, deployment_profile_digest, readiness_profile_digest}, constructed from the authenticated invocation and live resolved state. SHA-256 applies at Levels 1/2 and SHA-384 at Level 3 as selected by trusted configuration.

The sidecar binds an already complete ordinary proof, the actual request, the complete active assessment, both installed profiles, readiness_epoch, evaluated_at, expires_at, and issuer_id. It MUST NOT depend on a future trajectory signature or final record hash. Storing the complete sidecar in the existing signed trajectory action.details.readiness object preserves this ordering. A valid signature alone does not establish that the assessment occurred, its evidence remains current, or its digest is registered as active.

Privacy Evidence Storage Signatures

The separate ktp-privacy-evidence-v1 storage format MUST follow specifications/privacy-evidence.md and schemas/privacy-evidence-envelope.json. AES-256-GCM encrypts exact evidence bytes with the complete contextual header as JCS associated data; each envelope uses a fresh data key and nonce. The compact JWS signs all fields except signature and record_hash with typ = "ktp-privacy-evidence-v1". The final hash includes that signature and excludes only record_hash. Role, issuer, zone, level and independently anchored archive state MUST be verified. This role MUST NOT substitute for a trajectory, readiness or authorization signature.

Erasure MUST NOT edit signed plaintext or claim that a new envelope authenticates previously unsigned fields. A retained outer signature may remain verifiable after its payload key is destroyed; that result MUST be reported as outer integrity only. Actual key custody, all recovery paths and copies, recipient disposal, retention and erasure are additional obligations. The classical reference algorithms do not establish stronger threshold or hybrid conformance.

Agent Credential Format

Agent credentials establish identity binding.

   {
     "credential_type": "ktp-agent-credential",
     "version": 1,
     "agent_id": "agent:guarantor:7gen:optimized:a1b2c3d4",

     "identity": {
       "public_key": "base64...",
       "algorithm": "eddsa-ed25519",
       "key_id": "agent-key-12345"
     },

     "proofing": {
       "ial": 2,
       "proofed_at": "2025-01-15T10:00:00Z",
       "provider": "isp:acme-verify"
     },

     "lineage": {
       "type": "guarantor",
       "generation": 7,
       "sponsor_chain": ["org:acme", "agent:acme-deploy"]
     },

     "issued_at": "2025-01-15T10:00:00Z",
     "expires_at": "2026-01-15T10:00:00Z",

     "issuer": {
       "zone_id": "zone:alpha",
       "oracle_key_id": "oracle-zone-alpha-2025-001"
     },

     "signature": "base64..."
   }

Oracle Credential Format

Oracle credentials establish Oracle authority within a zone.

   {
     "credential_type": "ktp-oracle-credential",
     "version": 1,
     "oracle_id": "oracle-alpha-1",

     "zone": {
       "zone_id": "zone:alpha",
       "zone_type": "blue",
       "zone_public_key": "base64..."
     },

     "signing_capability": {
       "key_id": "oracle-zone-alpha-2025-001",
       "algorithm": "threshold-frost-ed25519",
       "share_index": 1,
       "threshold": {
         "k": 3,
         "n": 5
       }
     },

     "attestation": {
       "hsm_attestation": "base64...",
       "platform_attestation": "base64..."
     },

     "issued_at": "2025-01-01T00:00:00Z",
     "expires_at": "2027-01-01T00:00:00Z",

     "issuer": {
       "root_key_id": "root-nmcitra-2024-001"
     },

     "signature": "base64..."
   }

Federation Credential Format

Federation credentials establish inter-zone trust.

   {
     "credential_type": "ktp-federation-credential",
     "version": 1,

     "local_zone": {
       "zone_id": "zone:alpha",
       "oracle_key_id": "oracle-zone-alpha-2025-001"
     },

     "remote_zone": {
       "zone_id": "zone:beta",
       "oracle_key_id": "oracle-zone-beta-2025-001"
     },

     "trust_parameters": {
       "trust_factor": 0.85,
       "max_transitive_trust": 0.7,
       "allowed_operations": ["attest", "query", "federate"],
       "disallowed_operations": ["admin"]
     },

     "agreement": {
       "agreed_at": "2025-06-01T00:00:00Z",
       "expires_at": "2026-06-01T00:00:00Z",
       "renewal": "automatic"
     },

     "signatures": {
       "alpha_signature": "base64...",
       "beta_signature": "base64..."
     }
   }

Post-Quantum Cryptography

Threat Timeline

Current assessment of quantum computing threat:

+-----------+--------------+----------------------------+
| Timeline  | Threat Level | Recommended Action         |
+-----------+--------------+----------------------------+
| 2025-2030 | Low          | Plan transition, implement |
|           |              | hybrid                     |
| 2030-2035 | Medium       | Deploy hybrid mandatory    |
| 2035+     | High         | Full PQC transition        |
+-----------+--------------+----------------------------+

"Harvest now, decrypt later" attacks make earlier action prudent for data that must remain confidential for 10+ years.

KTP Trust Proofs have short lifetimes (seconds), so the threat is primarily to Flight Recorder data and trajectory histories.

Hybrid Signatures

Hybrid signatures combine classical and post-quantum algorithms.

Hybrid format:

   hybrid_signature = classical_signature || pqc_signature

Both signatures must verify for the hybrid to be valid. This provides security as long as EITHER algorithm remains secure.

Recommended hybrid pairs:

+-------------+------------+---------------+-------+
| Classical   | PQC        | Combined Size | Level |
+-------------+------------+---------------+-------+
| Ed25519     | Dilithium2 | ~2500 bytes   | 2     |
| Ed448       | Dilithium3 | ~3600 bytes   | 3     |
| ECDSA P-384 | Dilithium3 | ~3700 bytes   | 3     |
+-------------+------------+---------------+-------+

PQC Algorithm Selection

Based on NIST PQC standardization:

Signatures:
+-----------+------------+----------------+-------------+
| Algorithm | Type       | Security Level | Status      |
+-----------+------------+----------------+-------------+
| ML-DSA-44 | Lattice    | NIST 2         | RECOMMENDED |
| ML-DSA-65 | Lattice    | NIST 3         | RECOMMENDED |
| ML-DSA-87 | Lattice    | NIST 5         | OPTIONAL    |
| SLH-DSA   | Hash-based | NIST 1-5       | OPTIONAL    |
+-----------+------------+----------------+-------------+

(ML-DSA is the standardized name for Dilithium)

Key Encapsulation (for future key agreement):
+-------------+---------+----------------+-------------+
| Algorithm   | Type    | Security Level | Status      |
+-------------+---------+----------------+-------------+
| ML-KEM-768  | Lattice | NIST 3         | RECOMMENDED |
| ML-KEM-1024 | Lattice | NIST 5         | OPTIONAL    |
+-------------+---------+----------------+-------------+

(ML-KEM is the standardized name for Kyber)

Migration Strategy

Phase 1 (Now - 2027): PREPARATION

• Implement hybrid signature support
• Enable hybrid as OPTIONAL
• Inventory systems requiring long-term confidentiality

Phase 2 (2027-2030): HYBRID DEPLOYMENT

• Hybrid signatures RECOMMENDED for Level 2+
• Hybrid signatures REQUIRED for Level 3
• Classical-only still accepted for Level 1

Phase 3 (2030-2035): TRANSITION

• Hybrid signatures REQUIRED for Level 2+
• Classical-only deprecated
• Begin accepting PQC-only signatures

Phase 4 (2035+): COMPLETION

• PQC-only REQUIRED for Level 3
• Classical algorithms removed from specification
• Hybrid accepted for backward compatibility

Random Number Generation

Secure random number generation is critical for all cryptographic operations.

Requirements

All random values MUST be generated by a CSPRNG that:

1. Is seeded from high-entropy sources (hardware RNG, OS entropy)
2. Has been validated (NIST SP 800-90A compliance recommended)
3. Provides at least 256 bits of security
4. Is reseeded periodically

Entropy Sources

Acceptable entropy sources:

• Hardware RNG (Intel RDRAND/RDSEED, ARM TRNG)
• Operating system entropy pool (/dev/urandom, CryptGenRandom)
• HSM hardware RNG
• Environmental noise (with appropriate mixing)

NOT acceptable as sole source:

• Timestamps
• Process IDs
• User input
• Network data

Testing

Implementations SHOULD perform entropy health checks:

• NIST SP 800-90B health tests
• Continuous random number generator testing
• Startup self-tests

Security Considerations

Algorithm Downgrade Attacks

Attackers may attempt to force use of weaker algorithms.

Mitigations:

• Require minimum algorithm strength per level
• Sign algorithm negotiation messages
• Alert on unexpected algorithm changes

Side-Channel Attacks

Cryptographic implementations may leak information through:

• Timing variations
• Power analysis
• Electromagnetic emissions
• Cache behavior

Mitigations:

• Use constant-time implementations
• Use HSMs for high-value keys
• Validate implementations against known test vectors

Key Compromise

If a key is compromised:

• Oracle signing key: Revoke immediately, rotate threshold
• Agent key: Revoke agent, invalidate trajectory
• Zone encryption key: Re-encrypt data, rotate key
• Root key: Major incident, full ceremony required

Implementation Vulnerabilities

Common vulnerabilities to avoid:

• Nonce reuse in AES-GCM (catastrophic)
• Weak random number generation
• Improper signature verification (accepting malformed)
• Memory leaks of key material
• Timing leaks in comparison operations

Implementations SHOULD use well-tested cryptographic libraries:

• OpenSSL / BoringSSL
• libsodium
• AWS-LC
• Hardware vendor libraries for HSM

IANA Considerations

Algorithm Registry

This document requests establishment of a KTP Algorithm Registry with the following initial entries:

+--------+-------------------------+-----------+--------------+
| ID     | Name                    | Type      | Reference    |
+--------+-------------------------+-----------+--------------+
| 0x0001 | ecdsa-p256              | Signature | Section 4.1  |
| 0x0002 | ecdsa-p384              | Signature | Section 4.1  |
| 0x0003 | ecdsa-p521              | Signature | Section 4.1  |
| 0x0010 | eddsa-ed25519           | Signature | Section 4.2  |
| 0x0011 | eddsa-ed448             | Signature | Section 4.2  |
| 0x0020 | threshold-frost-ed25519 | Threshold | Section 4.3  |
| 0x0030 | hybrid-ed25519-mldsa44  | Hybrid    | Section 11.2 |
| 0x0100 | sha256                  | Hash      | Section 5.1  |
| 0x0101 | sha384                  | Hash      | Section 5.1  |
| 0x0110 | sha3-256                | Hash      | Section 5.2  |
| 0x0200 | aes-256-gcm             | AEAD      | Section 7.1  |
| 0x0201 | chacha20-poly1305       | AEAD      | Section 7.2  |
+--------+-------------------------+-----------+--------------+

Algorithm Identifiers

Complete list of algorithm identifiers for use in KTP messages:

Signature Algorithms: ecdsa-p256 ecdsa-p384 ecdsa-p521 eddsa-ed25519 eddsa-ed448 threshold-shamir-ecdsa-p256-KofN threshold-shamir-ecdsa-p384-KofN threshold-frost-ed25519-KofN threshold-frost-ed448-KofN threshold-bls12-381-KofN hybrid-ed25519-mldsa44 hybrid-ed448-mldsa65 hybrid-ecdsa-p384-mldsa65

Hash Algorithms: sha256 sha384 sha512 sha3-256 sha3-384 sha3-512 shake128 shake256 blake3

AEAD Algorithms: aes-128-gcm aes-256-gcm chacha20-poly1305

KDF Algorithms: hkdf-sha256 hkdf-sha384 hkdf-sha512 argon2id

Test Vectors

B.1. Ed25519 Signature

Private Key (hex): 9d61b19deffd5a60ba844af492ec2cc44449c5697b326919703bac031cae7f60

Public Key (hex): d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a

Message: (empty)

Signature (hex): e5564300c360ac729086e2cc806e828a84877f1eb8e5d974d873e06522490155 5fb8821590a33bacc61e39701cf9b46bd25bf5f0595bbe24655141438e7a100b

B.2. SHA-256 Hash

Message: "abc"

Hash (hex): ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

B.3. AES-256-GCM Encryption

Key (hex): feffe9928665731c6d6a8f9467308308feffe9928665731c6d6a8f9467308308

IV (hex): cafebabefacedbaddecaf888

Plaintext (hex): d9313225f88406e5a55909c5aff5269a

AAD (hex): feedfacedeadbeeffeedfacedeadbeef

Ciphertext (hex): 522dc1f099567d07f47f37a32a84427d

Tag (hex): 9fc0ef3636c83f6abbe3d6a6eb0e5bba