[#1]

Sorry, I couldn't find this information anywhere in the forums, documentation, etc, and it's strange it's not more prominent:

1) If I choose to use Mozy's default Blowfish encryption, is the default encryption key the same for every Mozy user?  If so, it might as well not be encrypted; all it would take is one leaky support person or engineer to compromise the data of every Mozy user using default encryption.  If not, how are the default encryption keys secured?

2) If I use my own encryption key for AES encryption, what's the required format?  64 hex characters?  Alpha-numeric?  Is the key hashed with other info when actually used for encryption?

3) The decryption utility looks extremely clunky.  Why is seamless decryption not built into the main client?  Why not ask for the key during restoration, decrypt them, and put them in the correct folder without having an external app and unwieldy directory structures.  In other words, why is private key decryption handled differently than the default key decryption? 

[#2]

There's something I don't understand - I've heard of that decryption utility before , but I've never had use for it myself. Files are already decrypted when I download them. And I'm using my own key?

[#3]

Does nobody know the answers to these questions?  They seem pretty simple to me.

[#4 · Accepted solution]

MattW, sensei--

Answers to your questions are below. Before I answer them, I'll discuss a bit of background on Mozy's security philosophy. Backup products, like any other software products, must maintain a balance between security and usability. Particularly with Mozy, where our user base runs the gamut from highly-trained systems administrators in organizations of over 10,000 personnel to home users with little to no technical knowledge, the ability to ensure that the solution can adapt to our users' needs is paramount.

Thus, users have the option (depending on geography and account type) of using a Mozy-specified key, a customer-defined encryption key, a two-part key (wherein the actually encryption key is encrypted by another key, requiring the presence of both keys to decrypt data), or a managed key provided by some OEM's / resellers. Each one of these options offers certain advantages and disadvantages. Two-part keys are popular with our large clients, as it ensures no single IT person can decrypt any user's data; by the same token, though, if one of the keys is lost, data will be unrecoverable in the future. Customer-defined keys are relatively popular, but have their own set of problems as well-- some people may put in a highly complicated password for their key, which they cannot remember 18 months down the round when a restore becomes necessary. In some cases, users have saved their keys to jump drives and the like-- which are then destroyed or taken in the same robbery, flood, or fire, that caused the loss of the data those keys were protecting.

So, my point is-- security and usability are at the discretion of our users. If you elect to use a custom encryption key, we don't store it-- which means its loss may be potentially crippling. Hence the Mozy default keys.

Now, on to the questions.

1) Mozy does not maintain just a single key. I'm not at liberty to disclose the number, but it is more than one. Key access is granted on an extremely limited basis, and the actions of any personnel who have such keys is monitored, audited, logged, and reviewed. All Mozy full-time personnel must pass a background check, drug check, and other screenings prior to being brought on.

2) If you use your own AES key, you'll need to create it in the client. The reason for this is that the client encrypts the key prior to storing it for future use on your data. This is a security measure; you're not required to maintain a copy of your key in cleartext for Mozy to use, and if someone were to gain access to your system, they'd not be able to find the key.

3) Decryption is built into the main client (if you do an in-client restore, this is what you'd use). The decrypt utility exists for instances wherein you wish data to be recovered but don't want to install the client. As for the second part of your question, it boils down to finding an adequate compromise solution. Restores are broken into 4GB archive bundles so that the download process is manageable (if we were to return all of a customer's 500GB restore in a single file, it's unlikely that the download would ever complete, or that the user would have room on his hard drive for both the original encrypted file and the decrypted output). The main client can handle all of this seamlessly, but it won't work for users who are unable to let the entirety of the restore run without disconnecting the computer from the Internet.

As far as Sensei's question goes-- if a user does a web restore and was using Mozy default encryption, then the restore is encrypted in-transit via SSL but is not encrypted once downloaded. Some users use the web restore frequently on multiple machines and having to maintain access to a key would be cumbersome. If you use custom encryption, you'll need to either restore in-client or use the decrypt utility and have access to your key.

For users who are executing restores in-client, the client manages all decryption.

We are making significant changes and updates to our restore logic to provide for an enhanced user experience, though I cannot state when users will begin to see these changes in production.

[#5]

Thanks much for your detailed response.  It just strikes me that the surest way to security is to have as many details of the securing process as possible -- the clipperz.com philosophy.  I found a white paper (mozy.com/reseller/mozypro_security_wp_decho.pdf) that discusses some of the aspects of your security process in more detail, but nothing like what you've provided.  I understand the need for a balance between security and usability, and in some ways it seems you are having it both ways, providing extra security for users that want it, and maximum ease-of-use for users that are ok with a little less security.  Some feedback though, from a user that wants the extra security:

1) It would be nice to specify the format in the client for the user-supplied encryption key, and to require double entry, just like a password.  I can see from the white paper that an alpha-numeric key of unspecified length can be used because the client hashes the provided key with other data to get the 256-bit key that's actually used (similar to many WEP implementations.)  But this isn't spelled out in the client during the key entry process, nor in the help.

2) Tell us how the encryption/decryption process works in the help.  Specifically, how our key is stored and secured (which you've provided nice details on), what goes on with authentication/encryption/decryption (nicely described by the white paper), etc.

3) Please show that a private key is being used as a status in the client somewhere.  There's no way (that I can see) to verify that my files are being encrypted with my key.

Thanks again for the response, and for clearing up my misunderstanding of the decryption process (i.e. decryption is seamless with the client and the utility is only necessary when not using the client.)

[#6]

Hi SakPase, I have a question about using the private key:

I was given the option to type in my passphrase, which I did.  I was also given the option to save my private key file somewhere, which I did not do.

If i want to later restore my files to a different computer, will knowing my passphrase be enough, or do I need to generate the physical key file beforehand and use it at the time of restore?

Thanks!

[#7]

pchoi94--

Yes, knowing your passphrase will be adequate.

However, we *always* recommend customers back up their key. It goes back to my discussion of security vs. usability above. A password easy enough to remember after potentially a year or two is probably weak enough to be cracked by a straightforward dictionary attack (unlikely, but it's there). On the other hand, a password of adequate complexity to provide meaningfully strong encryption is probably not going to be easily remembered after a year or two, and thus merits being backed up in a secure place.

Having said that, I've been privy to a number of sad stories surrounding the private keys. In one case, a user wrote down his Mozy encryption key passphrase and put the paper in a hidden location. Unfortunately, he couldn't remember the location 16 months later when it came time to decrypt his data. Another did back up the actual key on a jump drive-- which then got stolen in the same robbery when his computer was stolen. Another backed his key up to a ZIP disk, but then had a hard time finding another functioning ZIP drive when his computer died. And so on...

In any case, knowing your passphrase is adequate.

[#8]

Thanks for the reply SakPase!