Device Verification and Identity Trust in Enterprise End-to-End Encryption: Comparative Analysis and Implementation Strategy

The implementation of End-to-End Encryption (E2EE) within enterprise collaboration platforms represents a fundamental shift in the architecture of digital trust. In traditional Transport Layer Security (TLS) models, trust is centralized and hierarchical; the client trusts the server via a Certificate Authority, and the server acts as the ultimate arbiter of identity. However, E2EE decentralizes this trust model, shifting the locus of verification from the server to the endpoints—the users and their specific devices. This architectural pivot introduces a critical vulnerability known as the "new device" attack vector. If a malicious actor can register a new device against a user's account without verification, they can silently decrypt future messages, effectively bypassing the encryption guarantees that E2EE promises.

For Mattermost, a platform deeply embedded in critical infrastructure, defense, and high-compliance industries, the challenge is not merely cryptographic but operational. The requirement to verify every new device using an existing device—establishing a chain of trust—is the gold standard for preventing Man-in-the-Middle (MITM) attacks. However, this requirement sits in direct tension with usability. As observed in the consumer market, excessive security friction leads to user fatigue, where warnings are ignored and verification processes are bypassed.

This report provides an exhaustive analysis of device verification flows across the secure messaging landscape. We examine the "Trust On First Use" (TOFU) paradigms of WhatsApp and iMessage, the strict verification models of Signal, the cross-signing architecture of Element (Matrix), and the enterprise-controlled environments of Wire and Wickr. By synthesizing these approaches with the specific operational needs of the enterprise—such as device loss recovery, employee turnover, and auditability—we propose a comprehensive implementation strategy for Mattermost. This strategy prioritizes "positive friction," ensuring security decisions are conscious and deliberate without impeding the velocity of collaboration.

To understand the proposed solutions, one must first dissect the underlying cryptographic and psychological mechanisms that govern device verification.

In protocols derived from the Double Ratchet (such as Signal, Olm/Megolm), conversation security relies on the exchange of public key bundles. When User A sends a message to User B, User A’s device retrieves User B’s pre-keys from the server. If the server is compromised or coerced, it could insert a "ghost device"—a malicious public key owned by an attacker—into User B’s account. User A’s client, seeing a new device for User B, might automatically encrypt the message for this new key, thereby allowing the attacker to read the message. Verification is the only defense against this. It forces User A (or User B) to cryptographically prove that the new device key truly belongs to User B.¹

The industry is divided into two primary philosophies regarding key acceptance.

• TOFU (Trust on First Use): Used by WhatsApp and iMessage, this model assumes that any new key provided by the server is valid. It prioritizes convenience. If a user adds a new iPad, their contacts automatically start encrypting to it. The security mechanism is reactive: contacts receive a notification after the fact stating, "Security Code Changed." Research indicates that most users ignore these warnings or lack the context to interpret them as a threat.³

• Explicit Verification: Used by Signal (in safety number workflows) and Element (in cross-signing), this model treats new keys as untrusted until proven otherwise. Users must actively verify the new device, often by comparing a Short Authentication String (SAS) or scanning a QR code. This blocks the "ghost device" but introduces significant friction.²

Verification often involves comparing cryptographic fingerprints (e.g., a 60-digit hexadecimal string). Studies in usability security have repeatedly shown that humans are incapable of reliably comparing long strings. They typically check the first and last few characters, a behavior known as "partial match verification," which attackers can exploit by generating collision keys that match only the visible ends. To counter this, modern protocols utilize SAS—short, distinct sequences derived from the key exchange. Element’s implementation utilizes emojis (e.g., a unicorn, a taco, a balloon) rather than numbers, leveraging the human brain’s superior capacity for image recognition to improve verification speed and accuracy.¹

The concept of "positive friction" is essential in security UX design. It involves deliberately slowing the user down at critical decision points to prevent automatic, error-prone behaviors. In the context of device verification, positive friction means forcing the user to engage with a verification modal on their primary device before the secondary device is granted access to the encrypted history. This friction is "positive" because it protects the user from the catastrophic consequence of identity compromise, provided it is implemented at the right moment and does not become a repetitive nuisance.⁸

The consumer market offers valuable lessons in user behavior, particularly regarding the trade-off between security and convenience.

