5

By personal, I mean for one person that's not sharing the workflow of data access with any other users.

Appears based on the feedback I got on "is-hardware-based-disk-encryption-more-secure-that-software-based" that it might be more secure, but due to a lack of disclosure on the hardware implementation makers part, it's impossible to know, and as a result, appears to be meaningless.

As a result, I want to know the best practices for implementing and managing a personal data encryption workflow, and a briefing on the core concepts that are related to the workflow. This workflow assumes local access only, there is no need to make it more complex, and less secure by allowing or accounting for remote access unless it's as a counter-measure to prevent remote access.

Workflow should include backups of data at offsite, where the offsite store is assumed to be hostile and insecure.

The best answer will suggest a real implementation, not just a theoretical workflow, which is to stay it will present a implementation that is executable.

While I believe it would make the answer more useful if the answer worked on Windows, Mac, Linux, etc -- since this would cover the needs of most users, I'm open to a solution on any platform.

Community
  • 1
blunders
  • 5,072
  • 4
  • 28
  • 45
  • 1
    Does this hae to be automatic backup? – nlovric Feb 15 '12 at 17:53
  • @nlovric: No, the backups don't have to be automatic, though when running the backup manually, I'd like to not to do a volume backup, but a have a mechanism that allows a versioning tree of changes of a diff, only backing up the diff, and never overwriting odder files or deleted files; meaning it truly is a backup. If the backup is just a disk image, that'll get pretty massive and unless quickly. Reason I bring this up is that clearly you don't want store the keys to access the backup within the backup system, meaning they'd manually need to be entered I believe. – blunders Feb 15 '12 at 18:28
  • 2
    Well, I can script it (each differing file will be encrypted separately, with the filename renamed to a number, which will replace the original file; deleted files will be deleted; the encryption will be able to work fully automatically using asymmetric key Elliptic Curve Cryptograpy, using the P-571 curve - this will be equivalent to a ~6852-bit RSA or DSA asymmetric key) in BASH if you want; it will take me a few days. – nlovric Feb 15 '12 at 19:09
  • 1
    Alternatively, I might make a backup daemon in C - it will really call other commands, but cycling through files and checking for changes will be done much faster. – nlovric Feb 15 '12 at 19:11
  • 1
    Ahh... I can also make exactly what you wrote, but this is much more complex; do you intend to make restores manually? I can also make that automatic. – nlovric Feb 15 '12 at 19:17
  • @nlovric: Yes, I'd thought about a per-file setup too, but based on the feedback I got on this question, [Would a per-file encryption system any more or less secure than volume encryption?](http://security.stackexchange.com/questions/11662/would-a-per-file-encryption-system-any-more-or-less-secure-than-volume-encryptio) -- seems like there would be issues, and it would be less secure. – blunders Feb 15 '12 at 19:30
  • +5 @nlovric: And I like your style, the request for reps-via-bounties is an interesting idea; also not a big deal to me, though honestly I'm guessing a custom solution would be less secure, and I could just post a 100-bounty to this question and get a "good" answer... :-) – blunders Feb 15 '12 at 19:30
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/2513/discussion-between-blunders-and-nlovric)... just kidding, but SE really doesn't like lots of comments, and they requested I post the link to chat. – blunders Feb 15 '12 at 19:34
  • 1
    Yes, they could see changes to your files; however, I can make that vanish, too, by doing a backup on a image and then replicating the differing blocks. :p Replicating the differing blocks is, actually, pretty easy. – nlovric Feb 15 '12 at 19:38
  • @nlovric: Yes, I know... though still, I'm a huge fan of "keep it simple". So, I'll give you 50-rep just for being creative and funny, not asking for anything in return. Cheers! – blunders Feb 15 '12 at 19:41
  • But I did ask for something in return. – nlovric Feb 15 '12 at 19:55
  • @nlovric: Yes, I know, and it's not a deal I'm interested in... :-) – blunders Feb 15 '12 at 20:57
  • @nlovric - bartering rep like that isn't in the spirit of the site. – Rory Alsop Feb 17 '12 at 21:37

4 Answers4

4

