Data protection in a corporate messenger

Why one layer of encryption is not enough

For many people, data protection in a corporate messenger comes down to one question: "are the messages encrypted?" In reality a message passes through several states during its life: it is created on your device, sent over the network, routed on the server and stored on the recipient's device. Each state has its own threat — and each needs its own protection.

That is why a serious solution is built around defense in depth: even if one layer is breached, the data stays protected by the next. Let's walk through the key layers in order.

End-to-end encryption of messages

End-to-end (E2E) encryption encrypts a message on the sender's device and decrypts it only on the recipient's device. The server sees only the encrypted bytes and cannot read the text. The modern standard is the Signal protocol: key agreement via X3DH and a fresh key for every message via the Double Ratchet.

• Forward secrecy — even if one key is compromised, older messages stay protected.
• Group chats — typically encrypted with a symmetric group key (AES-256-GCM).
• The server never sees the content — this is the core difference between E2E and ordinary "server-side encryption".

Data on the device (encryption at rest)

E2E only protects data "in transit". But once a message is received, it is stored in the device's local database. If that database is in plaintext, the entire message history can be read from a stolen or uncontrolled laptop.

The fix is to encrypt the local database. On desktop clients a common approach is SQLCipher: a layer on top of SQLite where the whole database file is written to disk encrypted with AES. Even if the database file is stolen, it cannot be opened without the key.

Keys in the OS secure store

The most sensitive element is the encryption keys. They must not be sent to the server, appear in logs, or sit in a plain configuration file. The right approach is to hand the keys to the operating system's dedicated secure store:

• Windows — DPAPI / Credential Manager, bound to the user session.
• macOS — Keychain.
• Linux — Secret Service (keyring).

Then only the correct user, and only within their own session, can unlock the key. Someone who logs in under a different profile or mounts the disk separately cannot reach it.

Protection in transit, access control and data residency

Three more important elements complete the defense in depth:

• TLS 1.3 — all traffic between the device and the server travels through an encrypted channel. This protects metadata and authentication tokens from man-in-the-middle attacks.
• RBAC (role-based access control) — defines at the role level who can access which channels, documents and modules. It guards against insider threats and excessive privileges.
• Data residency — whichever country the servers sit in, that jurisdiction applies. For organizations in Uzbekistan, keeping data inside the country or in their own infrastructure is a sovereignty requirement.

A practical checklist

• Are messages truly E2E (the server never sees plaintext)?
• Is the local database encrypted on disk (at rest)?
• Are keys stored in the OS secure store?
• Does all traffic run over TLS 1.3?
• Is access restricted by roles (RBAC)?
• Where is the data physically stored, and who is the provider?

How HAMA handles this

HAMA — a single secure platform for organizations in Uzbekistan — combines all of the layers above:

• Messages are E2E encrypted with the Signal protocol (X3DH + Double Ratchet); groups use AES-256-GCM.
• The local database is encrypted with SQLCipher, so data is protected at rest on the device.
• Encryption keys are stored in the operating system's secure store.
• All transport runs over TLS 1.3 only.
• Access is governed by RBAC; available modules include the messenger, video conferencing, HR/org structure, helpdesk and more.
• The server is hosted in a secure data center in Uzbekistan or in the organization's own infrastructure (on-premise) — data stays in Uzbekistan.

HAMA is also preparing for compliance with O'z DSt ISO/IEC 27001:2023 and the PP-167 requirements (critical information infrastructure).