[liberationtech] Safe app like Dropbox?

[Jacob Appelbaum]

John Adams:
> On Sun, Jan 6, 2013 at 1:47 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> 
>> I generally agree that the data should be encrypted, though I think it
>> should also be authenticated and integrity checked before it is actually
>> used.
>>
> 
> If this level of paranoia is relevant to you, then maintain multiple
> offline SHA, MD5, and other checksum formats before use.

Dropbox accounts have been compromised in myriad of ways. They have an
architecture that allows for content tampering without detection. I
think it is justified and not even remotely paranoid to ensure that
files stored with Dropbox are manually integrity checked or that certain
kinds of files are used so that users have integrity checking *before*
decryption. This says nothing of possible SSL/TLS issues - do they even
have client side pinning of certificates?

To dismiss my concern as paranoia is neither technically reasonable nor
using the term correctly.

To quote Google define:

par·a·noi·a
/ˌparəˈnoiə/
Noun
1. A mental condition characterized by delusions of persecution,
unwarranted jealousy, or exaggerated self-importance, typically worked...
2. Suspicion and mistrust of people or their actions without evidence or
justification.

A user in Syria is well worth attacking and we indeed see targeted
attacks for such users. That clearly cancels out the claim of paranoia.
I'd also say that the Syrian people are not alone in their concerns of
targeted attacks.

Exposing a user's kernel to an arbitrary disk for mounting is extremely
sketchy. I'd wager that an attacker could do some serious damage before
the user even expects to type in a password. There have been security
issues about this in the past and I think it is reasonable to guess that
it isn't an isolated incident:

  http://support.apple.com/kb/HT3549

Which says the following about Disk Images:

"CVE-ID: CVE-2009-0150

"Available for: Mac OS X v10.5 through v10.5.6, Mac OS X Server v10.5
through v10.5.6

"Impact: Mounting a maliciously crafted disk image may lead to an
unexpected application termination or arbitrary code execution

"Description: A stack buffer overflow exists in the handling of disk
images. Mounting a maliciously crafted sparse disk image may lead to an
unexpected application termination or arbitrary code execution. This
update addresses the issue through improved bounds checking. This issue
does not affect systems prior to Mac OS X v10.5. Credit to Tiller
Beauchamp of IOActive for reporting this issue.

Please don't call my concern paranoia. It isn't paranoia, it is an
abundance of caution based on very specific public data.

> 
> It would be trivial to script this outside of Dropbox's scope.
> 

It isn't usable and thus it is unlikely to be practically used. It seems
that this is a property of that a specific disk format should have and
in my view it should fail closed if the file isn't what it seems. That
second part is perhaps "just" a security UX issue.

> 
>> I also think most disk images are not actually that difficult to brute
>> force - I was involved in a project to perform FileVault bruteforcing
>> accelerated by an FPGA a few years ago. With a modern GPU, I think
>> things are pretty slanted toward the attacker.
>>
> 
> Saying that it's possible to break all encryption, all the time, is a
> non-answer and doesn't address practical uses of cryptography. It also
> creates an environment of fear for casual users. In the case of pure AES
> (and not putting reliance on flaws in the implementation of systems like
> Filevault), a reasonable attack on the algorithm still doesn't exist. (see:
> http://www.schneier.com/blog/archives/2012/03/can_the_nsa_bre.html)
> 

I'm not really making a general claim about crypto; sure lots of stuff
in the long run is possible to be broken and there is a lot of
speculation about the state of things today, etc.

Rather, I'm saying that the attack surface of using encrypted disk
images is multifaceted. Merely encrypting a file or disk image is only
part of the solution and probably a dangerous one, I think. Without
integrity checking as part of the format, the attack surface is way
larger than is reasonable.

There is also the major issue of the user space tools or the kernel
itself being flawed when operating on a malformed disk image, as
mentioned above. When the security UX is "click here, wait for password
prompt" - I think it is game over if the user does open the disk image.

> What the user needs to do is to measure acceptable risk and weigh that
> against the encryption system being used. It's also relevant to know the
> validity of the information and the required amount of time it takes to
> break the file. If you said 'meet me here next week' and it takes three
> weeks to break AES-256, then I don't really care if you find out where I
> was weeks ago.
> 

Forward secrecy is important and so is deniability. Generally one
doesn't realize they need it until they wish they'd had it all along.
That is why, like integrity, we should just design these properties into
the file formats, network protocols, and so on. Obviously some things
don't fit the mold but just because we don't want them now doesn't mean
they wouldn't be handy later. Sometimes we have to plan ahead for
generally unlikely outcomes.

As an example, if the entire thing relies on TLS without a forward
secret mode, I can imagine a reasonable attack. The attacker could
wiretap a target and then later decrypt the TLS session by getting the
long term key from Dropbox. Then the activist can be confronted and
asked to decrypt the disk image that was downloaded. If the attacker is
sneaky, they might even try to replace the image with a malformed one as
stated above.

> 
>> In this - I rather like what I've read about SpiderOak but I haven't
>> seen a totally free implementation of the client or the server side... t
> 
> 
> I haven't looked at it, but I'd like to.
> 

This is where they make some interesting claims:

 https://spideroak.com/engineering_matters

Overall, it seems to suggest that it would reduce the general attack
surface. As one won't be presented with malformed disk images even if
one enters the proper password unless the attacker already had the
passphrase in question.

All the best,
Jake