Isidore Quantum® and Cassian™: A Secure Framework for Key Management, Zeroization, and Cryptographic Resilience

Isidore Quantum Resources

Whitepapers

Both devices (A and B) must be in a trusted state and physically or logically isolated during initial provisioning.

Access to a secure entropy source (FIPS 140-compliant RNG, hardware RNG, or approved nondeterministic behaviors).

Administrative credentials and access to management console, if remote zeroization or provisioning will be used.

Generate and securely load Key 0 (K0) into both nodes A and B.

K0 may be:

A random value R, or

A derived value from local material + second factor (e.g., token + stored bits).

Upon acceptance of K0, each device enters Provisioning Mode.

K0 establishes AES-256 Tunnel 0, creating a trusted communication path.

Ensure Tunnel 0 starts only after both nodes have securely received K0.

Knowledge of K0 alone does not enable MITM (man-in-the-middle) attacks when both nodes exchange initial packets.

Node A initiates an ML-1024 KEM with Node B, producing Key 1 (K1)

Destroy Tunnel 0

Create AES-256 Tunnel 1 using K1

Node B initiates an ML-1024 KEM, producing Key 2 (K2)

K2 = Hash(K1 + New Shared Secret)

Destroy Tunnel 1 and create AES-256 Tunnel 2 using K2

At this stage, the active shared secret is derived from the entropy of both A and B, ensuring strengthened assurance

Within Tunnel 2, negotiate:

Ephemeral DSA87 key pairs (public portions exchanged).

MTU settings, link timeout, and policy parameters

Upon completion, transition devices to Operational Mode

Returning either node to Provisioning Mode halts operational data flow until provisioning is re-completed

Nodes A and B alternate initiating ML-1024 KEM rekey transactions on a pre-defined schedule (e.g., every 2 minutes)

Each rekey generates:

If key drift is detected, initiate a recovery transaction using stored recovery keys to resynchronize the channel

Trigger a zeroize transaction under the following conditions:

Zeroization destroys the keystore of at least one node, rendering the channel inoperable

If a keystore is compromised without zeroization, only the last session’s data may be exposed

Re-provisioning is required before resuming EUD channel operations

All keys are cryptographically wrapped under a hardware root of trust

Keys are stored persistently and unwrapped only into volatile memory when needed

Isidore Quantum nodes continuously harvest entropy from:

Strong and weak entropy sources continuously feed local entropy pools

Entropy pools of A and B may be combined during key exchanges, strengthening randomness guarantees

Isidore Quantum nodes continuously harvest entropy from:

Strong and weak entropy sources continuously feed local entropy pools

Entropy pools of A and B may be combined during key exchanges, strengthening randomness guarantees

Ensure all provisioning actions occur in a trusted facility or through authenticated black-side transport

Never export or reuse session keys; keys must be destroyed upon tunnel teardown

Operational mode must be disabled during re-provisioning to prevent leakage of unencrypted data

AES-256 (FIPS 197)

ML-KEM (NIST PQC candidate, lattice-based)

DSA87 ephemeral key pairs

FIPS 140-3 compliant RNG