Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Encrypt Mail, Address Book, and iCal data System
Like many of you, I keep lots of personal information on my laptop that I would like to keep private in case I lose physical control of the computer (theft, or more likely these days, sudden seizure by the government).

There are a few ways to accomplish on-the-fly encryption with OS X, of course, but none of them really fit my needs. FileVault has not been known to be exceptionally reliable (although I've never tried it in Leopard) and is totally unconfigurable. Whole disk encryption is a little overkill for me, so I don't feel like eating the CPU overhead that it entails. On the other end of the spectrum, casual security like an Open Firmware / EFI password, and a strong login password are easily defeated, and only deter those with no interest in your data anyway.

What I really want is a way to encrypt just a certain set of private data (like my email in Mail.app, contacts in Address Book, and calendars in iCal), with as little inconvenience as possible. The best solution? How about an encrypted sparse disk image that mounts and unmounts on login/logout? With symbolic links in the proper places, Mail, Address Book, and iCal are none the wiser, and you can be reasonably assured that your private data will stay secure.

Note: This process is a little involved. Compromises can be made, however, and the general method is valuable, so read on!

STEP ONE: Create an encrypted sparse(bundle|image)

You're going to want a good amount of growing room for your data, so think about a maximum size for the disk image. Keep in mind that sparse images and sparse bundles (Leopard-only) only take up as much space as the data that they contain, so you can think big here. Let's go with 80GB.

You're also going to want a good password to secure the image. This password should not be trivial, or this whole exercise will be useless. See Notes on Security, below, for some clever suggestions. The image can be created on the command line; the following command is for creating an 80GB encrypted sparse bundle with the name PRIVATE:
hdiutil create ~/Desktop/PRIVATE -volname PRIVATE -size 80G -type SPARSEBUNDLE -fs HFS+J -encryption
The command line options are pretty straightforward: -fs HFS+J sets the filesystem to HFS plus Journaling, the standard OS X filesystem, and -type SPARSEBUNDLE can be changed to -type SPARSE if a sparse image is desired instead of a sparse bundle. Just change PRIVATE to whatever you want to call your image. You will be prompted for a password, and the image will be created on your Desktop. Of course, you can create the image with Disk Utility. Just remember to set encryption and the type to "sparse image" or "sparse bundle."

STEP TWO: Set custom mount points (optional)

Since we are going to be replacing our sensitive data directories with links to the new location of our files in the next step, it's a good idea to make sure that our new disk image "mounts" at a path that is both secure and invariable.

Normally, all external disks, images, and servers mount at /Volumes/, which is a "sticky" directory. This means that if you mount a volume called PRIVATE, it becomes available to you at /Volumes/PRIVATE and is inaccessible to other users. Nothing stops a malicious user, however, from mounting their own dirty volume, also called PRIVATE. In this case, your volume becomes mounted at /Volumes/PRIVATE 1, but your symbolic links do not change, and so your programs try to access data from the dirty volume, which our malicious user has graciously allowed you to access. We obviously want none of this.

This tremendous and underrated hint on setting custom mount points is the answer to this problem. You're going to have to use vi, so that's why this step is optional. Set the mount point, create the directory if it doesn't exist, unmount the image, and finally remount the image so that it is mounted at the desired directory. For this example, let's say that the image is now mounted at ~/Documents/PRIVATE.

STEP THREE: Migrate Data to Disk Image and create links

Now that you've set a mount point for your image (hopefully) we need to move the data that we're trying to secure to the encrypted image. In this example, we're concerned with data stored by Mail, Address Book, and iCal. Before you start, make sure these applications are not open!

Let's migrate Mail's data first: Mail.app stores it's data at ~/Library/Mail and ~/Library/Mail Downloads. Copy these two directories and their contents to your new disk image at its custom mount point: (the following assumes your mount point is at ~/Documents/PRIVATE; if you didn't complete step two, then your mount point for a volume called PRIVATE is /Volumes/PRIVATE).
$ cp -Rv ~/Library/Mail ~/Documents/PRIVATE/
$ cp -Rv ~/Library/Mail\ Downloads ~/Documents/PRIVATE/
Then delete your old copies:
$ rm -Rv ~/Library/Mail
$ rm -Rv ~/Library/Mail\ Downloads
Finally, link the old directories to their new locations:
$ ln -sv ~/Documents/PRIVATE/Mail ~/Library/
$ ln -sv ~/Documents/PRIVATE/Mail\ Downloads ~/Library/
You can launch Mail.app at this point to confirm that everything is gravy. Repeat these steps for Address Book and iCal:
$ cp -Rv ~/Library/Application\ Support/AddressBook ~/Documents/PRIVATE/
$ cp -Rv ~/Library/Calendars ~/Documents/PRIVATE/
  
