Why Team-Specific Keys Need a Middle Tier

Enterprise customers in finance, healthcare, and other regulated industries are pushing for encryption at rest that uses keys unique to their team—ideally anchored in a hardware security module (HSM). The goal is straightforward: give security teams the ability to disable access to all of their team’s data if needed, with the key material protected by dedicated hardware rather than by software alone.

The obvious way to deliver this is to follow the industry-standard model: a top-level key per team, used to derive or decrypt individual data encryption keys for every file. But that approach collides with one of Dropbox’s core workflows—file sharing and copying.

How Files Are Stored and Copied

When a file is uploaded, Dropbox breaks it into 4 MB chunks called “blocks.” Each block is encrypted and stored separately, sometimes in different physical locations, and each block carries its own data encryption key. When someone adds a shared file or folder to their own Dropbox, the system creates a new, independent copy of that file.

With a two-tier model (team key plus block keys), that copy would have to be encrypted under the recipient team’s key. That means re-encrypting every single block in the file. Given that Dropbox supports files up to 2 TB—potentially more than half a million blocks per file—a single copy operation could trigger hundreds of thousands of tiny re-encryption tasks. Even skipping straight to copying data encryption keys would be prohibitively expensive at scale.

A Three-Tier Key Hierarchy

The solution exploits the fact that Dropbox internally organizes files and folders into namespaces—containers analogous to a root folder. Inserting an intermediate encryption tier at the namespace level yields a three-tier hierarchy:

  • Team encryption key (TEK): A top-level key unique to each team, generated and stored in AWS Key Management Service (AWS KMS) within an HSM.
  • Namespace encryption key (NEK): Generated per namespace using AWS KMS and the team’s TEK, then encrypted with the TEK and stored in persistent storage.
  • Block encryption key (BEK): A unique key per block, stored encrypted at rest with the corresponding NEK.

Reads work down the chain: retrieve the TEK from AWS KMS, decrypt the NEK, use the NEK to decrypt the BEKs, and finally decrypt the data blocks. Writes run the same path in reverse. The extra tier adds just one additional metadata lookup and one extra encryption or decryption step per request.

Fast Copies Through NEK Re-Encryption

The real win shows up in cross-team copies. Instead of re-encrypting every block, Dropbox needs only to re-encrypt the source namespace’s NEK to grant the recipient access. That turns what could be a multi-hundred-thousand-step operation into a single, quick step.

Background processes then gradually re-encrypt every block with the recipient’s keys, eventually returning the system to a clean state where the recipient no longer depends on the original team’s NEK. This deferred re-encryption keeps user-facing operations fast, and it aligns neatly with Dropbox’s existing data locality architecture, allowing reuse of foundational infrastructure.

Operational Safeguards

Caching to Reduce KMS Load

The added tier actually lowers overall load on AWS KMS, since block-level operations no longer need to consult the top-level key every time. To further reduce calls, NEKs are cached in memory for short periods. Because file operations tend to happen in bursts—syncing or uploading many files at once—the cache absorbs most repeated KMS requests.

Rotation Without Long-Term Key Retention

Key rotation remains manageable despite the larger key inventory. TEKs live in AWS KMS and can be rotated with native tooling. Rotating an NEK requires re-encrypting all associated BEKs, but this is handled as an offline process with no user-visible impact. Importantly, old NEK versions are not retained indefinitely—the BEKs are re-encrypted with the new NEK, avoiding the security risk of accumulating stale key versions.

Checksums for Every Key Operation

Memory bit flips are rare but not ignorable at Dropbox’s scale. A single flipped bit during a key write could silently corrupt data or produce a faulty key that later fails to decrypt. Cosmic rays or hardware failures can cause these events, and the sheer volume of operations makes them a real consideration.

To guard against this, every key operation includes a chain-of-custody verification. Keys—whether plaintext or encrypted—are tagged with a cryptographic checksum, and that checksum is verified at each step. For example, when a plaintext NEK encrypts a plaintext BEK, the system generates a checksum of the resulting ciphertext, decrypts it, recomputes the checksum, and compares. The NEK’s own checksum is also recomputed and verified. This ensures corrupted keys or encrypted data never get persisted, even if an operation fails partway through.

Lessons from the Key Management Build

Developing advanced key management forced a re-evaluation of how security and usability interact at scale. The primary takeaway is that simply checking enterprise compliance boxes is insufficient; systems must also stay fast, reliable, and intuitive for both engineers and end users. Much of the effort went into finding that balance, driven by work on a three-tier key hierarchy, key caching, and rotation workflows.

Those same design principles are now guiding encryption work for Dash at Dropbox. Encryption is being integrated into the product from the ground up with focus on team isolation, efficient data access, and customer-managed controls. The intent is for each team's content — embeddings, interactions, and histories — to be protected by its own unique keys, which supports both stronger customer privacy and scalable AI-driven features.

Beyond the Standard Two-Tier Approach

The core innovation of this advanced scheme is inserting an intermediate layer of encryption keys into the conventional two-tier model. In practice, that means versioned node encryption keys bridge the gap between tenant-specific keys and file content. The benefit is notable: you can offer team-specific encryption without sacrificing the fast file sharing and copying operations that users expect. The table below outlines how the three-tier scheme compares to the existing file encryption design.

The goal of this intermediate layer is to make security architecture more responsive to customer demands. Rather than treating encryption as a static barrier, the system is built with operational flexibility:

  • Key caching is run on cloud platforms like KMS and Cloud HSM, reducing latency by relying on cached decryption while local first-hit security requests are batched.
  • Efficient rotation is built directly into the scheme. Converting a key for an updated database row yields a valid NEK with zero decryption operations, enabling fast, non-blocking encryption migrations.
  • Key chain of custody is documented so teams can trace key state for every generation of the derived key structure.

Bringing the Model to Dash

This architecture is now carrying over to Dash encryption. The novel three-tier system addresses one of the sharpest trade-offs in data security: until recently, strong tenant isolation usually required sacrificing file operations relating to copying or sharing between databases. The new structure avoids that concession by handling the re-encryption work efficiently at the key layer.

The result is that the strict security requirements of enterprise customers and the speed expectations of everyday workflows are no longer opposing constraints. Those requirements can be tuned with policies covering key retrieval patterns, version per user, and separate operational principals — for example, different principals for service access versus local key decryption attempts. With some hardening, that model covers the complexity while maintaining speed at interactive timescales.

Ultimately, when it comes to protecting business data, reliability requires foresight across key ownership, emergency recovery, tamper evidence, and rotation schemas. As threats evolve, so must the systems that keep encryption usable at scale.