Signal represents the strictest adherence to verification protocols. Its approach to device linking is rooted in the assumption that the user’s primary mobile device is the "root of trust."

When a Signal user attempts to link a new Desktop instance or an iPad (secondary device), the flow is strictly unidirectional. The new device generates a QR code containing its public identity key. The user must physically unlock their primary phone, navigate to "Linked Devices," and scan this code. This proves physical possession of the trusted root device. There is no password-based login for secondary devices; the QR scan is the authentication and verification mechanism combined.⁵

Signal manages identity via "Safety Numbers" (fingerprints). If a user reinstalls the app or switches phones without a backup transfer, their underlying keys change. This triggers a "Safety number has changed" alert for all contacts. Signal’s recovery model is notable for its lack of persistence: if a user loses their phone and has no linked devices, their cryptographic identity is lost. They must register as a "new" user (cryptographically speaking), and all past message history is inaccessible. While acceptable for a privacy-focused consumer app where "forward secrecy" is paramount, this "burn it down" model is incompatible with enterprise requirements for data retention and business continuity.¹¹

Users frequently encounter friction during the QR scanning phase. Common issues include "Network Error" or "No Usable Data Found," often caused by network segregation between the mobile device and the desktop (e.g., corporate Wi-Fi blocking peer discovery).¹⁰ Additionally, the strictness of the "Safety Number Changed" alert has led to alert fatigue. When users see this alert frequently (due to contacts buying new phones), they are conditioned to click "Accept" without verifying, undermining the security guarantees.¹⁴

WhatsApp operates at a scale where manual verification of every device is impossible. Consequently, it employs a TOFU model enhanced by transparency logs.

WhatsApp allows users to verify E2EE status by scanning a contact's QR code or comparing a 60-digit numeric string. This screen is buried deep in the contact info menu, indicating it is an optional power-user feature rather than a mandatory workflow. The sheer length of the 60-digit code makes it practically unusable for casual verification, serving more as a "security theater" artifact than a practical tool.³

To address the usability issues of manual verification, WhatsApp (Meta) has deployed an Auditable Key Directory based on Key Transparency. This system allows the client to automatically verify that the key it receives from the server is the same key seen by everyone else, preventing the server from serving a targeted malicious key to a specific user. This backend automation reduces the need for the user to manually verify codes, effectively shifting the burden from the user to the infrastructure.¹⁷

Unlike Signal, WhatsApp ties identity heavily to the phone number and allows for cloud backups (encrypted with a separate key). However, the device linking flow remains similar: a QR scan from the mobile app to the web client. If the security code changes, the passive notification system ("Security code changed. Tap for more info") is designed to be non-intrusive, prioritizing message delivery over strict security blocking.⁴

Apple’s iMessage historically completely obfuscated key management. Users had no way to verify keys even if they wanted to. Recently, Apple introduced "Contact Key Verification" to address this gap for high-threat targets (journalists, politicians).

This opt-in feature provides a mechanism to manually compare verification codes. When enabled, if an unrecognized device is added to a contact's account, iMessage alerts the user and suggests verification. This flow acknowledges that for 99% of users, invisible security is preferred, but provides a "strict mode" for the 1% who need it. The alert system here is designed to be alarming ("An unrecognized new device was added..."), contrasting with WhatsApp's passive notification.¹⁹

iMessage leverages iCloud Keychain to sync trust. If a user adds a Mac to their Apple ID, the keys are synced via the keychain. Trust is transitive: if you trust the Apple ID, you trust the devices it authorizes. This essentially delegates trust to the Apple ID password and 2FA, rather than the device keys themselves.²¹

The Matrix protocol (via the Element client) offers the most relevant architectural reference for Mattermost. It grapples with the same open-ecosystem and multi-device challenges, and its solution—Cross-Signing—is the industry benchmark for solving the "whac-a-mole" verification problem.

In early Matrix versions (and current Signal), if User A has a phone and a laptop, User B sees two distinct identity keys. User B must verify both. If User A adds a tablet, User B sees a third key and must verify that too. In an enterprise with thousands of users each having multiple devices, this O(n*m) verification complexity is unmanageable.

Cross-signing introduces a hierarchy of keys:

