Security whitepaper

Summary

Ease is a messaging platform where message content is end-to-end encrypted on the sending device before it leaves, and decrypted only on the recipients’ devices. The servers store and route ciphertext they cannot read. Encryption keys are generated and held on user devices; the server never receives a private key. This holds on every platform Ease ships: web, iOS, macOS, Android, and Windows.

The consequence for a reviewer is direct. The most common question in a vendor security review, who at the vendor can access customer content, has a structural answer here: no one, because the infrastructure never holds the keys to decrypt it. That narrows the blast radius of most of the risks a review is designed to find.

Threat model

Ease is designed to protect message content against:

• A network attacker between the client and the server, or between servers.
• The server operators and the hosting providers: a compromised or curious operator, or a subpoena served on the infrastructure, cannot yield readable message content.
• Theft of data at rest, on the server or on an idle device whose local store is encrypted.

Ease does not claim to defend against two classes, and says so plainly:

• Metadata. The fact that a message was sent, between which accounts, when, and the membership and roles of a group, is visible to the server. Content is private; the existence of communication is not.
• A compromised endpoint. A device already controlled by an attacker, or a web page running hostile code in the same origin, has the access the legitimate user has. Encryption protects data in transit and at rest, not a live compromised endpoint.

Encryption design

Ease encrypts on the client with libsignal, the library behind the Signal Protocol. The choice is deliberate: libsignal is a widely reviewed, open-source implementation of a protocol with a long public track record, rather than a bespoke scheme.

Direct messages

One-to-one conversations use the Double Ratchet. Each message is encrypted with a fresh key derived from a ratchet that advances per message, so a key recovered from one message does not decrypt earlier or later ones (forward secrecy and post-compromise recovery). The initial key agreement uses per-user prekeys published by the SDK, including post-quantum (Kyber) prekeys under the PQXDH scheme, so a sender can start an encrypted session with a recipient who is offline and the key agreement resists harvest-now-decrypt-later attacks by a future quantum adversary.

Group messages

Group conversations use Sender Keys. Each member encrypts once with a sender key distributed to the group, rather than re-encrypting per recipient device, which keeps group messaging efficient without weakening the end-to-end property. Membership changes rotate the relevant keys.

Key management

Keys are generated on the device at sign-up and never leave it in the clear. The SDK manages every key; integrating code never handles a private key, and the server never receives one.

Where keys live at rest

• Native (iOS, macOS, Android, .NET). Private keys are held in the operating-system keystore (Keychain, Keystore, DPAPI), the strongest local protection each platform offers.
• Web. The local key store is encrypted with a key the SDK never persists in the clear, derived from a user secret. At-rest encryption protects the offline case (a copied browser profile); the running page remains the trust boundary, per the standard browser model.

Multiple devices and accounts

Linked devices each hold their own encrypted key store; the linking exchange establishes trust without the server learning the keys. On shared installs, the SDK guards against one account’s key store being used under another account’s identity.

Identity and authentication

• End users verify with a one-time code delivered to an email address or phone number. Sessions are carried by signed tokens; the signing secret stays server-side and tokens are validated on every request.
• Tenant administrators sign in to the management dashboard with passkeys (WebAuthn), so there is no admin password to phish or reuse.

What the server sees

The server stores and routes ciphertext. It sees the routing metadata described in the threat model (which accounts communicate, timing, group membership and roles) and the operational data needed to run the service (account identifiers, device and diagnostic information). It does not see message content, media content, or any private key.

Traffic between clients and the service, and between services, is carried over TLS. The real-time transport and the request path are separated so that the socket layer carries only what it needs to.

Media and attachments

Shared media is encrypted on the device with a per-object key derived from the conversation’s key material, then uploaded as ciphertext to object storage. The storage provider holds encrypted bytes and never receives the decryption key, which is delivered to recipients through the same end-to-end channel as messages. A stored object is unreadable to the storage provider and to Ease.

Groups

Group messaging uses Sender Keys, as above. Group membership and member roles are managed server-side and are part of the metadata the server can see; the content exchanged in the group is not. Administrative actions within a group (for example moderation) act on membership and delivery, not on the plaintext of past messages, which the server never held.

Infrastructure

The production services run on a Kubernetes cluster on dedicated European hosting. Several practices harden the operational surface around the encrypted data:

• Secret management.Tenant-level secrets are encrypted through a dedicated secrets manager (HashiCorp Vault) whose master key is auto-unsealed by a cloud key-management service, so the keys that protect at-rest secrets are not sat next to the data they protect.
• Database durability. The primary datastore runs under an operator that provides high availability and continuous backup, with write-ahead logs shipped to object storage; disaster-recovery restores have been rehearsed and evidenced.
• Encrypted object storage.Media ciphertext is stored separately from the primary database.

Operational security

• Change control. Changes land through pull requests gated by an automated verification suite; the same gate runs before every push. Cross-service, security-relevant, and capacity changes require a runtime-evidence proof bundle before they merge.
• Dependency currency.External dependencies are inventoried in a ledger and checked against upstream on a regular cadence, so a known vulnerable version is caught rather than aged into.
• Least standing access.Because message content is never decryptable server-side, operational access to the infrastructure does not translate into access to customer content.

Data lifecycle

Account and profile information is retained while an account is active. Encrypted message content is retained as needed to deliver it to a user’s devices. A user can delete their account, after which the associated personal information is deleted, except where retention is required by law. The current handling is described in the privacy policy.

Compliance and governance

Ease acts as a data processor for its customers’ end users. Because content is end-to-end encrypted, the data Ease processes on a customer’s behalf is largely ciphertext and routing metadata rather than readable content.

• The third parties that process data on Ease’s behalf are listed on the subprocessors page.
• Security issues can be reported under the vulnerability disclosure policy.
• A formal compliance program (independent audit, penetration testing) is being established; this document will reference those reports as they are available. Ease does not claim a certification it does not hold.

The honest boundary

Ease does not hide metadata, and it does not defend a fully compromised device beyond the standard platform model. What it guarantees is the part that matters most, and guarantees it by construction rather than by policy: the content of a message is readable only by its participants, on every platform, by default. The infrastructure cannot read it, which means no operator, no hosting provider, and no legal order served on Ease can produce it.