Encrypted Communications Infrastructure

2.1 DTLS-SRTP Overview

Voice Connect+ uses DTLS (Datagram Transport Layer Security) for key exchange and SRTP (Secure Real-time Transport Protocol) for media encryption. DTLS performs a handshake between call participants to establish a shared secret, which is then used to derive SRTP session keys. Media is encrypted with AES-128-GCM or AES-256-GCM (configurable per deployment).

The critical design decision is where the DTLS handshake occurs. In Voice Connect+, the handshake is performed directly between call participants via the VPX signalling layer. VoicePro Plus infrastructure routes the DTLS handshake messages but never participates in the key exchange. The resulting SRTP session keys exist only on the participants' devices - our servers never hold, see or process them.

2.2 Per-Session Keys

Every call generates a unique set of SRTP session keys via a fresh DTLS handshake. Keys are derived from ephemeral Diffie-Hellman parameters that are discarded after the handshake completes. This means that even if a session key is somehow compromised, no past or future calls are affected - each call is cryptographically independent.

For group calls (up to 500 participants on dedicated infrastructure), a server-side Selective Forwarding Unit (SFU) handles media distribution. The SFU operates on encrypted streams - it forwards SRTP packets without decrypting them. Group key management uses a ratcheting protocol where each participant holds a unique per-sender key, derived from the group session key.

2.3 Signalling Security

Call signalling (setup, teardown, presence) is transported over TLS 1.3. Signalling metadata (who called whom, when, duration) is necessarily visible to VoicePro Plus infrastructure for call routing purposes. However, signalling metadata retention is governed by the client's data processing agreement and can be configured from zero-retention to 12-month retention based on regulatory requirements.

3.1 Double Ratchet Implementation

Messaging Connect+ is built on the open Matrix protocol's Olm and Megolm ratchets - the same family of forward-secret cryptography that underpins modern secure messengers. One-to-one device sessions use Olm, an implementation of the Double Ratchet that pairs a Triple Diffie-Hellman (3DH) initial key exchange with a per-message ratchet over Curve25519; group and room messages use Megolm, a sender ratchet that derives a fresh key for every message.

3.2 Initial Key Exchange (3DH)

On first contact between two users, the Messaging Connect+ SDK performs an asynchronous Triple Diffie-Hellman (3DH) key exchange using Curve25519 elliptic curve keys. The exchange produces a shared secret without requiring both parties to be online simultaneously - critical for messaging use cases where recipients may be offline when the first message is sent.

The exchange uses three key pairs per user: an identity key (long-lived), a signed pre-key (rotated periodically) and one-time pre-keys (single-use, uploaded in batches). The combination provides authentication (identity keys verify sender identity), forward secrecy (one-time pre-keys ensure each session is unique) and offline availability (pre-keys are stored server-side for asynchronous exchange).

3.3 Per-Message Ratchet (Olm and Megolm)

After the initial 3DH exchange, one-to-one device sessions use Olm - an implementation of the Double Ratchet - while group and room messages use Megolm, a sender ratchet. In both, each message derives a unique encryption key via a chain of HMAC-based key derivation functions, and the ratchet advances with every message. This provides:

• Each message is encrypted with a unique key (no key reuse).
• Forward secrecy: past messages cannot be recovered from a device's current ratchet state. For one-to-one Olm sessions this is complete; for Megolm group sessions it is partial - a compromised ratchet value can expose that and subsequent messages until the session is re-keyed.
• Post-compromise security (break-in recovery) on one-to-one Olm sessions: after a temporary key compromise, later messages become secure again once the ratchet advances.
• Megolm group sessions do not provide post-compromise security on their own; instead they are re-keyed on membership changes and periodically (typically weekly, or after a set message count) to bound the exposure of any single key.

3.4 Fallback Delivery for Recipients Without the App

For recipients without a smartphone app, Messaging Connect+ delivers encrypted payloads via standard SMS infrastructure. The encrypted message is submitted to VoicePro Plus as cyphertext. We deliver it via our SMS termination infrastructure to the recipient's handset. The SMS contains a short-lived URL (configurable expiry: 1 hour to 7 days) pointing to a browser-based decryption page.

The recipient opens the URL in any browser. The decryption key is embedded in the URL fragment (after the # symbol), which is never sent to the server. Decryption occurs entirely client-side in the browser. VoicePro Plus infrastructure serves the encrypted payload but cannot decrypt it - the key exists only in the URL that was delivered to the recipient's device.

5.1 Lawful Intercept Considerations

VoicePro Plus cannot comply with content-level lawful intercept requests because our infrastructure does not hold decryption keys. We can provide metadata (session records: who, when, duration) subject to lawful authority. For clients in regulated industries that require key escrow for internal compliance purposes, a client-managed key escrow option is available. The escrow is held by the client - not VoicePro Plus - ensuring that the zero-knowledge guarantee is maintained from our perspective.

The UK Investigatory Powers Act 2016 additionally provides for Technical Capability Notices, under which the Secretary of State may require an operator to maintain prospective technical capabilities. Any such notice served on VoicePro Plus would be assessed with counsel at the time, within the review and consultation mechanisms the Act itself provides. This section will be extended following formal counsel review of the TCN regime as it applies to the architecture described in this paper.

6.1 In Scope (what the encryption defends)

Content confidentiality is protected against every party in the transport path: passive or active network interception, a compromised or legally compelled carrier, VoicePro Plus infrastructure and staff (the zero-knowledge property), a breach of our servers, and content-level lawful intercept served on us. Because we hold no keys, we can produce only cyphertext. Against these adversaries the words of a message and the audio of a call are structurally unreadable, including to a well-resourced state actor intercepting the network or compelling the carrier.

6.2 Out of Scope (what transport encryption cannot defend)

End-to-end encryption protects data in transit and denies content to the carrier. It does not protect an endpoint that has already been compromised, and it does not conceal the fact that communication took place. These limits are inherent to end-to-end encryption and apply equally to every system in this class, including the most widely deployed secure messengers.

• Endpoint compromise: a device compromised by commercial mobile-surveillance spyware, a malicious application, or physical access to an unlocked handset can read content after it is decrypted, on the device. A capable state actor typically targets the endpoint rather than the cryptography. This is outside the scope of transport encryption.
• Metadata: signalling metadata - participants, timing, duration, IP address - is processed for routing and is not concealed by content encryption. Deployments requiring metadata protection need additional controls.
• Key authentication: the end-to-end guarantee assumes participants verify each other's device keys via cross-signing. Without verification, an adversary controlling the key-distribution layer could attempt an active man-in-the-middle; device verification is provided to detect this.
• Group forward secrecy: Megolm group sessions provide only partial forward secrecy and no post-compromise security on their own (see Section 3.3); sessions are re-keyed to bound the exposure of any single key.
• PSTN and standard SMS boundary: encryption applies to VPX Voice Connect+ and Messaging Connect+ sessions between participating endpoints. Calls or messages that bridge to the public telephone network or standard SMS are not end-to-end encrypted beyond the VoicePro boundary.