Implementing end-to-end encryption for Dropbox teams

People trust Dropbox to keep their most important content secure. As more teams embrace remote and distributed work, ensuring the privacy and security of their data has never been more important. While customers already appreciate our simple, seamless access controls, those who work with more sensitive information have told us they want even more control over how their data is secured.

One of the ways that Dropbox is meeting the needs of these customers is with the introduction of zero-knowledge, end-to-end encryption for team folders. While Dropbox already encrypts files at rest using 256-bit AES, customers are seeking end-to-end encryption where only they possess the decryption key, so not even Dropbox can access the contents of their files.

For customers with especially sensitive or confidential data—for example, those working in finance or healthcare—end-to-end encryption offers an additional level of security. When enabled, files are encrypted directly on the customer’s device before being uploaded to our servers.

Here we’ll discuss our implementation of end-to-end encryption for teams, the threat model of our design and encryption algorithms, and our commitment to minimizing the risk of data loss with a team-centric key management approach.

Our commitment to simplicity and reliability is at the heart of our encryption design. In our view, a secure system must also be user-friendly. A security system serves no purpose if it’s too complicated to use. For a feature like end-to-end encryption, with its added layer of complexity, striking the right balance between security and usability is key. Our aim was to make this technology accessible without compromising security.

At its core, our implementation of end-to-end encryption is designed so that neither Dropbox, unauthorized users, or malicious third parties can access a team’s encrypted files. Only the team holds the keys. Even if an attacker gains access to those keys, our implementation still ensures the confidentiality of new files or modifications, as long as the team’s keys have been rotated.

Encryption also assures that a file has not been tampered with. In other words, if a file decrypts successfully, it is cryptographically guaranteed to be the exact same content as encrypted in the first place.

At the same time, because zero-knowledge encryption means customers manage their own keys, they also risk losing access to their data if those keys are lost. To address this, we’ve developed a key management system designed specifically for teams. It ensures that even if one member loses their keys, the data remains accessible and secure for the rest of the team.

Key management in many end-to-end encryption systems has traditionally focused on individual users, mainly because they were the first to adopt and use these systems. In those systems, each user is responsible for managing their own set of keys and making sure they're always accessible. However, this can create complications that diminish the user experience and may even lead to data loss if keys are misplaced. To counteract potential data loss, some systems use a method called key escrow, which allows for data recovery by a trusted third party, e.g. a spouse or an administrator. But this adds complexity, both in terms of the coding required and in using the product itself.

By focusing on our teams customers and drawing the cryptographic boundary around teams, we were able to re-think how the key management is done. With our approach, users don’t have any keys, but every team has a central team key. This key is accessible to all team members and controls access to the team’s encrypted data, providing protection against unauthorized third parties.

The team-centric approach offers the following benefits:

• Reduced risk of data loss and implicit key escrow. By sharing the team key among all members, any member with access—such as a team admin with a recovery key or a member with a registered device—can restore access for everyone.
• Reduced user responsibility. The burden of managing cryptographic keys shifts from individuals to the team, reducing the risk of a single person causing data loss.
• Reduced complexity and improved user experience. The absence of user keys as well as an explicit key escrow significantly simplifies the implementation and improves the user experience. Team members can simply use end-to-end encryption without having to worry about keys at all.

To preserve data confidentiality when team members change, admins can rotate keys for the entire team. Rotating keys upon the departure of a member ensures that any potentially leaked keys become obsolete for accessing new or modified encrypted data. This mechanism is critical in a scenario where a former member, now considered an untrusted outsider, attempts to misuse a previously acquired key. By instituting a new team key for encrypting subsequent data, the system effectively safeguards the confidentiality of new files or modifications made after key rotation, thereby aligning with the threat model's emphasis on protecting data integrity against insider threats turned external.

Before a user can use end-to-end encryption on a new device, the required keys must first be made available. We offer admins a choice of two device registration modes: automatic device registration and manual device registration.

Automatic device registration balances security with usability by distributing keys from our system to authorized team members through the Dropbox authentication and access control infrastructure—for example, when logging into a new device. Existing devices automatically authorize new devices by wrapping the team key with the new device's public key. If there are no devices available to do this, a team admin can use a recovery key to facilitate the new device's registration. The device then obtains and uses its version of the team key, ensuring quick and smooth setup without manual input.

If a customer prefers more fine-grained control, they can opt for manual device registration. This process lets team admins personally approve new devices before they can access encrypted files. Team admins and members can check key authenticity by comparing the fingerprints, or security codes, of the device and team keys out-of-band. Only keys verified to belong to the correct devices and team will be used, ensuring that only legitimate team devices can access encrypted files. This process adds an additional safeguard against unauthorized access and man-in-the-middle attacks as admins can ensure that a key really belongs to a person or team, and not a malicious actor.

