Viewable by the world

Document Purpose

One compelling feature of the Carbonite backups are that they are encrypted as they leave the client workstation. This ensures that access to the Carbonite cloud or storage data is not sufficient to read backed up data. Even with physical access to the underlying Carbonite storage system, the encryption keys and password are required to read back the data. This raises the questions of how keys are managed and what happens in the event of a lost password and/or lost keys? Additionally, what are the provisions for eDiscovery access either at the institutional level or by Carbonite?

Keys vs Passwords: How it works

The key used to the encrypted the backup data is named Carbonite-Encryption-Key.pem by default. Normally, this is managed by Carbonite, and this is their recommended configuration. Carbonite then keeps a copy of the encryption key on their servers as well, and this allows Carbonite users to utilize the "Remote File Access" feature. This feature allows users to access some of their files from any web browser without needing to install Carbonite.

The alternative is for users to manage their own encryption key. This option is only available for PC users. In this case, Carbonite does not have a copy they can access, so the "Remote File Access" feature is not available. Users can choose to later upload their key, at which time Carbonite manages the key from then on and in the default configuration.

Data Recovery in the Event of Password Loss

Carbonite can reset your password via a web request (if you supply last 4 digits of the credit card used to purchase Carbonite, the name of the computer, and the billing address). It's not clear how this would work in a volume licensed environment that LBL would use. On the technical side, I'm guessing that the encryption key is not password encrypted with the password. Thus, password changes do not affect the encrypted data store.

eDiscovery

Carbonite seems to support having the ability to decrypt your encryption key, having the ability to perform eDiscovery in legal cases, as per their privacy policy :

Carbonite will not decrypt your files unless i) it reasonably believes that it must do so to troubleshoot problems with the Carbonite Products or Services or ii) it reasonably believes it must do so in order to comply with a law, subpoena, warrant, order, or a certification requirement, such as the requirements of 18 U.S.C. § 2703.

Outstanding Correspondance

Date: Wed, 10 Feb 2010 16:48:37 -0800
Subject: Carbonite Key Management and eDiscovery
From: James Welcher <[email protected]>
To: [email protected]

Carbonite Support,

I have a question about the ability to perform institutional eDiscovery on our customers using Carbonite onsite. I see from your Privacy Policy (http://www.carbonite.com/privacy) that you have the ability to decrypt data if required by law or for trouble-shooting:

Carbonite will not decrypt your files unless i) it reasonably believes that it must do so to troubleshoot problems with the Carbonite Products or Services or ii) it reasonably believes it must do so in order to comply with a law, subpoena, warrant, order, or a certification requirement, such as the requirements of 18 U.S.C. § 2703.

Question 1:
Does this mean that the encryption key (Carbonite-Encryption-Key.pem) is itself not encrypted? I guess I assumed that the user's password was used to encrypt the encryption key. If the encryption key *IS* encrypted, does this mean that you are encrypting the backup data with multiple keys (along the lines of a PGP message encrypted for multiple recipients?) so that you can later decrypt it when needed?

Question 2:
However you have access, clearly, Carbonite does have the ability to decrypt users data when required by law. As an Institution purchasing a set of licenses for it's employees, do we have the ability to decrypt customer data, again, when required by law or company policy? i.e. how can we perform our own eDiscovery?

Question 3:
Assuming that I have a PC platform and I am doing my OWN key management... this means that you can no longer perform a password reset, correct?

Thank you for your time.
--
James Welcher <[email protected]> 1.510.486.5543
Cyber Security, IT Division
Lawrence Berkeley National Laboratory - http://www.lbl.gov

Restores, et. al.

  1. EXTERNAL DRIVES: not included, neither are other partitions of same disk
  2. Mac: Multi-user computer: non-admin user not able to restore even their own files (Bad)
  3. Mac: Multi-user computer: users are unable to browse other users files through "Restore" interface (Good!)
  4. Mac: Multi-user computer: admin users are unable to restore non-admin users files (Bad? To do a restore, you'll need the user to log in first, then an admin to "authorize" the restore.)
  5. Mac: File-Vault complications (how exactly does this software work with File Vault? Was able to restore an individual file, not from a /band/. What does Remote File Access show? When I dragged a file to the trash, it was "grayed out" from restore selection and I couldn't select it for restore)

References

  • No labels