Skip to main content

Security

Security built from
first principles.

Every cryptographic decision in IMCS was made to satisfy the requirements of national security, not consumer convenience. Here is exactly what we built and why.

End-to-End Encryption

The server cannot read your messages.

Every message is encrypted on the sender's device with a key that only the recipient can derive. The IMCS server transports ciphertext blobs — it has no key, no plaintext, no ability to decrypt.

  • 1. Sender encrypts with recipient's session key
  • 2. Server stores and forwards ciphertext only
  • 3. Recipient decrypts on-device with private key
  • 4. Session key rotates after every message (Double Ratchet)
SENDplaintext
encrypt(plaintext, session_key) → ciphertext
SERVERciphertext only
store_and_forward(ciphertext)
RECVplaintext
decrypt(ciphertext, session_key) → plaintext

Signal Protocol

Double Ratchet forward secrecy.

IMCS uses the same Double Ratchet algorithm developed for the Signal Protocol. After every message, the encryption key rotates forward. A compromise of today's session key cannot decrypt yesterday's messages — and cannot decrypt tomorrow's.

Forward Secrecy

Past messages remain secure even if a current key is compromised.

Future Secrecy

A single compromised key cannot decrypt future messages — the chain self-heals.

Per-Message Keys

Every message has a unique symmetric key, derived from a forward chain.

Cryptographic Architecture

Military-grade encryption.
Quantum-resistant future.

Every cryptographic primitive is NIST-approved. Post-quantum hybrid key exchange ships today — not as a roadmap item.

Read the technical spec →

Key Exchange

X25519 + ML-KEM-768

Hybrid post-quantum key exchange. Classical and post-quantum protection in parallel. NIST FIPS 203.

Messaging

Signal Double Ratchet

AES-256-GCM symmetric encryption. HKDF-SHA256 key derivation. Forward secrecy guaranteed.

Signatures

Ed25519 + Dilithium-3

Dual hybrid JWT signing. Both classical and post-quantum signatures on every token. NIST FIPS 204.

Key Storage

Hardware-Backed Keys

iOS Secure Enclave · Android StrongBox · Windows TPM 2.0. Private keys never leave hardware.

Transport

mTLS Everywhere

TLS 1.3 with mutual authentication on all service-to-service communication. CFSSL PKI.

Calls

DTLS-SRTP

All voice and video encrypted with DTLS-SRTP. WebRTC via self-hosted SFU — no media relay outside your network.

Post-Quantum Migration

Quantum-resistant today.

IMCS ships post-quantum hybrid encryption in production today — not as a future roadmap item. Migration is staged in three phases.

Phase 1

Hybrid TLS

X25519MLKEM768 hybrid key exchange on every TLS 1.3 connection. Active in production.

In production
Phase 2

Hybrid JWT

Dual-signed JWTs (Ed25519 + Dilithium-3) on every authentication token. Active in production.

In production
Phase 3

Hybrid messaging

Post-quantum key encapsulation in the Signal Protocol session key derivation chain.

Rolling out

Key Ceremony

Two-officer Root CA generation.

The Root CA private key never exists outside an HSM. Two authorised officers must be physically present to initialise the ceremony, generate the key, and produce the intermediate certificate authorities. Every step is video-recorded and cryptographically attested.

  1. 1Air-gapped HSM initialised in dual-control mode
  2. 2Officer A and Officer B authenticate with hardware tokens
  3. 3HSM generates Root CA key — private key never exfiltrated
  4. 4Intermediate CAs signed for services and clients
  5. 5Witness signatures recorded; ceremony report archived

FIPS 140-3 Compliance

NIST-approved primitives only.

PrimitiveAlgorithmStandard
Symmetric encryptionAES-256-GCMFIPS 197 / SP 800-38D
HashingSHA-3-256, SHA-256FIPS 180-4 / FIPS 202
Key derivationHKDF-SHA256SP 800-108
Asymmetric (classical)X25519, Ed25519SP 800-186
Asymmetric (PQ KEM)ML-KEM-768FIPS 203
Asymmetric (PQ sign)Dilithium-3FIPS 204
Random bit generationCTR_DRBGSP 800-90A

Audit Architecture

Tamper-evident audit logs.

Every administrative action, every key operation, every login is recorded in an append-only audit log. Each entry is hashed and chained to the previous entry — any tampering is immediately detectable. Logs ship to an HSM-signed offsite WORM store.

Deployment

Air-gap deployment architecture.


┌─────────────────────────────────────────────────────────┐
│              SECURE ENCLAVE / CLASSIFIED LAN            │
│                                                         │
│   ┌──────────┐   ┌──────────┐   ┌──────────────────┐    │
│   │  Auth    │   │ Gateway  │   │  Media SFU       │    │
│   │  +Vault  │◀─▶│  +Mesh   │◀─▶│  (mediasoup)     │    │
│   └──────────┘   └──────────┘   └──────────────────┘    │
│         ▲              ▲                ▲               │
│         │              │                │               │
│   ┌─────┴──────────────┴────────────────┴────────┐      │
│   │       Internal mTLS · No egress · WAL        │      │
│   └──────────────────────────────────────────────┘      │
│                                                         │
└────────────────────[ AIR-GAPPED ]───────────────────────┘
                              ╳ no internet ╳

Found a vulnerability?

We welcome responsible disclosure from security researchers. Read our policy and reporting process.

Responsible Disclosure Policy

Ready to inspect IMCS in detail?

Request a security architecture briefing or arrange an on-site source code review under NDA.

Request Security Briefing →Download Technical Spec