$ rm -Rv ~/Library/Application\ Support/AddressBook
$ rm -Rv ~/Library/Calendars
  
$ ln -sv ~/Documents/PRIVATE/AddressBook ~/Library/Application\ Support/
$ ln -sv ~/Documents/PRIVATE/Calendars ~/Library/
Again, reassure yourself by launching Address Book and iCal. Note that this method can be used to secure any directory that you'd like, like your Documents folder, for instance.

STEP FOUR: Add encrypted image to Login Items, turn off automatic login

Now, we want to open our disk image upon login so we don't have to do it manually. This can be done quite simply by adding the file to the Login Items tab of the Accounts System Preferences pane. Log out and log back in to confirm that everything's working okay.

Finally, we need to secure the computer a bit so that this whole process isn't rendered a virtual Maginot Line. Go to the Security System Preferences panel, and check Require password to wake this computer from sleep or screen saver and Disable automatic login.

NOTES ON SECURITY

We can make this method even more secure with long passwords and clever control of the keychain.

If we allow the keychain to store the password to our encrypted disk image, we can make the disk image password as long as we like. One clever way of creating a long, but reconstructable password is by hashing a favorite poem or quote (or anything really, even an image) and combining it with a favorite password. For instance, if our favorite quote is "Et tu, Brute?" and our favorite password is "venivedivici", then our long password would be:
$ echo "Et tu, Brute?" | md5 # => 718a9508a9ce9695778eaedb9df851bc
$ echo 'venivedivici718a9508a9ce9695778eaedb9df851bc is our new password!'
Nice and long, and we can reconstruct it if necessary.

Of course, if that password is in the keychain, then our keychain password should be relatively secure. Just changing the login keychain's password is probably sufficient, but if you'd like more security, then:
  1. Create a new keychain with a password different from your login password, and set that as the default. OS X understands that this is not the login keychain, and will never attempt to "repair" the keychain by synchronizing its password with your acount password.
  2. Store this keychain on a USB key, and set it to mount at ~/Library/Keychains, as described above in step two.
