[guardian-dev] Fwd: What is "Panic" discussion

[David Oliver]

Abel thanks for this.

Folks, my worry is not so much the technology of what we're doing as a
problem with terminology that "means different things to different people".


He's my two cents, and even without it I think we need to come to grips
with how to explain what we have:

PANIC, to me, means a rapid "fight or flight" type reaction to an immediate
situation.  There is little time to think and discriminate between choices
for possible actions - there is only an immediate need to remove the
danger.

I understand the reasons a panic might occur relate to a user being in
possession of a mobile device which one or more external parties - usually
armed and of official capacity - believe contains "harmful" information.
 In "panic mode" the user is being chased by those people.

>From this perspective, I don't see "I think the police are on their way to
my hotel room" as a "panic" situation.  I don't see "I am now headed home
to the USA from country-with-ugly-regime, and am about to go through the
security check where they may examine my phone" as a "panic" situation.

Therefore, I believe the "panic" situation we are trying to address must be
addressed in a time-period of between 10 and 30 seconds.  What can out
technologies do in 10-30 seconds?  My guess is they can do A LOT of a
nature that would mitigate the probability that a first-responder would
find the harmful information.  But we need to architect that way.

 Nate has said, and Abel as seconded, that there is true need exists for
"deep cleansing".  But that sort of effort takes many minutes or even
hours.  This problem is somewhat mitigated in SOME instances by the
apparent fact that the authorities will sometimes delay any forensics on
the device for minutes or hours.  All good!

So, I'd like to repeat my suggestion/request - and I'm doing so in the name
of making the terminology consistant and unambiguous: We should architect
the functions in such a way that "first looks" are mitigated immediately
while progressively more-deep forensics are mitigated as more minutes are
available.  This is a sound philosophy, as I see it, for all use-cases -
because highly-knowledgeable users who know they need their device wiped
with the highest degree of certainty know that such an activity takes time.

The people I am really worried about are those people who are quite
innocent about what's possible in forensically inspecting a device who
believe - because of the name we use - that their device is forensically
secure in 10 seconds.

What can we do to implement this sort of thinking in our app (In The Clear)
and in that software as a "function", which we need to import into other
apps)?????


Dave





David M. Oliver | o <david at olivercoady.com>liver.david.m at gmail.com |
http://<http://olivercoady.com>
davidmoliver.com | http://dmo.tel | @davidmoliver | +1 970 368 2366


On Tue, Mar 5, 2013 at 9:21 AM, Abel Luck <abel at guardianproject.info> wrote:

> Nathan of Guardian:
> > (moving this discussion to guardian-dev)
> >
> > On 03/01/2013 03:18 AM, David Oliver wrote:
> >>
> >> Nate - is your experience radically different? That is, is "panic"
> >> indeed defined as a timeframe which can be handled by the current
> >> software - which appears to me to be roughly 2-30 MINUTES?
> > I replied to this in the other thread message, but it is important to
> > consider how these things usually play out, and by these things, I mean
> > the imminent detention of someone carrying a smartphone full of
> > sensitive data. In general, even if they only have a few moments to
> > realize something is going to happen, there is still quite a while
> > between that happening, and their smartphone being accessed or
> > inspected. In some cases, even in some of the worst places you can
> > imagine, I have first hand knowledge that people were allowed to keep
> > their phones for quite a while before they were taken and inspected. I
> > am talking *hours* hours before these devices were removed from their
> > pockets and inspected. OTOH, in more local cases with NYPD arrests,
> > phones are immediately taken, but unlikely to be
> > clone/processed/extracted for a few hours.
> >
> > 2nd, I also want to make the point that if our target audience is using
> > full-disk encryption of some sort (such as is built into Android 4.x),
> > then the wipe process for this is quite fast technically, though the
> > actual mechanism for doing this on an Android phone takes too many
> > steps, and can often fail mid-process. For apps with SQLCipher or
> > IOCipher in them, our hope is to optimize this process, and so the
> > "insta-nuke" feature we have been designing into our new apps matter
> > greatly here.
> >
> > 3rd, in our work on panic apps, with InTheClear, the feature of wipe was
> > paired with the "emergency distress beacon" feature that uses ongoing
> > background SMS alerts containing GPS and cellular tower location to
> > notify your friends, family, support network that something has happened
> > to you. This is a whole nother side of panic functionality, that doesn't
> > really involve anything about forensically sound data-wiping.
> >
>
> +1 to all this. "Panic button" is a term being thrown around that means
> different things to different groups. For some it is forensically wiped
> flash memory, for others it is a distress beacon, for yet others it is a
> deadmans switch that deletes/locks their online presence (twitter,
> facebook accounts etc).
>
> Some of these features are mutually exclusive.
>
> Example:
>
> On a FDEd phone, the fastest and most secure way to do a wipe, is to
> overwrite the portion of disk where the LUKS key is stored [1] and do an
> emergency poweroff. This takes seconds. But, once initiated, the phone
> can no longer be a distress beacon.
>
> This is something I've stressed in my talks with others about a "Panic
> Button". Different groups have different needs due to their different
> threat models. I oppose the idea that you can create a Panic Button app
> that will be generally useful for everyone.
>
> ~abel
>
>
>
> [1]: quick FDE intro: your FDE password unlocks a key on disk which is
> in turn used to decrypt your disk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20130305/ce8647e4/attachment-0001.html>