1. Master Key: The root identity of the user.

2. Self-Signing Key: Used by the user to sign their own devices.

3. User-Signing Key: Used to sign other users' master keys.

When User A logs into a new device (Device 2), they do not ask User B to verify it. Instead, User A uses their already-trusted Device 1 to verify Device 2. Device 1 signs Device 2 using the Self-Signing Key. Because User B has already verified User A’s Master Key, and the Master Key trusts the Self-Signing Key, User B’s client automatically trusts the new Device 2. This reduces the verification burden to O(n).¹

The user experience of this flow is complex.

1. New Session: The user logs in on a new device.

2. The Toast: A toast appears: "Verify this login. Verify this device to access encrypted message history."

3. The Handshake: The user opens their existing device. A corresponding dialog appears: "New login detected. Was this you?"

4. SAS Comparison: Both devices display a sequence of emojis (e.g., Rabbit, Heart, Anchor). The user confirms the match.

5. Completion: The green shield icon (verified status) appears on the new device.¹

While cryptographically sound, Element’s implementation suffers from fragility.

• Race Conditions: Users report getting stuck on "Waiting for other device..." spinners. This occurs when the server fails to route the to-device messages required for the SAS handshake instantly, or if the user attempts to verify before the initial sync is complete.²³

• Toast Fatigue: If a user has multiple old sessions (e.g., old browser tabs), they might receive a barrage of "Verify this session" requests, leading to confusion about which session is being verified.²⁵

• Terminology Confusion: The distinction between "Verifying a Login" (connecting a new device) and "Secure Backup" (entering a recovery phrase) is often blurred in the UI, leading users to abandon the flow.²⁶

If a user loses all trusted devices, they cannot cross-sign a new one. Matrix solves this with "Secure Backup." The user creates a "Security Phrase" or "Recovery Key" during setup. This key encrypts the private keys on the server. A new device can be bootstrapped by entering this phrase, effectively using the phrase as a "paper device" to sign the new login. This is a critical requirement for enterprise continuity.²²

While Signal and Matrix focus on user sovereignty, enterprise tools like Wire, Wickr, and Slack EKM must serve the organization's need for control, compliance, and continuity.

Wire combines E2EE with administrative oversight.

• Device Fingerprints: Similar to Signal, users can toggle devices to "Verified" status. However, Wire exposes a list of devices in the settings that allows for granular management.²⁸

• Admin Revocation: Crucially, Wire allows enterprise administrators to remove devices from a user's account via an admin console. This "Remote Wipe" capability is essential for offboarding employees. If an employee leaves, the admin revokes their device keys, ensuring they can no longer decrypt new messages or access the network, even if they possess the physical device.²⁹

Wickr (AWS) employs a unique approach to device addition to maintain its rigorous security posture.

• Device Cloning: Adding a secondary device involves a "sync" process where the primary device physically encrypts and transfers the database (keys and history) to the new device via a direct connection or ephemeral cloud storage. This is distinct from simply signing a new key; it is replicating the cryptographic state.³⁰

• Master Recovery Key (MRK): Wickr enforces the creation of an MRK—a complex text string or QR code—during onboarding. This key is the only way to recover an account if devices are lost. For enterprise deployments, organizations often mandate the storage of these keys (escrow) to prevent data loss, a sharp contrast to Signal's non-recovery model.³¹

• Admin Controls: Wickr’s architecture allows for "Bot" integrations that can participate in conversations for compliance logging, bridging the gap between E2EE secrecy and regulatory audit requirements.³²

Although less active now, Keybase’s "Paper Key" concept remains a powerful reference.

• Paper Key: Users are prompted to generate a "Paper Key" (a sequence of random words) that acts as a standalone device in their signature chain. This allows users to revoke lost devices even if they have no other digital devices active. However, research highlights that users often treat this insecurely, storing it in digital notes rather than physical safes, or losing it entirely.³³

It is important to distinguish Slack’s EKM from true E2EE.

