Security That Starts at the Hardware and Ends at Your Ears

FREEPTT was designed from the ground up under the assumption that every component between two users might be adversarial. For encrypted calls: a network or server that is not your device learns nothing about audio content. For open channels: the same audio anyone in the group hears. The security model is honest about both. And it requires no account to use.

Encryption by Call Type: Honest and Precise

FREEPTT supports two voice modes. The distinction is deliberate and has legitimate uses for both.

Encrypted Calls (Private and Encrypted Group)

When you make a private call or use an encrypted group talkgroup, your voice is captured, compressed, and sealed in an encrypted envelope before it leaves your device. Only a device that holds the corresponding private key can open it. The server routes sealed packets it cannot read.

Encrypted Call Specifications
──────────────────────────────
Codec:         Opus at 8 kHz, mono, 20ms frames
Encryption:    AES-256-GCM
Key length:    256-bit session key per PTT press
IV:            12-byte random nonce, fresh per frame
Auth tag:      128-bit GCM authentication tag
AAD:           Talkgroup ID (binds ciphertext to channel)
Key wrapping:  RSA-OAEP (SHA-1/MGF1) with recipient public key
Key lifetime:  One PTT press — never reused across transmissions

The per-press key model means that even if a single session key were ever extracted from a device, it would expose at most one PTT transmission.

Open Group Channels (Unencrypted)

Open group talkgroups transmit voice without encryption. This mirrors how conventional radio channels work: no key distribution required, any authorized device can join immediately.

What open channels still provide: Every connection goes through full mutual authentication. The server verifies its own identity cryptographically. Your device's hardware-bound key proves who is transmitting. Open does not mean unverified — it means the audio content is not encrypted, but identities are still authenticated.

Two-Layer Authentication: Trust No One Layer Alone

The problem with TLS alone: TLS encrypts your connection to a server. It does not prove that the server belongs to your network. A compromised network or rogue server with a valid public-CA TLS certificate could still impersonate your operator unless you verify identity at the application layer.

Layer 1 — Transport (TLS)

TLS is used for all connections, with either public CA certificates (e.g. reverse proxy) or operator-issued certificates. This establishes encrypted transport — the first layer only.

Layer 2 — Application Authentication

After TLS, the server signs a challenge with a private key bound to a certificate issued by your operator's System CA. The client validates this using the operator CA trusted by the app. The client also signs a challenge with its device private key; the server verifies against the registered public key.

This applies to all channels — open or encrypted.

Client                        Server
  │                              │
  ├─ Layer 1: TLS ──────────────►│ Encrypted channel established
  │                              │
  ├─ Layer 2: Server proof ◄─────┤ Server signs nonce with CA-issued key
  │  Validate against bundled CA  │
  ├─ Layer 2: Client proof ──────►│ Client signs nonce with hardware key
  │                              │
  └─ Connection authenticated ───► Voice may flow (encrypted or open)

A Cryptographic Chain of Trust

Trust flows from a hierarchy of certificates — Platform Root CA, Platform Issuing CA, System CA Signing CA, per-operator System CA, then server and device certificates. Your app ships with trust anchors needed to validate operator servers.

Platform Root CA (vendor-controlled, offline)
    └── Platform Issuing CA
            └── System CA Signing CA (bundled in app)
                    └── System CA (per operator / public system)
                            ├── Server identity certificates
                            └── Device enrollment certificates (optional)

The vendor-operated public system has its own System CA under the same hierarchy. Devices use the same verification model as private deployments.

Supply Chain Integrity

Each app build embeds a Bootstrap JWT — a signed credential from the Platform Issuing CA. Servers can require this to ensure the client is a genuine vendor build, not a repackaged binary.

Hardware-Bound Device Identity

On supported Android devices, RSA keys can be generated in the hardware-backed Keystore. Your network identity is a Device Numeric Identity (DNI) derived from your public key — not linked to personal data unless you register for billing.

Voice Frame Authentication

Transmitters sign a transmission identifier on the first frame of each press so receivers and infrastructure can validate authenticity and resist audio injection.

What We Can and Cannot See

Use encrypted private or group channels for sensitive communications; use open group channels when broad coordination is the operational goal.

Threat Model (Summary)

Compare Channel Modes

Your Voice → Opus → AES-256-GCM on device → Server routes sealed packet → Decrypted on recipient device

Your Voice → Opus → Transmitted authenticated → Server verifies identity, routes → Received by group

Full Security Architecture (Docs)

Contact security