There have been a lot of recommendations here for encrypting specific files but nothing really about full disk encryption. If you do not use full disk encryption, your data is vulnerable if the attacker has access to your machine. Most programs you would use to interact with the data (including the OS) will create temporary files, etc that will leave bits and pieces of your data in unencrypted areas of the hard drive where it can be recovered by an attacker. If you at all think that an attacker might have physical access to your machine, you must use full disk encryption. The easiest way to do this is to use TrueCrypt on Windows. Ubuntu Linux will let you do full disk encryption if you use the alternate installer. This tutorial isn't for the latest version of Ubuntu, but it is more than enough to get you started.

Backing up to a remote location makes things tricky. You absolutely must encrypt all data before it ever touches the network or a third party service. Sites like Carbonite, Backblaze, Dropbox, etc. offer encryption but still maintain a copy of your keys so that you can restore your data from a web interface and cannot be trusted to fully secure your data. I would recommend storing all of your data in a encrypted volume (again Truecrypt is a good option for doing this) and then backing up the entire volume at once.

To summarize, the workflow would look like this:

  1. Fully encrypt your computer using Truecrypt(Windows) or LVM(Linux)
  2. On your now fully encrypted computer, create a local encrypted volume using Truecrypt to store data that needs to be backed up .
  3. Do Work
  4. Unmount/Close the encrypted volume so that keys are no longer in memory, and then push the fully encrypted local volume to a remote site.
  5. Shut off your machine when you are done. Do not use suspend as it will leave encryption keys resident in memory.

If you are exceptionally paranoid, the computer you do work on shouldn't have access to the internet. To back up the data you would want to burn the encrypted local volume to a CD, move it to another secured computer with internet access, and then back it up from there.

Also, all of the steps above assume that you use good, strong passwords/passphrases for all encryption. They should all be different and all contain letters (capital and lowercase), numbers, and symbols to make them difficult to guess.

TwentyMiles
  • 869
  • 5
  • 8
3

Truecrypt is one option you can explore. Truecrypt clients are available for Linux/Windows/Mac.

Personally, I have a TC container that maps as a drive onto my windows machine. For backup, I back it up on a remote linux machine (via rsync) and it works pretty good for my personal needs.

So far as you have a pretty good (long) pass-phrase, it will be pretty hard to brute force it.

CodeExpress
  • 2,447
  • 14
  • 10
  • +1 @Shivam: Only used rsync a few times, I know, hard to believe. So in the context of backups with Truecrypt, are you doing a backup of the whole volume each time you backup, or some how entering the phase phrase so that a non-volume backup that reads the current backup, does a diff, and then encrypts the new files sent to the backup? Possible the question doesn't make sense, if not, let me know. Thanks! – blunders Feb 15 '12 at 18:31
  • 1
    @blunders I am doing a full backup of the encrypted container. rsync normally sends only the diffs of a changed file. For Truecrypt containers, its a bit different though... mostly because the size of the container doesn't change when you add more files to it. To overcome that, people use -c flag to make it compare the checksum before copying over. In my case, my file is about 40 MB and so I didn't actually ever cared to see if rsync is copying over the entire stuff of only the delta. – CodeExpress Feb 15 '12 at 20:23
  • 1
    @blunders Ok, so I went back and checked. Every time you change a file in the truecrypt container, its entire entropy changes in a way such that binary diffs aren't possible anymore and actually thats the way it should be for any strong encryption. Therefore rsync ends up copying the entire file (you still have to use -c flag else it won't even copy the file). This is more of a fundamental problem. Binary diffing of encrypted data isn't any good. If its good, then the encryption is bad ! – CodeExpress Feb 15 '12 at 20:58
  • +2 Shivam: Right, not suggesting to do a diff of the encrypted data, but the decrypted data. Seems like after the Truecrypt mounts the volume, it's complete decrypted, and I'd be able to run any application level versioning I wanted; though I would not be able to do a sync/diff to other Truecrypt volume unless it was mounted as well. Is that correct? – blunders Feb 15 '12 at 21:16
  • 1
    Correct. And yes, once truecrypt is mounted its decrypted and like any other fileshare. How much data are we talking about here ? – CodeExpress Feb 15 '12 at 21:36
  • +1 @Shivam: Thanks for confirming that. Honestly, hadn't thought about breaking up the files into access levels, but given that it is done on a volume basis, appears I'll need to do that; originally I had planned to just encrypted everything, in part because I figure the volume of files would make it more secure, but encrypting/decrypting a massive amounts of data sounds like a bad idea, and more likely to suffer some corruption just due to run-time issues, right? – blunders Feb 15 '12 at 22:45
  • 1
    Well once the drive is mounted, encryption/decryption is opaque to you. So I don't see any issue in encrypting/decrypting large amount of data. However as I noted earlier, you can always have containers (which can also be transferred quickly if needed) living amongst your regular files. Having said that, you know your situation best. If there are a set of files (tax docs, personal docs) you'd like to encrypt, container is the way to go. I have it that way and then it becomes one stop shop for all my 'secret' documents :) – CodeExpress Feb 16 '12 at 04:29
  • Note that there are some minor security issues with backing up the whole container(as opposed to its contents). Compare http://security.stackexchange.com/questions/10987/are-backups-of-truecrypt-volumes-with-different-pass-phrases-a-security-risk/11661#11661 | When you change something in a truecrypt encrypted container, only the blocks that were actually changed, change in the encrypted file. So transferring the whole container is not necessary. – CodesInChaos Feb 17 '12 at 17:16