Despite its security benefits, key verification can be cumbersome and impact usability, often leading to its limited real-world use—so we've made it an optional feature for those who need greater security.

It’s important to point out there are also some threats that fall beyond the scope of our implementation: 

• Device security. Though end-to-end encryption keeps data safe during transmission and while stored on our servers, it doesn't address security at the device level. Since encrypted files decrypt automatically for access during sync or download, we still recommend customers adopt best practices such as full-disk encryption and secure access methods to protect their devices.
• Metadata visibility. Our encryption efforts concentrate on file contents rather than metadata. With this approach, customers can still search their Dropbox account based on metadata such as file name, file type, and creation date, ensuring end-to-end encryption is still practical in everyday use.
• Insider threats. Our implementation safeguards against external threats to a team but doesn't change internal permissions. Teams should continue using existing access controls to manage data access amongst members, ensuring sensitive information remains compartmentalized and secure.

Our implementation uses a hybrid scheme, combining a symmetric algorithm for encrypting file content with an asymmetric algorithm for securing the keys. We aim for a balance of proven security, performance, and broad platform support in our choice of encryption algorithms.

Symmetric file encryption
Plaintext content is split into 4 MB blocks, where each block is authenticated using AES-256 encrypted in Galois/Counter Mode (GCM) with a random and unique 96-bit nonce. While AES-GCM guarantees authenticity and integrity for each block, the 128-bit authentication tags of all blocks are cryptographically hashed using HMAC-SHA-256 to expand these guarantees to the entirety of the file.

This method supports partial encryption and decryption, offering seamless security without compromising the file's integrity or order. This method is especially effective for large files, as it aligns with our practice of chunking file content into 4 MB blocks for storage. It also avoids the limitations of in-memory processing required by some APIs, like WebCrypto.

Asymmetric key wrapping
To encrypt secret keys, our approach to key management uses Hybrid Public Key Encryption (HPKE), a modern and flexible standard that combines asymmetric and symmetric encryption in a hybrid crypto system. We use HPKE in single shot, base mode using Elliptic-Curve Cryptography (ECC) with the P-256 curve, SHA-256, and AES-256-GCM (DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, AES-256-GCM). When manual device registration is chosen, HPKE is used in auth mode to encrypt parts of the key chain with sender authentication required for effective key verification.

NIST P-256 has been chosen over other curves like Curve25519 because it is widely adopted in the industry, is available in most cryptographic libraries (e.g. WebCrypto, CryptoKit, OpenSSL), and is specified in FIPS 186-4.

Post-quantum cryptography
The algorithms mentioned above do not include any post-quantum cryptography (PQC). While there exist some products with early implementations of PQC, we're taking a more cautious approach, relying on proven and time-tested encryption algorithms for several reasons:

• PQC's reliability for long-term storage is still uncertain due to ongoing standardization efforts. For instance, the Kyber algorithm has seen several revisions throughout its NIST standardization process.
• PQC is relatively new in cryptographic terms and lacks the extensive scrutiny that more established algorithms have undergone. To counteract this, some PQC applications use a hybrid model, where traditional cryptography is also used. This ensures baseline security should the PQC component be compromised at the expense of greater complexity.
• PQC algorithms are not yet sufficiently included in common cryptographic libraries, requiring custom implementations across some codebases and increasing the risk of vulnerabilities, bugs, and other human error.
• The threat posed by quantum computing—while significant—is still theoretical, with its practical impacts still unknown.

Given these considerations, we’ve maintained flexibility around our ability to change our encryption protocols, while staying focused on trusted, well-known cryptographic implementations. This will enable us to integrate new encryption algorithms to our protocol at any time in the future. We are closely monitoring the development of Kyber and other PQC algorithms and will adapt our choice of encryption algorithms as they mature and standards evolve further.

With the introduction of end-to-end encryption for teams, Dropbox is proud to offer additional access controls for our most security-conscious customers. By prioritizing usability alongside security, we've ensured that end-to-end encryption not only secures data but also remains accessible and manageable for any user that requires it.

To learn more about end-to-end encryption at Dropbox, read the latest version of our security whitepaper.

~ ~ ~

If building innovative products, experiences, and infrastructure excites you, come build the future with us! Visit dropbox.com/jobs to see our open roles, and follow @LifeInsideDropbox on Instagram and Facebook to see what it's like to create a more enlightened way of working.