Time Machine encryption

[Virgil-TB2]

Hello,

I won't get my copy until later today, but I thought I would ask this question as I can't see it listed anywhere here ...

Time Machine is a security *plus* in the same way that all backups are. Without encryption turned on however, it's actually a security *minus* because it creates an easily readable, detailed, time-stamped, trail of all your actions at the computer. For that reason I won't be using it unless the encryption also works well.

However, it seems that the system comes with it turned off by default, and I was wondering if anyone had turned on encryption and if there was a performance hit associated with that.

[Transeau]

As far as I know, there is no option to encrypt Time Machine backups.
Maybe you can create a dmg and use that on an external drive.

[/dev/toaster]

In earlier seeds there was an option to encrypt the images, however it is now gone. Too many things got nerfed in timemachine before release.

[Virgil-TB2]

Originally Posted by /dev/toaster

In earlier seeds there was an option to encrypt the images, however it is now gone. Too many things got nerfed in timemachine before release.

Too bad.

I am guessing that Homeland Security is loving it though.

Let's hope this was just removed for technical reasons and will be back. It would be nice to have a secure backup feature.

[/dev/toaster]

I am pretty sure many of those things they removed from Timemachine right before release was due to bugs or other major hurtles.

[Veri]

Originally Posted by Virgil-TB2

I won't be using it unless the encryption also works well.

If you mean FileVault, it might protect against the random guy that swipes your machine and wants to see what dirt he can get, but consider this presentation on FileVault. Some key points:

• Not fully open-sourced, and no-one afaik has done a proper audit;
• Safe sleep images are unencrypted [edit: no, I misremembered - they are encrypted if encrypted swap is enabled, but keys are written to the header];
• Temporary files etc outside home directory are unencrypted;
• DMA attacks via firewire (unlikely but still cool ;-) ).

The second issue is the most obvious flaw if you're using a laptop - as any thief interested in espionage will begin by lifting out the drive and reading your /var/vm/sleepimage.

The first means one is relying on Apple's competence and trust that they've not incorporated a backdoor or non-trivial intentional weakness; regardless of Apple's good reputation, one cannot rely on such promises without auditing.

Anyway, *not tried it*, but consider that FileVault just produces a big fat DMG, so either Time Machine has special handling for it (and the idea that the "special handling" is to copy the unencrypted content is scary, but I guess it might happen ;-), or you're simply backing up a huge DMG every hour.

[Virgil-TB2]

Originally Posted by Veri

If you mean FileVault, ... (you could end up) simply backing up a huge DMG every hour.

Well I wasn't talking about FileVault per se and yes, backing up a huge disk image *does* kind of defeat the purpose of Time Machine anyway.

I was referring to all the recent reviews of Leopard that have been mentioning Time Machine as a "security feature" since it backs up your work and therefore makes it "more secure" in general.

It just seems obvious to me that unless the Time Machine disk and the process of sending data to it is encrypted, Time Machine is actually a way of revealing more information about your files and is thus has the effect of decreasing security.

For instance, if you use Time Machine for a year the data will easily fit onto one average HD bought for the purpose. Someone stealing/accessing that HD not only has access to all your files, they now have access to what you were doing with them, and when, on an hourly basis over the period of the entire year.

This means the Time Machine drive has information on what files you moved to what folders at what times and on what days. Presumably the file would be archived based on the "last accessed dates" that change with file views etc. Time Machine potentially creates a veritable Cornucopia of detailed personal information for law enforcement agencies (hurrah?), and thus a security "hole" for the average user who probably doesn't realise this.

Our average user is also not going to know enough to get into the guts of Time Machine and exclude particular files or folders etc. It will be a sort of "magic copy" for most users that they will never understand enough to alter the parameters in any meaningful way. Therefore, until the security of the data is protected in a similarly "magic" way, you have really taken the ability to manage their own security out of the average users hands. You have created a security hole that they cannot easily plug themselves and that they may not even be aware exists.

[Veri]

Originally Posted by Virgil-TB2

Time Machine potentially creates a veritable Cornucopia of detailed personal information for law enforcement agencies (hurrah?), and thus a security "hole" for the average user who probably doesn't realise this.

You're absolutely right - my money says that Finder/Prefs/Advanced/"Empty Trash securely" is now completely meaningless if you have Time Machine on, though I'd be interested in reports to the contrary. Assuming this tech note is still current, there is no support for third party stacking VFS plugins, so it's not as if users can be offered an installer which transparently encrypts all files on the backup drive (yeah, can still identify metadata, but it'd be a step up while allowing the drive for TM et al. to be seen as just another HFS volume).

A horribly convoluted sequence that might work for secure local backups: enable the local machine's AFP server and choose a local AFP mount as a backup drive; then once it's created the DMG container that, IIRC, it uses for remote backups, try converting it to an encrypted DMG. If lucky, the system will just ask for the password when it needs access and TM will continue as normal.