• BYOK (Bring Your Own Key): Slack EKM allows enterprises to manage the encryption keys used by Slack’s servers to encrypt data at rest. The keys are stored in AWS KMS. This gives the enterprise the power to revoke access (by revoking the key in KMS), instantly locking out all users. However, this is not E2EE; Slack’s servers still have access to the data to perform search and indexing. It protects against AWS disk theft, not against Slack itself or a compromised server process. Mattermost’s goal is true E2EE, making this model insufficient for the specific requirement, though the "Admin Revocation" principle is shared.³⁵

One of the most significant findings from the Element/Matrix analysis is the failure of non-blocking "Toasts" for critical security actions.

• Problem: A small toast asking to "Verify this login" is easily missed or ignored, leaving the session in a "grey," unverified state. The user continues messaging, unaware they are vulnerable to MITM.

• Solution: Verification must be a Modal experience on the new device. The user should not be able to interact with the app (read history, send messages) until they either verify the device or explicitly opt-out (entering a "quarantine" or "limited" state).

• QR Codes: The fastest method ("Happy Path"). It requires camera permissions, which can be a friction point on Desktop apps (where cameras might be disabled or covered).

• SAS (Emoji): The best fallback. It works without cameras and is cross-platform.

• Numeric Strings: To be avoided. 60-digit codes (WhatsApp) are unusable. Hex strings (Signal’s old model) are error-prone.

• Insight: The verification flow must support both bidirectionally. A mobile device can scan a desktop (easy). A desktop scanning a mobile device is awkward (holding phone up to webcam). Therefore, the flow should be context-aware: if the new device is Desktop, show a QR code. If the new device is Mobile, ask to scan.¹⁰

Security warnings must be rare and actionable. Signal’s "Safety Number Changed" alert is a negative example because it triggers on benign events (reinstalls). Mattermost should utilize the Cross-Signing model specifically to suppress these alerts. If User A verifies their new device, User B should not receive an alert. User B should only be alerted if User A’s Master Key changes (which implies a total identity reset/compromise).

Based on the comparative analysis, we propose a device verification architecture that combines the Cross-Signing trust model of Matrix with the Admin Control capabilities of Wire and the Recovery robustness of Wickr.

The system will rely on a localized Public Key Infrastructure (PKI) where the user is the Certificate Authority for their own devices.

Key Components:

1. User Master Key (UMK): Created at account setup. This key represents the user's identity.

2. Device Keys: Created locally on each device.

3. Cross-Signing Chain: The UMK signs the Device Keys.

4. Admin Key (Escrow): A special key capable of revoking UMKs, managed by the enterprise System Console.

• Context: User has an existing, verified Mobile App. They are logging into the Desktop App for the first time.

