This document describes the threat model, security properties, operational best practices, and known limitations of Evaemon OTK-PQ.

1. OTK-PQ threat model
2. Three-layer security architecture
3. Algorithm selection
4. Key management
5. OTK-PQ operational security
6. Server hardening
7. Client hardening
8. Backup security
9. Key rotation policy
10. Algorithm performance
11. CVE advisories
12. Known limitations
13. Incident response

Quantum harvest attacks ("capture now, decrypt later") Session keys are hybrid (classical + post-quantum) and ephemeral. The master key is post-quantum (ML-DSA-87) and never transmitted. An adversary recording traffic today cannot decrypt it with a future quantum computer.

Key theft Stealing an ephemeral session key after use gains nothing — it is already destroyed on both client and server, and recorded in the revocation ledger. The master private key never touches the network.

Man-in-the-middle Session keys are signed by the master key. An attacker cannot forge the ML-DSA-87 signature without the master private key.

Replay attacks The revocation ledger records every used session key hash. Nonce validation (timestamp + CSPRNG) ensures temporal uniqueness. A replayed session bundle is rejected immediately.

Server compromise The server only holds master public keys. The private master key never leaves the client. A compromised server cannot forge session keys or recover the master private key.

• Initial enrollment compromise — if the first master key transfer is intercepted, the attacker has the master public key (but still needs the private key to forge sessions). If they substitute their own public key during enrollment, they can impersonate the client. Mitigate with out-of-band verification.
• Client device compromise — if the client device is fully compromised and the master private key is extracted, the system is broken. Hardware-backed key storage mitigates this.
• Side-channel attacks — this toolkit does not address timing or power side-channels in OQS library implementations.
• Denial of service — monitoring tools detect issues but do not prevent attacks on the SSH port.
• Protocol downgrade — the system's standard OpenSSH remains unchanged; clients can still connect to it unless firewalled.

Deploy keys from at least two different assumption families:

• Never share the master private key. It is the root of trust.
• Protect with a passphrase. The generation wizard prompts for this.
• Verify enrollment out-of-band. Compare fingerprints between client and server.
• Rotate annually or immediately upon suspected compromise.
• Archive old master keys — the rotation tool archives automatically.

• Private keys must have permissions 600
• Protect with a passphrase
• Generate distinct key pairs per purpose
• Verify host key fingerprints on first connection

Enrollment validation: the server validates all enrolled public keys using ssh-keygen -l -f before storing. Invalid keys are rejected. Key type is checked against OTK_MASTER_SIGN_ALGO.

Session bundle validation: before signature verification, the server validates that session public keys contain properly formatted SSH keys (correct prefix, base64 data present).

Remote script injection prevention: all variable data injected into remote scripts (session push and cleanup) is base64-encoded before interpolation. This prevents shell metacharacter interpretation ($(), backticks, ${}) if key material contains unexpected characters.

Every session bundle includes a nonce (timestamp + 32 bytes CSPRNG). The server rejects bundles with:

• Timestamps in the future (clock skew) — error includes skew magnitude and NTP recommendation
• Timestamps older than OTK_NONCE_MAX_AGE (default 300 seconds) — large deviations (>1 hour) are flagged as probable clock skew
• Non-numeric or malformed timestamps

Clock synchronisation: ensure client and server clocks are synchronised within OTK_NONCE_MAX_AGE seconds. Use NTP.

• Location: build/etc/otk/ledger/revocation.ledger
• Growth: one entry per session (~80 bytes). At 100 sessions/day, ~2.8 KB/day, ~1 MB/year.
• Pruning: entries older than OTK_LEDGER_PRUNE_DAYS (default 7) are safe to remove since nonce validation would reject them anyway.
• Concurrency: flock exclusive lock prevents corruption from simultaneous sessions.
• Maximum size: OTK_LEDGER_MAX_ENTRIES (default 100,000) triggers a pruning warning.

Session key material is destroyed using:

1. shred — multi-pass random overwrite + zero pass + unlink (preferred)
2. Manual overwrite — dd from /dev/urandom (fallback if shred unavailable)
3. Verification — post-destruction check confirms no files remain

Configure the number of overwrite passes with OTK_SHRED_PASSES (default 3). The manual overwrite fallback detects and warns on disk-full or I/O errors during each pass.

OTK-PQ uses an existing PQ or classical key to push the session bundle to the server. This "bootstrap" connection:

• Must use PQ KEX algorithms (configured automatically)
• Should use a key that is already enrolled via standard authorized_keys
• Is separate from the ephemeral session — the session key is what authenticates the actual connection

