The Sookasa Blog

The Theocracy of the Cloud: Why Box’s Enterprise Key Management solution falls short

Last week, Box unveiled its long-rumored encryption solution to allow customers to manage their own keys. Some speculated that it might nudge businesses that have been wary of the cloud to finally get on board. But we suspect that security-minded enterprises will conclude that this server-side encryption solution falls woefully short.

Box’s Enterprise Key Management solution has been lauded for how the mechanism could help thwart governments demanding data by putting encryption keys in the hands of the client. Unfortunately, that isn’t accomplished with the proposed architecture.

That’s because this kind of encryption fails on an important measure: The separation of church and state, which we believe is essential to any healthy security approach.

Even if customers are “managing” their own keys, Box’s Enterprise Key Management model requires that clients continue to place all their trust in Box. In normal operation, Box has access to all unencrypted files and their keys, and all uploaded files are still going through Box unencrypted. But customers have no understanding of when normal operations end and when exception procedures should kick in.

Here’s how EKM works, a description furnished by Box to Ars Technica:

  • A file is uploaded to Box, which is encrypted in transit with TLS
  • Box generates a Box Key to encrypt the file
  • Box encrypts the file with the Box Key
  • Box sends the Box Key to the Customer’s HSM on Amazon AWS
  • HSM encrypts the Box Key with the Customer Key and sends it back to Box

Under this system, Box would work as it usually does, simply grabbing the keys each time a file is accessed. But here’s the leap of faith that enterprises that use this solution will need to make—trusting that Box:

  • encrypts but does not store keys;
  • does not access files on its own or on behalf of a government agency without a warning;
  • did not install or allow any government to install “recording” mechanisms.

Sure, this might help limit “blind” subpoenas, in which the government demands access to a customer’s data without that customer being told. With EKM, customers might be told—but they’d still be powerless to do much.

But given the fact that Box is dealing with unencrypted data, despite what newfangled steps it takes to retroactively shield files, it’s not hard for the pessimistic among us to imagine a situation in which a government can take over a Box facility and see everything uploaded in real time. A company could shut off Box, but they’d need to know when and why to do so. In Sookasa’s model, two companies—Sookasa and Dropbox—would need to be subpoenaed, an extra layer that complicates the process.

Another area of concern is the fact that Box’s EKM system is solely focused on the cloud, effectively ignoring the concerns surrounding on-device data. Like its peers, Box uses a share-and-sync model in which files are cached on user devices for immediate access. That means data is left unprotected on devices, a fact that has also posed a huge loophole in Box’s HIPAA compliance, and a problem for secure handling of data in general.

In short, Box’s Enterprise Key Management solution might put encryption keys in the hands of customers—but it doesn’t adequately address their security concerns.