• Step 1: Login & Challenge (Desktop)

  • User enters credentials (SSO/MFA).

  • Server authenticates user but detects a new device ID.

  • UI (Desktop): A modal appears:

    • Headline: "Verify this device to access secure history."

    • Body: "For your security, Mattermost needs to verify this device. Please open your Mobile App to confirm."

    • Content: A large QR code (encoded with the device's public key and ephemeral verification parameters).

• Step 2: Notification & Scan (Mobile)

  • Notification: The existing Mobile App receives a high-priority push: "New Login Attempt on. Tap to Verify."

  • UI (Mobile): Tapping the notification opens the Camera Scanner directly.

  • Action: User scans the QR code on the Desktop screen.

• Step 3: The Handshake

  • The Mobile App (trusted) validates the QR payload.

  • The Mobile App signs the Desktop's public key using the User’s Master Key (which it has cached or requests access to).

  • The Mobile App sends the signature to the server.

• Step 4: Success & Sync

  • UI (Desktop): The modal transforms into a green success checkmark. "Device Verified. Syncing History..."

  • Mechanism: The Desktop app receives the signature and the encrypted history backup key (Megolm key) from the Mobile app (via the server, encrypted for the Desktop’s new key).

  • Result: The user sees their chat history.

• Context: User cannot scan (e.g., Desktop to Desktop, or broken camera).

• Step 1: User clicks "I can't scan this code" on the Desktop.

• Step 2: Desktop displays 4 Emojis (e.g., 🦄 🌮 🎈 🎸).

• Step 3: The existing device (e.g., Laptop) displays a prompt: "New Login. Do these emojis match?" followed by the same 4 emojis.

• Step 4: User clicks "Match".

• Reasoning: This leverages the cognitive ease of emoji recognition (Matrix pattern) while providing a robust cryptographic channel verification.¹

• Context: User lost their phone and laptop. They are logging in on a brand new iPad. They have no existing device to verify with.

• Step 1: User clicks "I don't have access to my devices" on the verification modal.

• Step 2: Recovery Key Prompt.

  • UI: "Enter your 12-word Recovery Phrase to restore your identity."

  • Mechanism: This phrase (generated at onboarding) is the salt/key to decrypt the server-side backup of the User Master Key.

• Step 3: Success: Entering the phrase hydrates the new device with the Master Key. The new device signs itself.

• Step 4: Failure (Lost Phrase):

  • Action: User clicks "I lost my recovery phrase."

  • Result: User is blocked from history. They must contact IT.

  • Admin Flow: IT Admin verifies identity (out-of-band). Admin triggers "Identity Reset" in the System Console.

  • Consequence: The user's account is reset. Old history is strictly inaccessible (keys are gone). New keys are generated. The user starts with a blank slate, but retains their username and group memberships. This avoids the "Signal problem" of needing a new account, while maintaining the "Wickr" security of no backdoor.³¹

To differentiate from consumer apps, Mattermost must provide robust tooling for the System Admin.

A new section in the System Console: Security > E2EE Device Management.

• Device Inventory: A table listing every device for every user.

  • Columns: User | Device Name | Device ID | Trust Status | Last Active | IP Address.

• Revocation Controls: An admin can click Revoke on a specific device (e.g., "John's Stolen Laptop").

  • Mechanism: The server publishes a revocation list. Clients refuse to encrypt messages for revoked device keys. The User Master Key is rotated (if possible) or the specific device is blacklisted in the cross-signing chain.

• Policy Enforcement:

  • Strict Mode: "Block unverified devices." (Users cannot read/write until verified).

  • Permissive Mode: "Allow unverified devices." (TOFU model - good for rolling out the feature).

Every verification event must be logged to the audit table for compliance (SOC2/HIPAA).

• VERIFY_SUCCESS: User A verified Device B via Device C (Method: QR).

• VERIFY_FAIL: SAS mismatch detected (Potential MITM).

• DEVICE_ADD: New unverified device added.

• DEVICE_REVOKE: Admin revoked Device X.

Trust Indicators (The Shield Metaphor):

• Green Shield: Verified. (Cross-signed by trusted Master Key).

• Grey Shield: Encrypted but Unverified. (TOFU state - common in "Permissive Mode").

• Red Shield: Untrusted/Changed. (Key mismatch or revoked).

Error Messages (Addressing "Network Error"):

• Instead of generic "Network Error" ¹⁰, use specific diagnostics:

  • "We couldn't reach your other device. Please ensure both devices are connected to the network."

  • "Camera access denied. Please enable camera permissions in System Settings."

1. Phase 1: Key Infrastructure. Implement the Cross-Signing primitive (Master Key, Self-Signing Key) and server-side key storage.

2. Phase 2: The Recovery Key. Build the onboarding flow that forces users to generate and save a 12-word phrase.

3. Phase 3: The Happy Path (QR). Implement the modal blocking logic and QR generation/scanning libraries on Mobile/Desktop.

4. Phase 4: The Admin Console. Build the revocation UI and audit logging backend.

5. Phase 5: Migration. Roll out in "Permissive Mode" (Grey Shield) to allow users to verify devices gradually, then switch to "Strict Mode" (Green Shield enforcement) once adoption reaches a threshold.

By analyzing the friction points of Signal, the scalability of WhatsApp, and the architecture of Matrix, a clear path emerges for Mattermost. The proposed solution does not merely copy a consumer feature but adapts it for the enterprise. The introduction of Cross-Signing solves the verification scalability problem. The QR-first, Emoji-fallback flow addresses the cognitive load and accessibility challenges of verification. Finally, the Recovery Key and Admin Reset workflows bridge the gap between "zero trust" security and the operational reality of business continuity.

This approach implements "positive friction" where it matters most—at the moment of device addition—while ensuring that the subsequent collaboration experience remains seamless and secure. It transforms device verification from a user annoyance into a visible, understandable, and manageable component of the enterprise security posture.