Storing Files in the Cloud: Storage-as-a-Service for Lawyers—Encryption

For attorneys, special considerations may be appropriate before implementing a STaaS solution especially if storing client data in the cloud. What might an attorney consider before using a Storage-as-a-Service (STaaS) such as DropBox, SpiderOak, IronMountain, JungleDisk, or MozyPro? Salient factors may include 1) encryption, 2) functionality, and 3) long-term accessibility. This article addresses encryption.

First, STaaS describes remote, storage capacity— a cloud hard drive— generally accessible via an internet connection. The remote drive acts a virtual file store or backup store. Files are uploaded or downloaded from the remote drive. In some cases, the cloud drive also synchronizes a common file set across multiple devices thus allowing access to the same files from a mobile device, home office desktop, or work laptop. A wide-variety of vendors make STaaS available with business or personal emphasis.

Understanding Basic STaaS

In simplest form, the STaaS provider 1) makes available disk space on a remote server 2) accessible via the internet and 3) restricting access with some form of subscriber/user account. The provider locates the remote server in a data center. The complexity and redundancy of the data center varies from provider to provider (and, at least in part, distinguishes the pricing structures).[FN1] The provider allocates disk space from the pool of all disk space to the subscriber. The subscriber accesses the disk space, or virtual cloud drive, via the internet. The subscriber typically enters a user name and password to gain access to the cloud drive.

For general purposes (personal use), basic STaaS is probably adequate. For attorneys, however, a more nuanced analysis may be necessary.

The Encryption Conundrum: Who, What, Where, When?

Note: I preface with a caution. I intentionally simplified this, otherwise very complex, discussion for a general audience.

Encryption obfuscates data—scrambles the data in a methodical way so the data can later be unscrambled. When dealing with the internet, encryption exists in several forms, and distinguishing the forms is essential to understanding STaaS for attorneys.

The attorney should be aware of two applications of encryption: 1) file encryption and 2) transmission encryption.[FN2] Providers, in marketing literature and possibly without knowing of attorney obligations, do not always make this essential distinction clear.

File Encryption

File encryption describes the application of an encryption algorithm to a data file. Essentially, the encryption algorithm scrambles the file contents using an electronic key. The file contents are later unscrambled using the electronic key. When scrambled, the file contents appear as meaningless gibberish. Common file encryption algorithms include AES, Triple-DES, Blowfish, Twofish, RSA, Serpent.[FN3] STaaS provider marketing materials often extol to the apparent “strength” of the key as 128bit or 192bit or 256bit encryption and terms like “military grade” are not really meaningful.[FN4] AES is the current, US government, standard for encryption.

Thus, to reiterate, file encryption generally applies to the file contents. The file itself, such as a word processing document, is scrambled.

Transmission Encryption

Transmission encryption describes securing the internet connection itself and can be visualized as securing the “pipe” or connection between the subscriber’s computer and the remote, cloud server. What is encrypted is the stream of data between Point A (subscriber computer) and Point B (STaaS server). The data is encrypted only while flowing through the connection. Once reaching the destination, the data “loses” its temporarily encrypted state because the transmission is complete at that point—remember, transmission encryption only lasts while data is in transmission.[FN5] SSL (secure socket layer) is the most common transmission encryption (also referred to as https connections).[FN6]

For example, Mariela wants to upload a file using SSL. She selects the file locally and issues the upload command. SSL wraps the file in transmission encryption and sends the file to the remote STaaS server. Once reaching the STaaS server, the SSL connection decrypts the transmission and saves the file on the remote computer. Note that the encryption only lasts as long as the file is in the pipe.

Typical, Hybrid STaaS Implementation Using Both Transmission and File Encryption

Now, let’s put the parts together. STaaS providers typically offer the following:

  • SSL transmission encryption from the subscriber computer to the remote server, and
  • file encryption of some type on the remote server.

I described the SSL transmission encryption above (remember, do not get mislead by STaaS providers who imply that your files are locally encrypted).

File encryption on the remote server is a minimum requirement. In some cases, however, the STaaS provider file encrypts the uploaded files using the STaaS provider’s key and not your key. This is not necessarily bad but does raise two issues for lawyers: 1) who does the file encryption materially protect and 2) access to the lawyer’s data locked by some else’s key.[FN7] The STaaS-Provider-key alleviates one problem of managing the subscriber’s key. In other words, using the STaaS’ key to encrypt avoids the sticky dilemma of somehow securing the subscriber’s key on the remote server because otherwise the subscriber’s key is necessary, using current file encryption schemes, to file encrypt the subscriber’s data (assuming symmetric encryption like AES). Thus, this model is not per se nefarious albeit still a challenge for lawyers. A challenge arises from having the lawyer’s data irretrievably locked by someone else—a question that each lawyer needs to come to grips with. An analogy may be to bank safe deposit boxes (although even there, two keys are used in my experience). JungleDisk addresses this issue, somewhat on the bank safe deposit box model, by allowing the subscriber to use a password that unlocks the key which unlocks the file.

An Alternative Solution: Local Encryption Before Uploading Using the Attorney-Subscriber’s Key

Using local file encryption before uploading via SSL to the remote, cloud server may be one way to potentially minimize the dilemma. In this model, the transaction occurs as:

  • encrypt the file locally by using file encryption and the subscriber’s key;
  • upload via SSL transmission encryption from the subscriber computer to the remote server; and
  • file encryption of some type on the remote server.