3

For your on-site work physical security should be your first line of defense. If people can't physically get to your computer, they can't hack it. If on the other hand someone could physically steal your computer then they could take as long as they like trying to hack it.

As for what you send off-site, never send all the data to one place. One way to do this would have your backup device be a RAID 2 implementation with seven(7) disks. Since the only way to get the data from a RAID 2 array of this type would be to have physical possession of six (6) of the disks at a minimum, make sure that no single site or person ever has access to more than one of the seven backup disks.

Once you have this physical security in place then go ahead with whatever type of encryption makes you most comfortable.

EDIT: If you install and enable a network card in this computer you have materially increased the potential venerability of your data. The reasons for this are many but at a minimum include:

1) The network card driver when sending and receiving packets will need to read and write data in memory.

2) Irrespective of the fact that data is encrypted on the disk, it must be unencrypted in memory to be processed or displayed.

If, while your sensitive data exists unencrypted in memory, networks packets are simultaneously being sent and received from memory; how can you guarantee that the memory is kept completely isolated from each other? In other words things like buffer overruns for example never occur?

Here is a document which recommends:

Where possible, avoid storing sensitive customer data on a computer with an Internet connection.

For a technical discussion of the risks associated with a network connection see this SANS Institute report.

JonnyBoats
  • 1,143
  • 7
  • 8
  • +1 @JonnyBoats: Interesting, good point. So, to be extra-secure, I'd have to mount the secure volume by booting from a some read-only media source, and make sure the boot disabled remote access, right, or no? – blunders Feb 15 '12 at 21:13
  • 1
    blunders: Your question states"This workflow assumes local access only" so what is your comment about "disabled remote access" ? – JonnyBoats Feb 15 '12 at 21:32
  • +1 @JonnyBoats: I see, by "assumes local access only" I didn't mean that networking was disabled, but that I did not need to access the files remotely. In hindsight I see how that might have been read For example, when booting backtrack boot disable networking was disabled, which not seems like a good idea, right? (Only time I've ever done that was with by booting backtrack-linux from disk, which was easy enough. So, far while no one has posted a suggested complete workflow, this has been a huge help, thanks!) – blunders Feb 15 '12 at 22:51
3

If you're an Ubuntu user, you can trivially chose to Encrypt your Home Directory during installation, and this will ensure that any and all data you store in your $HOME directory is always encrypted using eCryptfs before being written to disk.

As for backing your data up, if you want backups of the cleartext files, you simply need to backup $HOME while you're logged into the system. On the other hand, if you want backups of the encrypted data, you need to backup $HOME/.Private.

It's also critically important that you also store a copy of the key, which you can retrieve by running ecryptfs-unwrap-passphrase.

Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
Dustin Kirkland
  • 233
  • 1
  • 5