Daemonic Dispatches

Spammed by TimeBridge

I recently received an email, allegedly from someone I knew:

I'd like to add you to my network on TimeBridge.

Get started by checking out my calendar:
http://app.timebridge.com/user/availability/<CENSORED>

- <CENSORED>

A short time later, I received an email which actually was from this person, telling me (as I suspected) that he did not, in fact, want to add me to his network on TimeBridge. Three things went badly wrong here.

First, if you have a Google Calendar, TimeBridge wants to connect to it. How? By asking for your email address and password, logging in as you, and downloading it. But the password which controls access to your Google Calendar is also the password which controls access to Gmail, Google AdWords and AdSense, Google Checkout, and Google Web History. Do you really want to give TimeBridge access to all of that?

Second, TimeBridge asks if you "want to share your calendar with your friends". Well, why not? Sharing is one of those automatically nice things we were all taught to do in kindergarten, right? What TimeBridge should have asked is "do you want us to spam everybody you know". Remember what I said about how your Google Calendar password also controls access to Gmail? At this point TimeBridge logs in to Gmail, pretending again to be you, and downloads your address book. Of course, there's a reason why TimeBridge asks such a misleading question -- how many people would answer affirmatively if they were asked if they wanted their friends to be spammed?

Third, TimeBridge sends out the email quoted above to everybody in the address book it downloaded -- pretending to be you. TimeBridge's Terms of Service state that

3.2(f) You may not impersonate another person (via the use of an email address or otherwise) or otherwise misrepresent yourself or the source of any email.

but apparently this prohibition against impersonating other people doesn't extend to TimeBridge itself. Clearly the people who work at TimeBridge have learned the same lesson as many authors of malware: People are far more likely to pay attention to you if you pretend to be someone they know and trust.

Lessons to be learned here? Don't do business with spamming and impersonating outfits like TimeBridge. And for the love of security, the next time someone asks you to tell them your password to some other website or service, Just Say No.

Tarsnap public beta

Tarsnap is an implementation of my idea of a perfect online backup service. After many months in private beta testing, tarsnap is now publicly available for BSD, Linux, and other UNIX-like operating systems.

The design of tarsnap was guided by the following four principles:

• Backups should be secure against attack from Hostile Governments and (Extended) Three Letter Agencies, even if they force me to cooperate with them. You shouldn't have to trust me to keep your secrets if someone puts a gun to my head -- because if someone puts a gun to my head, I'll do whatever they tell me to do.
• Backups should be powerful but intuitive. Each time you create a backup, you should have complete control over what you want to have backed up; and you should be able to delete backups at any time. A backup service shouldn't do things like deleting old backups after 30 days just because the original version of the file was deleted.
• Backups should be efficient. You should be able to rename files, create multiple copies of them, append data to them, edit parts of them, concatenate them together, et cetera, without needing to store the unchanged data twice.
• Backups should be provided as a utility, with pay-as-you-go pricing. Forcing people to figure out ahead of time how much data they want to back up so that they can sign up for the right "plan" is dumb, and having some customers subsidize other customers is inherently unfair.

How does tarsnap satisfy these four principles? Let's look at them one by one.

Paranoid security

Before you can start using tarsnap, you have to register a machine with the tarsnap server using the tarsnap-keygen utility. This serves two purposes: First, it tells the server which account should be charged for usage; and second, the tarsnap-keygen utility generates cryptographic keys. Several cryptographic keys, in fact.

The keys used by tarsnap include