[robg adds: I haven't tested this one...]
    •    
  • Currently 2.64 / 5
  You rated: 5 / 5 (11 votes cast)
 
[36,545 views]  

Encrypt Mail, Address Book, and iCal data | 19 comments | Create New Account
Click here to return to the 'Encrypt Mail, Address Book, and iCal data' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Encrypt Mail, Address Book, and iCal data
Authored by: AudioBear on Sep 22, '08 08:03:43AM

This looks like a good idea, but could you also not just use an enyrpted MacFuse volume to store the data? I think these volumes expand on demand and I thought sparse images were fixed in size? I could be wrong though?



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: glgray on Sep 22, '08 08:11:26AM

Thank you for the very interesting tip. One question though...

Don't Time Machine backups (or any other incremental backup method) become rather onerous if you do this? For example, my Mail folder is 3+GB -- won't that entire 3GB need to be backed up every time I send or received an email message?

I suppose I could exclude that disk image, but then I am defeating the purpose of automatic backups. Am I missing something here?



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: Toadling on Sep 22, '08 09:42:02AM

Not if you use the Sparse Bundle format, which stores the disk image as a collection of 8 MB "bands" inside a single bundle. That way Time Machine only has to copy the bands that have changed.

Of course, a change on a single byte will still force an 8 MB backup, but that's a lot better than your entire 3 GB disk image!

-Dennis



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: glgray on Sep 22, '08 12:55:34PM

Excellent! I did not know that sparse bundles were stored that way. We just did this on a friend's machine and it worked like a charm -- I will be doing it tonight.

Thank you!



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: unforeseen:X11 on Sep 22, '08 09:57:10AM

I've used FileVault since it's become available, and it's absolutely transparent, now as of 10.5.5 also for Leopard. Only thing is it only creates TimeMachine-Backups on logout and you can't browse individual folders, you have mount the homefolder of the desired date and navigate to the file you need.
But besides this, everything perfect, no noticeable slowdown, either.

---
this is not the sig you`re looking for.



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: tc_nyc on Sep 24, '08 05:11:43AM

I came here to say the same thing. While this hint is interesting and I'm sure helpful to some, in my experience FileVault gets a bad rap from people too scared to try it.

I have used it since 10.4 on two Macs in daily use, and while FV implementation was prone to some bugs in 10.4 it's been rock solid in 10.5. No data corruption or weirdness.

The other, often cited, potential problem with FV is slowdowns. I work on Macs all day and most do not use FV, and in comparison I can see absolutely no speed issues with running FV on your home folder.

The Time Machine backup limitation is a hassle, but I don't understand why people would jump through so many hoops to rig up a homemade encryption solution when FV is a button-push away.



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: Dr. T on Sep 22, '08 10:22:51AM

This seemed logical until the discussion of passwords. It makes no sense to assign a long password to the encrypted sparseimage and then put it into Keychain Access that is protected by a weak password. Your keychain password must be strong. Otherwise, the malefactor who takes your laptop will crack the keychain password and gain immediate access to the encrypted sparseimage.

A second point is that you need to securely erase the files that were moved to the sparseimage. Some of that sensitive data may still be readable weeks after completing this process.

A third point is the issue of securing your Address Book. This makes little sense to me. Most names and addresses are in the public domain, so I don't see how it helps to hide them (unless you're rich and don't want criminals to know about your nephews and nieces). You probably wrote letters to many of the people in your Address Book, and their names and addresses will be in your correspondence files. So, if you don't put those files into the secure sparseimage, then the names and addresses be available to whoever snatches your laptop.

My fourth point is don't bother securing your laptop's Address Book and iCal data if you synced them with your totally unsecured iPod or iPhone. It would be rather frustrating to spend hours securing your laptop and then lose the same data when your iPhone is stolen.



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: osxpounder on Sep 22, '08 11:17:56AM

Those are good points. Thanks for taking the time to point these out for us.

I thought about securing my iCal data and my TextExpander data, but since it's being transmitted over various networks, unencrypted, I wondered if it was worth my time. I think not. Better for me to assume that the calendar can be read by strangers, and so never put something too private in it. So, if I have a an appointment to see Dr. Muckenfuss, I just type "Dr. M", for example.



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: UberFu on Sep 24, '08 09:18:45AM

In response to your third point: Not necessarily! Although Names and phone numbers and addresses are in the "public domain" - make an attempt to track down the cell phone number of someone you know using public domain records_ Not gonna happen_ Most people I know myself use a cell phone as their primary phone line_ There is no public domain for cell phone listings_ There are a few upstart websites trying to catalog cell phone numbers with subscribers - but people can roll thru phone numbers like a cop eating doughnuts_

Myself and a couple of people I know have had the same cell phone numbers for years now - but most everyone I know has rolled thru about 4 or 5 cell phone numbers in the past 8-10 years_ that's an average of 1 number every 2 years_

Regardless - the big 4 or 5 carriers in the US [aside from that whole wire-tapping non-sense] don't typically pass out cell phone numbers to the genreral public when asked as this is usually coverd in their Corporate Privacy Policies_

the point is that if someone does get ahold of your Address Book or Mail.app content - then Yes it could cause big problems for any given person with information contained in your files_

I'm all for encrypting this type of content - but I am also in favor of transparent encryption - wehere it does it on the fly after I set it up and I don't have to worry about it every single time I send an eMail or add a Contact to my Address Book_



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: jonbauman on Sep 23, '08 10:38:04PM

What makes the disk image unmount on logout?

---
jon



[ Reply to This | # ]
Warning SparseImage corruption
Authored by: emarmite on Sep 24, '08 10:29:25AM

The SparseImage is contained within a file. If you are writing to it while your Mac dies for some reason the end result may be a corrupted file that can no longer be mounted, losing you the whole file & its contents as a result. As it's corrupted it cannot be mounted for Disk Utility to fix and as it's a file it can't be fixed without mounting.

I was using a sparseimage for my personal documents a few years ago. At the time my Powerbook often had problems coming back from sleep that required a power down and after a year, the inevitable happend: the file became corrupted and I lost some recent & valuable data. Even HFS with journaling doesn't protect you fully (go Google fsync to see why).

Not sure if this has been improved in 10.5 and/or if having Time Capsule makes any difference but beware, applying this tip does put your data at slightly more risk than before.



[ Reply to This | # ]
Reply to Concerns
Authored by: guns on Sep 24, '08 04:22:03PM

There seems to be a lot of confusion about the purpose / methodology of this hint, but unfortunately, I haven't had a chance to respond to comments in a timely fashion. So I'm going to roll up my sleeves and try to address the points brought up, if only for the record so it might be useful to someone in the future:

The Time Machine backup limitation is a hassle, but I don't understand why people would jump through so many hoops to rig up a homemade encryption solution when FV is a button-push away.

Filevault is definitely a good solution for the majority of people, and I apologize for the FUD (really), but like I mentioned in the post, it's not configurable. I use this method for some sensitive information that I keep outside of the OS X user directory (in the /usr/local/ tree). That doesn't seem possible with Filevault. Also, in the case of disk image corruption (see below), the whole user directory becomes unusable until restore, while corruption of selectively encrypted content won't stop the show completly. If you're wondering if it's really worth the effort, the relevant question is if you enjoy the process. If you don't, then do the easy thing.

If you are writing to it while your Mac dies for some reason the end result may be a corrupted file that can no longer be mounted, losing you the whole file & its contents as a result.

Well, this is the danger of data on encrypted images. This is one reason I don't like whole-disk encryption or Filevault; if fatal data corruption occurs, you're out of luck until you restore from a backup. If you're only encrypting a few directories of data, you con continue using your computer until you can restore from a backup.

Oh, this all assumes that you're keeping good backups. I should have mentioned this, but anyone actively working from encrypted disk images should be keeping regular backups. If you're not, go do that before encrypting anything. I recommend rsync, SuperDuper, and Jungle Disk.

As it's corrupted it cannot be mounted for Disk Utility to fix and as it's a file it can't be fixed without mounting.

I fully agree about the risks involved, but incidentally, I accidentally corrupted a large encrypted image containing the backup of my entire hard drive about five months ago, but was able to repair the filesystem dmage with Diskwarrior. It's a little expensive and not guaranteed to work so I certainly wouldn't rely on it, but it's not technically impossible to recover from filesystem damage in encrypted volumes.

Oh, and if you are running Leopard, sparse bundles are more resistant to corruption than sparse images, and like Toadling mentioned, are much more amenable to backups.

What makes the disk image unmount on logout?

The logout process unmounts any user-mounted volumes.

#---------------------------#

Now to Dr. T's concerns:

This seemed logical until the discussion of passwords. It makes no sense to assign a long password to the encrypted sparseimage and then put it into Keychain Access that is protected by a weak password. Your keychain password must be strong.

I'm not sure where I said that it was a good idea to keep a weak keychain password. I wrote:

Of course, if that password is in the keychain, then our keychain password should be relatively secure.

By relatively secure, I meant not as long as "venivedivici718a9508a9ce9695778eaedb9df851bc", not as in something trivially crackable, like "popcorn". My keychain password, for instance, is about 10 random characters with numbers, letters, and symbols. It is, as I wrote, relatively secure, easy to type, and enough for my needs. It would be better to go with a longer password, perhaps, but if more security is desired, you could:

2. Store this keychain on a USB key, and set it to mount at ~/Library/Keychains, as described above in step two.

This effectively separates the keychain from the disk images, so even a cracked keychain wouldn't immediately compromise your data. I object to the accusation of being illogical.

A second point is that you need to securely erase the files that were moved to the sparseimage. Some of that sensitive data may still be readable weeks after completing this process.

This is true enough. I should have mentioned this, but I was trying to spin this hint as a medium-level security process. If your data is terribly sensitive, then your best route is to use a TrueCrypt volume with plausable deniability on a brand new hard drive. Tiger's secure erase isn't even 100% reliable; zeroed out data can be retraced by high-tech labs, however slowly; Leopard's secure remove command (/usr/bin/srm) however correctly overwrites sectors with random data.

A third point is the issue of securing your Address Book. This makes little sense to me. Most names and addresses are in the public domain, so I don't see how it helps to hide them ...

Snip some comments about the futility of securing marginally private data / data synced to an iPhone:

My first response to this is that I agree that Address Book / Calendar information is hardly the most sensitive information that a person has on a laptop. That's why you could use this method to encrypt your entire Documents folder in addition to your contacts and calendar. Or, don't encrypt your contacts and calendars at all, and encrypt the few things that you do want to protect.

This hint was meant to provide a general method for modularly encrypting data while keeping it easily accessible, despite the title and examples. I personally use this method to secure business documents, financial data, and private source code, in addtion to the data in the examples.

I guess I could have been more clear about the generality of this hint, but I thought more people would be interested in the post if a concrete and compelling example was demonstrated. And it is compelling for me, because despite the fact that much of the information in Address Book and Calendar can be gleaned or acquired, I don't necessarily want the TSA (for example) to easily see who I know or what I'm scheduled to be doing when I'm boarding a flight or crossing a border.

Finally, the futility argument can be made against your mail in Mail.app as well. The emails go over the internet unencrypted, and furthermore, governments have been quite successful in acquiring email from email providers or outright intercepting them onroute. So what's the point of keeping your mail secured? Again, it's an issue of low-hanging fruit: if anybody with serious resources is after you, you should be employing heavier security. If you're trying to guard against moderate, opportunistic infiltration, securing the local copy of your mail makes sense.

Oh, and btw, if you do need to secure your email, you can do it with GnuPG. My business partner and I confidently email each other passwords and financial data all the time using gpg-encrypted mail. The GPGMail plugin makes it possible to have this functionality right within OS X's Mail.app.



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: Mr.C.Tippins on Sep 24, '08 04:28:34PM

I'm sure you already know that File Vault is nothing more than an encrypted sparse image. The OS then handles all the mounting/unmounting, other details and is supported under Time Machine as another commenter mentioned. If you are going to sparse image your stuff may as well do the whole Home directory as already supported by the OS, don't you think?



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: guns on Sep 25, '08 07:14:03AM

Yes, i do realize that Filevault is essentially this hint, applied to the home directory, and yes, it's a sparse image under tiger and a sparse bundle under leopard.

As I explained in the comment above, I personally don't want to use it for a few reasons:

1) Image corruption can lead to getting locked out of your user account until a restore (selectively encrypting your mail for instance, will lock you from your mail client, but you can still fetch your mail through a web interface after you log into your user account -- not a show stopper)

2) I want to control the terms of the encryption, and not leave it to Apple. I understand that filevault is straightforward, but since Apple does not provide many details or offer options to their services, I don't feel like I'm really in control. I was pretty dismayed to learn when first using time machine that it excluded (initially) VMWare virtual machines from its backups. I understand the rationale behind this, but this was largely undocumented and no options were offered. Sure, you could edit the plist at /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist, but then again, you could just use a different backup method. So now, by extension, I don't want to use any Apple utilities that make assumptions about your needs and offer no way to edit them.

3) i want to mount and unmount UNIX directories on login/logout.

I want people to understand that this hint is not for everyone. It's for people with moderate security needs who enjoy DIY computer solutions. I apologize again for denigrating Filevault, but this post was never meant for people who were satisfied with it.



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: selcouth on Sep 29, '08 05:05:40PM
I love this hint! Thanks for taking the time to write it up.

I'd like to add that thanks to the following link, I figured out how to make the mounts not show on the desktop. Though hackish, this really works well for me. Thanks again!

http://julipedia.blogspot.com/2007/01/hide-volume-in-mac-os-x.html


[ Reply to This | # ]
Effect of password reset on confidential data encryption
Authored by: CFQ on Sep 21, '09 08:27:36AM

Hi,

thanks for this tip!

I have recently learned though that the account password on a Mac can be easily reset by making use of the OS X installation DVD. What happens if a thief steals my MacBook and resets my account password? Does the confidential data remain encrypted, or is it still all dencrypted at login, even if there is not account password?

Thanks,
CFQ



[ Reply to This | # ]
Effect of password reset on confidential data encryption
Authored by: cdenesha on Jul 27, '10 10:48:04AM
Awesome tip and very clean writeup. Logical. :) I'd recommend that once you are switched over and are sure everything works, that you delete all backups of the old data on your Time Machine drive. I'm not sure how to do this securely, but perhaps a secure wipe free space program (will need to look for a tip!) can be run on your Time Machine drive as well as your original drive.
I have recently learned though that the account password on a Mac can be easily reset by making use of the OS X installation DVD. What happens if a thief steals my MacBook and resets my account password? Does the confidential data remain encrypted, or is it still all dencrypted at login, even if there is not account password?
When the account password is reset, the login keychain will be opened as well. Be sure to create a new keychain if you wish to store the password for your encrypted sparse bundle, you can even make it the default keychain and it'll still be secure in that instance. Also, your sparse bundle will be using either 128 or 256 bit AES encryption, so as long as you have a strong password the data itself is secure.

chris

[ Reply to This | # ]

Encrypt Mail, Address Book, and iCal data
Authored by: mk on Nov 25, '09 01:51:24PM

Fantastic article - thank you. A few notes to contribute:

1) New volumes are not automatically indexed by Spotlight which will break the ability to search "Entire Message" within Mail. Run the following to enable indexing:

sudo mdutil -i on "/Volumes/PRIVATE"

2) I once used Filevault and was excited to do a restore via my Time Capsule when I bought my new MBP. Turns out this is (or was not) supported by Apple. At least one of their technicians was told me how to open up the backed up image so that I could extract my files. The fact that Filevault breaks full user (everything) restores and requires users to be logged out in order to backup turned me off.

3) Here is a GUI based tool for managing sparsebundles: http://www.knoxformac.com/specs/

--
Marc

Edited on Nov 25, '09 01:53:05PM by mk



[ Reply to This | # ]
Encrypt Mail, Address Book, and iCal data
Authored by: zpjet on Aug 05, '10 02:42:17AM

Thanks MK, great sub-hint!



[ Reply to This | # ]