Jungle Disk
Jungle Disk (JD) is an interesting power tool – it lets you treat Amazon’s S3 “cloud” storage service as a local network drive.
A few things about JD caught my attention. First, it’s cheap – only $20, and that’s after a free 30-day trial. That’s pretty cool.
Second, JD requires users to register directly with Amazon for an S3 account. That’s an interesting tradeoff. On one hand, it greatly simplifies JD’s billing and business model. On the other hand, it limits their target audience to people who are willing, and sufficiently sophisticated, to not only learn about Amazon web services (AWS) but also to sign-up.
Third, I noticed in an early newsgroup post that JD’s creator had added an encryption feature for the data at rest. Then I noticed that they provide sample code for reading and decrypting the data, targetted at those users who, rightly so, are paranoid about not being able to decrypt their data if Jungle Disk goes out of business. This was a nice gesture.
In fact, I now notice that the JD home page says, prominently, “Your data is fully encrypted at all times.” It was this claim that prompted me to sign-up with AWS and install the JD free trial to check things out.
When you first run it, JD prompts for your AWS “access” and “secret” keys. It then stores this data locally in the %userprofile%\AppData\Roaming\JungleDisk\jungledisk-settings.xml file. Interestingly, the AWS secret key is not stored in plaintext form. I see that the JD program binary imports Crypt32!CryptProtectData, so my guess is that they’re using the Windows Data Protection API for this (obviously, only some of this analysis will apply to the Linux version of JD). The DPAPI encryption is based on the Windows logon password. Thus, if you can logon as the user, then you can decrypt his/her DPAPI data. Still, JD has made appropriate use of that feature in this case – nice!
The next thing that JD does during initial configuration is prompt the user to choose between “Standard” and “High” security for the cloud data storage. The High setting requires a user-supplied password, which is then used as the basis for the file encryption key. Unfortunately, Standard is the default, in which case a default password (which appears to be “Bucket Password”) is used. That’s equivalent to no encryption. Yes, the data has been run through a cipher algorithm, but that’s only as good as the secret material used as the basis of the key. No, the problem isn’t that JD provided sample decryption code. The problem is that users need to use strong passwords.
One side note about that sample code, though. There’s heavy use of MD5, including in the key derivation. That’s bad; MD5 is insecure.
Finally, that security settings page also mentions that data in transit is protected by SSL, which is pretty cool. I hadn’t realized that S3 offered HTTPS. That prompted me to do a network capture of copying a reasonably sized (4 MB) local file to the JD drive.
First observation – JD copies data in the background. That’s mostly good, because I’m guessing that the latency for command-line access would be horrible otherwise. On the other hand, that means that, while my brand-new file shows up in a directory listing of the JD drive, it’s not actually fully copied to the cloud yet. However, JD anticipated this challenge by providing a systray application that shows pending transfers. Mine advertises a little more than 300 kilobits per second on a basic DSL connection. Thus, my 4 MB file took around 2 minutes to upload.
Anyway, having confirmed the SSL (TLS, actually; I checked) transfer, I wondered what the data transfer would look like with transport security disabled. Turns out the JD monitor/systray application exposes that option, so I disabled it and copied another file. Sure enough – there’s my AWS access key in plaintext, as well as the signature based on my secret key. More on AWS authentication can be found here.
Thanks for the review! A note on the use of MD5 for key generation – MD5 has been shown to have collisions, which makes it bad for use as a cryptographic signing hash. However, as a hash algorithm it is still considered excellent, which makes it a good choice for key generation.
Well, the default lack of a user password is definitely the weakest link. If the user provides a password, it’s still probably the weakest link, depending.
I’m uncomfortable with calling MD5 “excellent” or “a good choice” in any situation, cryptographic or otherwise, based on what’s published, except as a compromise for backward-compatibility.
Also, when Jungle Disk switched to AES (I saw an early reference to RC4), MD5 became a bad choice even assuming its best-case collision space. That is, there’s a 128-bit (at least) key space cipher with a 64-bit (effective) key space hash.
Most would agree that SHA-256 is currently the proper choice for supporting 128-bit keys. And it’s supported by both .NET and OpenSSL.
The default to standard (SSL, no bucket password) security is simple: The greatest “risk” to most users is that they forget their password. When that happens there is no recovery and all data is lost. For those users who want added security and can take responsibility for remembering their password, that option is available.
Regarding MD5 for key generation – note that it does not simply use a hash of the password (which would limit the key size). Rather, MD5 is used as an input to a PBKDF2 (http://en.wikipedia.org/wiki/PBKDF2) key generation function, which allows you to extract as many bits of key data as needed (randomness limited only by the length of your pass phrase). Of course, most users have no where near 256 bits, or even 128 bits of randomness in their pass phrase, but we don’t limit your choice in that area.