The latter step, remote file encryption, may not be necessary because the file is already file encrypted before being sent to the remote server. This model gives control over the key to the subscriber and provides whole-process encryption. In this model, even if the file is intercepted while transmission encrypted (in the SSL pipe), the file is still file encrypted—as opposed to other models that file encrypt only after the file reaches the STaaS server.[FN8] So far, I have found only twothree STaaS providers apparently using this model: MozyPro, CoreVault, and Nasuni.[FN9] Nasuni recently announced a “100% up-time promise” which pays a penalty for any downtime.[FN9a] A newer offering, SpiderOak, also appears to encrypt prior to uploading to the server using AES256.

Much Ado About Nothing? An Example of the Problems of Non-Locally, File Encrypted Services

Is this much-ado-about-nothing? DropBox is a very popular file synchronization tool (STaaS variant) that allows the subscriber to drop files in the DropBox and have those files automatically uploaded to the DropBox remote server.[FN10] However, a recent security post indicates a potential the vulnerability of such tools services without local file encryption. According to the report, files dropped into DropBox might be available to attackers who gain access to the DropBox configuration file. See Dropbox authentication: insecure by design[FN11]. While the flaw here is not technically related to STaaS encryption, the issue illustrates the ease by which data might be compromised—disturbingly, without the knowledge of the owner. While local file encryption might not have fully mitigated the issue, if the files were locally file encrypted, even if the attacker gained access the file contents would be effectively unreadable.[FN12]

Conclusion: Know Your STaaS Provider and Seriously Consider File Encryption

Trusting the STaaS provider is key. Should you use a STaaS, the STaaS provider potentially has access to your client’s data. Thus, prudence and careful evaluation may be warranted. When evaluating STaaS providers, special attention to who holds the keys and knowing what effect, if any, this has on your data may also be helpful. Knowing precisely what is encrypted and when encrypted may also be important factors.

Related Articles

If you liked this article, also see my other articles on related topics. Cloud Computing: Who Holds the Encryption Keys? [And Why It May Matter to Lawyers] specifically looks at the encryption key issues in more detail. Avoiding Being "Bit"ten: Bandwidth Issues With Cloud Computing Backups discusses the lengthy time potentially required to perform a full restore via the internet from a remote, cloud backup. Cloud Nines: Understanding Accessibility Versus Availability in Cloud Computing for Lawyers discusses the confusion regarding cloud provider claims of accessibility and availability—especially important with online backups. Not comfortable with online backups? Then see a review of the open source, backup application called Areca.

Footnotes

FN1—The discussion here is intentionally simplified. Typically, a provider has multiple, regionally distributed data centers. Within each data center might be hundreds or thousands of servers mounted in racks in a secured facility.

FN2—A third form of encryption is container encryption or whole-disk encryption and might also apply in some cases.

FN3—I omit a detailed description of encryption algorithms although the topic is of significant personal interest. The common algorithms include symmetric and asymmetric (the latter sometimes described as public-key encryption because a public-private key pair is used to perform the encryption) algorithms. Note Triple-DES (or 3DES) is distinguished from DES which is no longer considered reasonably secure.

FN4—While discussion of the “strength” of the keys is far beyond this discussion, know that the key length is not the only factor is assessing strength. Pass-phrase complexity (password), iterations, randomness, key security, etc. also influence “strength.”

FN5—Technically, the encryption also exists temporarily outside the transmission as just before entering the pipe and just after leaving the pipe. I mention this because some STaaS providers [confusingly] imply the transmission encryption exists on your computer. But note that this is technically true but probably momentary at best unless plainly paired with true, persistent file encryption.

FN6—SSL is only one form of transmission encryption. VPNs (virtual private networks) also serve similar function.

FN7—I am not implying a nefarious scheme by STaaS providers—although in fairness, one can easily imagine this scenario being used as leverage against the subscriber.

FN8—Questions about the effectiveness of SSL stretch back to at least the mid-1990s (when I started my first web technology development company). Even though SSL is often promoted as “bank grade security,” the reality is that SSL has some serious flaws. See recent articles such as How is SSL Hopelessly Broken? and SSL and the Future of Authenticity.

FN9—As with all my articles, mention of a brand is NOT intended as an endorsement but for reference only. No implication should be drawn that these brands are superior to other brands—they simply illustrate the options available.

FN9a—Chris Mellor, Nasuni puts its cloud storage balls on the line, The Register (Jul 21, 2011) http://www.theregister.co.uk/2011/07/21/nasuni_sla_uptime_guarantee/.

FN10—Again, mention of a brand is for illustration only. No implication should be drawn from the mention here.

FN11—See also A Mobile Security Checklist for Attorneys which indicates (in Item 5) potential flaws.

FN12—Also, however, note a recent (14 March 2011) article related to the transmission encryption layer and DropBox on mobile devices. According to the article, when using DropBox on a mobile device, the file name and other metadata (but not the file data itself) are transmitted outside the HTTPS pipe and thus may be intercepted. DropBox apparently responded by emphasizing that the problem only effects file name information and metadata and not the actual file data. See Dropbox Mobile Apps Are Less Secure than the Desktop Utility [Updated]. For the purposes here, the issue simply emphasizes the distinction between transmission encryption and file encryption. Either can be problematic.

Original Posting: 13 April 2011
Minor Update: 15 April 2011
Update: 06 May 2011
Update: 06 July 2011