• A 2048-bit RSA key used for signing archives. This is used in combination with SHA256 and a Merkle hash tree to verify the authenticity of stored archives. (Cryptographers: RSASSA-PSS is used, with SHA256 as the hash function.)
• A 2048-bit RSA key used for encrypting session keys. All the data which the tarsnap client sends to the server to store is encypted with per-archive random AES-256 keys; those keys are encrypted with this RSA key and attached to the stored data. (Cryptographers: RSAES-OAEP is used to encrypt the session keys, using MGF1 and SHA256, and the padding verification performed when decrypting is carefully written to be free of timing side channels. The AES-256 keys are used in CTR mode, with sequentially incrementing nonces.)
• A 256-bit HMAC-SHA256 key used to protect each individual block of data from tampering. From a cryptographic perspective, this is unnecessary, since a Merkle hash tree protects each archive; but data is compressed using zlib before being stored, so this provides protection against a theoretical attacker who can tamper with stored data and has found a security flaw in zlib decoding.
• Two 256-bit HMAC-SHA256 keys used to generate names for blocks of data stored. Tarsnap uses the same reference-by-hash trick as my Portsnap and FreeBSD Update utilities do; using HMACs instead of raw SHA256 hashes prevents any information from leaking via the hashes. (Why two keys? One is used to hash data, and the other is used to hash archive names. Yes, that's right, even the names of archives are stored securely.)
• Three 256-bit HMAC-SHA256 keys used to sign requests sent by the tarsnap client to the tarsnap server: One used for writes, one used for reads, and one used for deletes. These are the only keys sent to the tarsnap server by tarsnap-keygen.

Naturally, not all of these keys are needed for every operation. Tarsnap comes with a tarsnap-keymgmt utility for generating key files with a subset of the keys. For example, you can create a key file with only the keys needed to write an archive; you could use this to generate backups from a server every day, knowing that if an attacker broke into your server and started deleting all of your files, he would be unable to destroy (or even read) your backups.

Tarsnap's paranoia also extends to the client-server protocol. With most online backup services, you're lucky if they use SSL; I avoided using SSL because I wasn't satisfied with its security. Obtaining a fraudulent SSL certificate is too easy (read: possible) for an attacker, and relying on external certification isn't necessary for tarsnap: The tarsnap server's public key is included in the tarsnap client code. Further, the complex and error-prone SSL protocol (how error-prone? Just look at how many security issues OpenSSL has had over the past decade) is replaced by a significantly streamlined protocol which is cryptologically similar to SSL and resists chosen-input side-channel attacks. (Cryptographers: The server uses its 2048-bit RSA key to generate an RSASSA-PSS signature on a Diffie-Hellman parameter modulo the 2048-bit "group 14" modulus. The Diffie-Hellman computation is performed using a blinded exponent. The result of the DH exchange is mixed with a 256-bit server nonce, a master key is generated using MGF1, and client and server AES-256 and HMAC-SHA256 keys are derived from that. Finally, the client and server exchange HMAC-SHA256 signatures of the master key to confirm that the key exchange succeeded. After the key exchange is complete, variable-length packets are exchanged, authenticated using the HMAC-SHA256 keys and encrypted using the AES-256 keys in CTR mode.)

Naturally, I would never ask someone to blindly trust a binary which I provide, so all the source code to the tarsnap client is available.

Tar-like front end

What's the most powerful and widely used archiving tool on UNIX-like systems? Tar. Various versions of tar have existed ever since Seventh Edition Unix was released in January 1979, and rare is the user of a UNIX-like system who hasn't at some point typed tar -xf foo.tar or tar -cf backup.tar ~/myfiles.

Tarsnap, as the name suggests, has the same look and feel of tar. You can run

tarsnap -c -f mybackup ~/myfiles

to generate an archive named "mybackup" which contains the files in ~/myfiles; and you can run

tarsnap -t -f mybackup

and

tarsnap -x -f mybackup

to list and extract the contents of the archive "mybackup". Because tarsnap is based on Tim Kientzle's excellent libarchive archiving library and the included bsdtar implementation of tar, tarsnap also accepts --exclude, --include, --keep-newer-files, --nodump, and many other options.

Of course, instead of being stored as a file on your local disk, tarsnap archives are stored remotely. Since you can't list your archives with ls, there's a

tarsnap --list-archives

command to do that for you; and since you can't delete an archive with rm, there's a

tarsnap -d -f backupInolongerwant

command to do that.

Finally, just in case you want to stop using tarsnap but keep your archives,

tarsnap -r -f mybackup

will convert the archive "mybackup" to a tar stream and write it to the standard output.

Snapshotting

The second part of the name "tarsnap" is "snap". Rather like in "Portsnap", actually.

As with Portsnap, the "snap" in tarsnap refers to snapshots; and this is what makes tarsnap both efficient and intuitive. Most backup systems work with a model of "full backups" plus "incremental backups": Once in a while, a full backup is generated, which involves storing everything; and then more frequent incremental backups are generated, which store only the differences since the last full or incremental backup. When you want to restore a backup, you start by going to the most recent full backup, and then you apply each of the intervening incremental backups -- all told, a big headache at exactly the time when you don't need any more headaches. By working with snapshots, tarsnap eliminates the "full plus incrementals" paradigm.

When tarsnap writes archives, it keeps track of each block of data which has been written to the server. If it sees the same block of data again -- even if it's part of a different archive -- it doesn't need to store that block. Tarsnap also keeps track of how many archives reference each block; when you delete an archive, tarsnap only removes blocks from the server when there are no archives remaining which reference them.

In the "full plus incrementals" paradigm, there's a trade-off between full backups and incremental backups: Incremental backups are far more efficient, but are less convenient because you can't keep an incremental backup unless you keep all of the preceding increments back to the last full backup. Snapshots provide the best of both worlds: The performance of incremental backups, and the convenience of being able to decide to keep or delete each archive completely independently of other archives.

Prepaid "utility" pricing

Tarsnap uses a model which should be familiar to anyone who has ever used a prepaid mobile phone: You deposit money into your account by sending a paypal payment, and as you use tarsnap, money is deducted from your account at a rate of 300 picodollars per byte of bandwidth used ($0.30 / GB) and 300 picodollars per byte-month of storage used ($0.30 / GB-month). When your account balance reaches zero, you lose access to tarsnap. If your account balance stays below zero for too long, your account will be permanently removed any backups you have stored will be deleted.

That said, tarsnap doesn't follow some of the more obnoxious aspects of mobile phone pricing: Your money won't evaporate after X days, there isn't any monthly "account maintenance fee", and if you want to stop using tarsnap, you can have your money back. It is your money, after all.

If you use twice as much storage and bandwidth, you pay twice as much. If you use a very small amount of storage, you pay very little -- some tarsnap users have less than 10 MB stored, and they're paying a fraction of a cent per month. All of the accounting for tarsnap is rounded in the customer's favour to the next attodollar (that's a millionth of a picodollar, or a quintillionth of a dollar), mostly because I'm a math geek who hates rounding errors.

Public beta

So what does it mean for tarsnap to now be in public beta? It means that if you go to the tarsnap beta testing website (UPDATE 2009-10-19: Go to the main Tarsnap website instead), you can create a tarsnap account, download the tarsnap client code, and start using tarsnap (at least, as soon as you send in some money via paypal to fund your account). It also means that there are some rough edges which I want to get rid of before I remove the "beta" label:

• The tarsnap website is functional, but minimalist to an extreme. (UPDATE 2009-10-19: The Tarsnap website is now less extremely minimalist.)
• I need to write more documentation.
• I currently process incoming payments manually, which can result in a delay of 8-12 hours if a payment arrives when I'm not in front of my laptop. (UPDATE 2009-10-19: Payments have been processed automatically since January 2009.)
• The tarsnap account management interface on the beta testing website doesn't have a password reset mechanism yet.
• Some minor scaling issues need to be fixed; if you plan on storing more than 100 GB of data on tarsnap, please let me know in advance. (UPDATE 2010-02-23: The above-mentioned issues were fixed a few months ago. There are still scaling issues, but they're much further away now -- please warn me if you plan on uploading more than 5 TB, though.)
• I haven't figured out how to deal with Canadian and BC sales taxes yet, so for now only non-Canadians are allowed in.

In spite of these (minor) rough edges, the past months of private beta testing have demonstrated to my satisfaction that the tarsnap code is very solid. The "beta" label is an indication that some things are still subject to change and improvement -- not a statement about the quality of the code which is already done.

So what are you waiting for? Go and get started with tarsnap! (UPDATE 2009-10-19: Link changed to point at the main Tarsnap website.)

Wuala's improved security

Last year I wrote about the poor security of the Wuala online storage and file-sharing startup. Over the following eight months, the people at Wuala made significant improvements, and four months ago Dominik Grolimund asked me to update my blog concerning their now-improved security. Unfortunately bronchitis and and wrist pain delayed this substantially; but here's my belated reassessment of Wuala's security: Much better, but still lacking in some respects.

The big improvements first:

• Wuala no longer uses ECB (Electronic Codebook) mode for encrypting files. They're now using CBC (Cipher Block Chaining) mode instead; this wouldn't have been my first choice (I'm a big fan of CTR mode due to its seekability and trivial application to partial blocks), but there's nothing wrong with CBC from a security perspective.
• Now that Wuala is using CBC mode, the proper use of initialization vectors is important; based on what Dominik has told me, it sounds like IVs are being generated in a manner which will ensure that they are unique as long as no collisions are found in SHA256. Wuala even went further than necessary here, ensuring that IVs will be unique even when used with different AES keys -- but I approve of the paranoia here, since it makes Wuala more likely to resist any as-yet-undiscovered attacks.
• Wuala is now using a slower key generation algorithm. This is critical for guarding against offline dictionary attacks, since anyone who obtains a Wuala user's password can download all of his "private" files. Given that people tend to leak passwords very easily -- either by reusing them, handing them over in exchange for chocolate, or typing them where other people can watch or listen -- the notion of having one's data protected only by a single password scares me (in tarsnap, an attacker must obtain a secret key file in order to access a user's data), but obviously different people have different levels of paranoia.

A few points remain major concerns to me, however:

• Wuala relies upon a central server for verification that files have not been tampered with. Now, Wuala's central server doesn't hold the keys needed to decrypt "private" files, and as such it cannot create "fake" versions of private files which decrypt to anything non-random-looking; but if a file stored on Wuala is made "public", Wuala can replace the file with anything it wants. Among other things, this means that Wuala should NEVER be used to publicly distribute executable code unless a strong hash is sent out-of-band and verified after the download is complete.
• The source code to the Wuala client is not available. While I have no reason to think that Dominik or anyone working at Wuala has inserted any evil code into the Wuala client, at present there is no way to know. Somehow "hey, download and run this program! It will back up all of your data over the internet, and it's perfectly safe because it encrypts everything first. Really it does! Trust me!" isn't a sales pitch which inspires a lot of confidence in me. Of course, Mozy and Carbonite seem to be successful with precisely this pitch, so clearly I'm more paranoid than most people -- but I would never ask someone to blindly trust a binary which they downloaded (especially if it could start uploading gigabytes of data without drawing attention) and for tarsnap I make all of the client source code available.
• Because of the design of the Cryptree key management system used by Wuala, it is possible for Wuala (and possibly other attackers, but I'm not sure about that) to identify which files you have modified. This sounds like a minor point, but it is a potential problem: For example, when people decide to update their CVs / resumes, they would often prefer that their current employer not find out.

Finally, I have one non-security-related concern about Wuala. Due to the design of Wuala's key management system, there isn't any way to update part of a file: If you modify a file and back up the new version, Wuala generates a new key and re-encrypts the entire file. No security problem here; but if you have a large file which changes frequently -- for instance, a mailbox file for those people who are old enough to stil use an offline mail user agent -- you will end up wasting a very large amount of bandwidth.

Make sure that your password is strong; that you don't reuse it anywhere; and that you never type it into an untrusted system or where people could watch you or listen to your typing. Realize that you can't trust the authenticity of any public files. Don't modify and re-upload files if you don't want people to know what files you've changed. And recognize that ultimately you're completely trusting Dominik Grolimund and the Wuala staff with your computer and your data.

But aside from that, Wuala's security now looks fine.