Mind you, if I recall correctly about a big sparse DMG just being used for remote TM backups, I don't see why support by the remote server of magic new HFS+ hard links, i.e. AFP calls which implement them, is technically necessary - to the server, you're just updating one big container. Maybe it isn't.

[/dev/toaster]

It totally rules out using a central server to backup a number of machines to. Now, instead of buying a few xserves to handle 80+ people, we are going to have to purchase 80+ external drives ....

I don't understand why they changed this.

[knapkin]

Generally speaking you *never* want to encrypt backups. Backups are about maintaining data integrity, not security. One bit flip on the encrypted disk and your backups are toast.

If you are in such a sensitive environment that physical access to the backup system is a problem, you should consider moving them offsite to a secure location.

[Veri]

Originally Posted by knapkin

Generally speaking you *never* want to encrypt backups. Backups are about maintaining data integrity, not security. One bit flip on the encrypted disk and your backups are toast.

A crypto algorithm can independently encrypt blocks of arbitrary size, such that corruption in one block will only affect that one block. Signing each block allows us to identify and discard any blocks modified due to bitrot or maliciousness.

If you are in such a sensitive environment that physical access to the backup system is a problem

Unless you are in a burglar-proof, espionage-proof, law-enforcement-proof fortress, then physical access to the backup system is a risk. Unless you're happy for others to read anything on your hard drive - and I've never met anyone who offers a public share that points to their drive root - this risk is a problem. Which is why FileVault was implemented in the first place.

[knapkin]

To be clear all of the below is in reference to encrypting backups. I'm all for encrypting as much of any primary device as possible.

Originally Posted by Veri

A crypto algorithm can independently encrypt blocks of arbitrary size, such that corruption in one block will only affect that one block. Signing each block allows us to identify and discard any blocks modified due to bitrot or maliciousness.

It was my understanding that FileVault did not have this functionality. However I would still argue that as the size of the blocks you encrypt increases, the risk of data loss increases substantially. Avoiding data loss is arguably the reason to do backups.

I can accept that there is a min/max procedure to be done though.

In terms of securing data and having effective backups, one must evaluate under which circumstances total/partial data loss is acceptable.

If it is never acceptable to loose data willingly (the assumption I was working under), then encryption is simply not an option.

In the case that data loss is preferable to data capture, I would argue a destructive failsafe (or series of redundant failsafes) on the backup device is preferable to encryption.

Now if you are worried about your destructive measures being countered, you must also be worried about having the passphrase for the encrypted device extracted from whomever is unfortunate enough to know it (unless you plan on going the cyanide pill route ).

Fundamentally, data security and data integrity are two different things, often with opposing goals. Being effective in both can be tricky. You seem to lean towards the security side whereas I lean towards the integrity side.

[Ranza]

Is it possible to back up to a encrypted disk image created using Disk Utility.

Perhaps saving the password in keychain so Time machine can always access it to store the latest back ups on it and the user not having to enter the password every time the disk image is opened.

[Jethryn Freyman]

In theory it should work, but I'm not sure if Time Machine lets you select a disk image to back up to. It should, but Apple may have deliberately programmed it to not accept disk images.

Can anybody confirm?

Also: can SuperDuper backup to a disk image?

[haravikk]

Hmm, no Time Machine won't let you select a mounted disk-image, otherwise an encrypted read/write image would be ideal

Where does Time Machine store its preferences? Maybe it could be entered manually?

[edit]
I found the com.apple.TimeMachine.plist file, and it appears to identify the target volume by the BackupAlias field, however it stores the value as "data" like:

AAAAAAGGAAIAAQ9FeHRlcm5hbCBEcml2ZXMAAAAAAAAAAAAAAADG0XcpSCsAAAAAAAEPRXh0ZXJuYWwgRHJpdmVzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsbRdykAAAAAAAAAAP////8AACkAAAAAAAAAAAAAAAAAAAAAD0V4dGVybmFsIERyaXZlcwAAEAAIAADG0WkZAAAAEQAIAADG0WkZAAAAAQAAAAIAH0V4dGVybmFsIERyaXZlczpFeHRlcm5hbCBEcml2ZXMAAA4AIAAPAEUAeAB0AGUAcgBuAGEAbAAgAEQAcgBpAHYAZQBzAA8AIAAPAEUAeAB0AGUAcgBuAGEAbAAgAEQAcgBpAHYAZQBzABIAAAATABgvVm9sdW1lcy9FeHRlcm5hbCBEcml2ZXMAGAArZmlsZTovL2xvY2FsaG9zdC9Wb2x1bWVzL0V4dGVybmFsJTIwRHJpdmVzLwD//wAA

I know this is a base64 string, but it doesn't produce plaintext so I can only decipher what some of it is. If we could figure out how to produce the above data entry then we could easily set any volume we like, unless it's identified in some way that would not uniquely identify the drive after being unmounted and remounted.