OTK-PQ uses StrictHostKeyChecking=accept-new for both the bootstrap push and the ephemeral session connection. This means:

• First connection to a new host: the server's host key is automatically accepted and saved to known_hosts. This is a TOFU (Trust On First Use) model — an attacker performing a MitM during the very first connection can substitute their own host key.
• Subsequent connections: rejected if the host key changes (standard SSH behaviour).

Mitigation: before the first OTK-PQ connection, manually verify the server's host key fingerprint via an out-of-band channel (e.g. console access), or pre-populate known_hosts:

# Pre-populate the server's host key fingerprint
ssh-keyscan -H <server_host> >> ~/.ssh/known_hosts

After pre-populating, you can set StrictHostKeyChecking=yes in your SSH config for maximum security.

PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
AllowUsers alice bob
ClientAliveInterval 300
ClientAliveCountMax 2
PermitRootLogin no

sudo ufw allow from 192.168.0.0/24 to any port 22
sudo ufw deny 22

• Verify master key fingerprints out-of-band before enrolling
• Review enrolled clients periodically: bash server/otk/otk_server.sh list
• Revoke compromised clients immediately: bash server/otk/otk_server.sh revoke <name>
• Prune the revocation ledger periodically: bash server/otk/revocation_ledger.sh prune

Host pqserver-otk
    HostName               192.168.1.10
    User                   alice
    Port                   22
    IdentityFile           ~/.ssh/id_ssh-falcon1024
    HostKeyAlgorithms      ssh-falcon1024,ssh-mldsa-87
    PubkeyAcceptedKeyTypes ssh-falcon1024,ssh-mldsa-87
    KexAlgorithms          mlkem1024nistp384-sha384,mlkem768x25519-sha256,curve25519-sha256

• Use passphrase protection on the master key
• Store on encrypted filesystem where possible
• Consider hardware-backed key storage (TPM / Secure Enclave) for high-security deployments

Backup files from client/backup.sh are encrypted with AES-256-CBC (PBKDF2, 600,000 iterations).

• Store backups offline (encrypted USB, cold storage)
• Never store a backup and its passphrase together
• After master key rotation, create a new backup and destroy the old one
• OTK session keys are ephemeral and should NOT be backed up (they are destroyed by design)

After rotation: re-enroll the new master public key on all servers.

Per-session overhead from the OTK-PQ architecture:

This overhead is negligible for interactive SSH sessions.

Recommendation: build against liboqs main (>= 0.14.0) or the latest tagged release.

The OQS-OpenSSH repository (OQS-v9 branch) is archived. It may not have received patches for all upstream CVEs.

1. OQS implementations are not yet FIPS-validated. Await formal FIPS 204/203 certification for regulated environments.

2. Initial enrollment must be secure. If the first master key transfer is compromised, the system is broken. This is a bootstrapping problem common to all PKI.

3. Revocation ledger growth. The server must maintain a record of used keys. Mitigated by time-based pruning (7-day default). The prune operation uses temp-file traps to prevent orphaned files on abnormal exit.

4. Client device compromise. If the master private key is extracted, the system is broken. Hardware-backed storage mitigates this.

5. Computational overhead. Generating fresh hybrid keys per session has a cost (~25 ms). Acceptable for SSH, potentially challenging for high-frequency connections.

6. System SSH is unmodified. Both standard and post-quantum sshd run simultaneously by default. Firewall the classical SSH port.

7. OQS-OpenSSH is archived. The upstream project is no longer actively maintained. This toolkit is built on a research-grade fork.

1. Immediately rotate the master key:

   bash client/otk/master_key.sh rotate

2. Re-enroll on all servers:

   bash client/otk/master_key.sh export > new_master.pub
   bash server/otk/otk_server.sh enroll alice new_master.pub

3. Revoke the old enrollment (if a separate client name was used)
4. Review server logs for unusual session activity

No action required — the session key is already destroyed and revoked. An intercepted session key has zero value.

1. Stop the sshd: sudo systemctl stop evaemon-sshd.service
2. Use out-of-band console access for investigation
3. After remediation:
   • Wipe and rebuild the server
   • Re-initialize the OTK-PQ server: bash server/otk/otk_server.sh setup
   • Re-enroll all client master keys
   • Rotate all client master keys (optional but recommended)

If sessions were interrupted (crash, network failure), clean up residual key material:

bash client/otk/otk_lifecycle.sh cleanup