Time Machine won't even let you select the a disk-image volume to back-up data from, so I can't just add it and copy the entry

[haravikk]

Aha! I found this guide:
http://mike.peay.us/blog/archives/248

As it says, just create an encrypted .sparsebundle with the correct name (MachineName_MACAddress) on the top level of the target drive, and Time Machine will back-up into it, with whatever encryption you specified. Don't forget to the name the volume the image contains as "Backup of MachineName", or Time Machine will complain the image could not be accessed. In both names, MachineName would be replaced by the name of your machine (in my case "MacPro") which you can get from the Sharing panel in system preferences, and MACAddress is the MAC address of your primary ethernet port (en0) which you can find from network utility, remove the separators (hyphens or colons) from the number.

Oh, I should add the note that the image needs to be mounted when Time Machine begins (since it's encrypted Time Machine won't open it automatically). However, you must select the drive the image exists on as the target-drive, not the image's volume. So if your image is at /Volumes/BackupDrive/MyMac_1234567890.sparsebundle then you will mount the bundle first, then select /Volumes/BackupDrive as the target. Your sparebundle image will be given the time-machine icon, and back-up as normal.

[haravikk]

One further note; Time Machine attempts to unmount the image once the back-up is finished. For this reason I've placed another image inside mine, just an unencrypted, empty .sparseimage. When I log-in a simple shell-script runs which mounts my encrypted image first, then opens the image inside in order to prevent Time Machine from being able to unmount the secure image.

I then used the chflags command-line utility to hide both volumes so they don't clutter up my Finder.

Another solution if the drive is to be used by all users would be to use a system start-up script to mount the secure volume with the -notremovable flag, but you would need to add your pass-phrase to the command which would seem to defeat the point of encrypting the image. Since I only have one user on my machine anyway, then I'm perfectly happy to just use my keychain. I had originally intended to not use the keychain and just let the password box appear so I would have to enter it each time, but that doesn't appear to work with the shell script (which progresses to the next operation early and fails).

[Idlebum]

I have a simpler, though only pontential, solution, as I have not tested it myself yet.

What about just making an encrypted Truecrypt (http://www.truecrypt.org/) volume in the standard Mac OS Extended (Journaled) format and use it as a normal Time Machine volume? Truecrypt can encrypt entire disks, disk images and even startup volumes in standard Mac and FAT32 formats (at least the PC version does the equivalent). It uses AES and similar formats for encryption. To access Truecrypt volumes one needs either a password, which is either stored in Keychain or not at all, and/or a keyfile, which can be stored anywhere.

What do you think?

[haravikk]

Ah, it's a sensible idea, but I believe others have tried it, in another thread on this same topic (can't find it now) and found that Time Machine won't allow you to select it as a target.

If we could figure out what the binary string I posted is comprised of, then it may be possible to "force" volumes that Time Machine won't ordinarily recognise.

[maflynn]

Why would you want to encrypt your backup, seems risky as you're playing with the stability/accessibility of your data. That is, if you lose the encryption key or something burps in the encryption/decryption your SOL.

Typically when you want to restore something, its because of a problem you don't need the added headache of trying to decrypt your backup and it not working while experiencing a problem that required you to restore a back up in the first place.

Why not use encrypted DMGs for your sensitive data and TM will back them up as is, so your sensitive data will sit in TM encrypted but your entire backup is not.

[Idlebum]

Although I fully understand the concern regarding the reliability of encrypted backups, the premiss here is that encrypted file systems or disk files are reliable enough for backups. If they are not, it can be seen almost an entirely as an isolated problem with the encryption method.

Filevault is a realtime encryption of files that are used all time, and thus encrypted and decrypted all the time. Even so, I have never experienced any reliability issues with it. Why should a backup, which is mostly never used, except for incremental addition and deletion of files, be any less reliable?

Also, using encryption keys is optional, and can themselves be backed up an infinite amount of times, mostly it is just a matter of storing or remembering passwords.

[haravikk]

I fully expect to remember the password for this

The images Time Machine supports are sparse-images, which as I understand it are allocated in blocks, and likely several of these are encrypted separately, rather than the whole thing being encrypted in a single-pass, so any error would only invalidate a single chunk, if even that much (there may be error-correction, I dunno).

Generally I'm not as concerned with the historic back-ups of Time Machine as I am of having a whole copy of my system (well, user folder) so I can re-install if my internal drives ever fail. I expect that the likelihood of my Time Machine backup becoming damaged, and me wanting a historical copy of a file is remote enough that it's unlikely to happen at all.

My current set-up is that I have a single internal volume, in three partitions. One is boot-camp which I don't care about, the other is my OS and applications/settings volume, which I encrypt parts of. The third is my "media storage" volume which is encrypted using TrueCrypt and only mounted on my successfully logging in, this contains a ton of a large images and movie files I've worked on.

I want all of these backed up to a single external volume, and I figure that having the whole thing encrypted is a heck of a lot easier than trying to do it all individually.