[liberationtech] New Satphone Safety Guide

Fri Mar 16 14:48:24 PDT 2012

Thanks Jacob, comments in-line.

But first a clarification. This guide was originally developed for a
specific use-case, teaching specific middle eastern activists not to use
Thuraya (thats why so much specific information about Thuraya) and why
another, really any other phone (for the syrian use-case), but in this case
the iSatphonePro(as the device chosen to be sent) is arguably better than a
Thuraya but really only very very minimally.

If in anyway the guide is not clear that #1 Satellite communications are
NOT SECURE, my apologies, and I would welcome advice to correct that.

I recognize now that, in our rush to distribute the guide publicly in the
wake of recent events, was overlooked in our final review. As this is a
Creative Commons (Open Source) project I would welcome any suggestions on
how to clarify this, and certainly if anyone is in possession of other
models of phone we'd be happy to test them or provide exact user directions
for how to engage in all the steps in section 7 for each model we can get
our hands on. Section 7 was provided to ensure that those receiving phones
had an easy guide for following the basic steps for improving the safety of
the phone they were receiving

On Tue, Mar 13, 2012 at 7:06 PM, Jacob Appelbaum <jacob at appelbaum.net>wrote:

> On 03/13/2012 03:43 PM, Brian Conley wrote:
> > Hi all,
> >
> > I'm pleased to announce that we have released our newest guide, focusing
> on
> > increasing satphone safety through best practices.
> >
> > You can find the guide here:
> >
> > http://smallworldnews.tv/Guide/Guide_SatPhone_English.pdf
> >
> > comments, questions, and critiques much appreciated!
> >
> > I will be writing a longer blog about the motivations and timeliness
> later
> > this week. Also you can see Frank Smyth's comments here at CPJ.org:
> >
> >
> http://cpj.org/blog/2012/03/from-small-world-timely-advice-on-safe-satphone-us.php
> >
> >
> >
>
>
> Hi Brian,
>
> Some thoughts in response to specific chunks of text from your pdf
> follow...
>

First of all, do I need to remind you that the content was made available
to you and others for peer review based on requests? I did not fulfill all
requests, due to some concerns about the publicity of the guide prior to
its release, but I did make a copy available to you weeks, if not months,
prior to publication.

>
> "If you communicate with someone outside the satphone’s service provider
> network your communications are subject to any observation happening on
> the other user. Communicating with other satphones from the same service
> provider is much safer. Even this method is not entirely secure, but
> following these basic steps will limit your risks."
>
> This is a really weird statement. The first sentence is true. The second
> is pretty subjective, I'd even say incorrect but there is some wiggle
> room. The third is also a bit weird to the point of being incorrect.
> Limit what risk? Risk in relation to whom? If someone is sniffing the
> uplink for either phone, it's irrelevant to take such a step - it's
> probably even irrelevant if your threat model includes the sat phone
> provider as part of the adversary model.
>

Perhaps the language is to simplistic? the thought is this:

your phone - your provider - any other provider - other phone  has far more
variables than:

your phone - your provider - other phone on same provider

perhaps rather than "not entirely secure" we should say "not secure" ?
point is to limit the potential variables for observation. If this method
is followed to the letter, it makes it easier to correct on the fly should
it prove not to be safe in a given environment.

>
> "The time needed to connect with the network is the first
> major security risk."
>
> Sure - why is that though? Isn't it because 0) the beam pattern for
> uplink 1) gps location being sent by the phone 2) the phone provider
> knowing 0 & 1 and 3) the downlink? So really is it the time that is the
> issue? Or what is done during that time?
>

This is unfortunately an artifact which, you've pointed out, doesn't
clarify why its the biggest risk. point is that if you are stationary/out
in the open to ensure a good connection you are more at risk, once your
phone has obtained a connection it is easier to conceal yourself/your
device. There are many risks, but the mere fact that you have to wait a not
insignificant period of time just to connect before you can even use the
device is something to be aware of.

>
> "2.3 USING A SATPHONE, A WALKTHROUGH"
>

First of all, this was a last-minute addition to the guide, and thus not
available to those who first offered peer review to the guide, it was
reviewed numerous times, but now i realize there may be some confusion in
the simplicity of the walkthrough.

>
> This walk through seems not entirely correct. For example 07 is not
> really the full picture, is it it? Isn't that when the phone sends the
> GPS data and not in step 10 as indicated?
>

Steps 07-10 occur almost at the same time. Perhaps we should add a color or
additional indicator to clarify this? Upon further review I realize it is
possible that, in some or all cases, between steps 04 and 05 a GPS fix is
transmitted to the provider and sent onward to the GES. I would appreciate
any exact information that can be provided to correct this. I'm also
waiting for responses from satellite phone distributors to the content of
the guide.

>
> "3.1 PHONE CONFISCATION"
>
> I rather like this part of the guide.
>
> "In some cases the authorities may have the proper equipment
> to “listen in” on your transmissions, however this requires highly
> advanced and sophisticated technology"
>
> I think this is misleading. What country doesn't have the ability to do
> this? It requires a fun cube dongle pro or a GNU Radio, a commercial
> device or something else home brew - if a hacker at the CCC can do it,
> it's not "highly advanced and sophisticated technology" in my opinion.
> That isn't to say that it was easy, it's just that now that the work is
> done - the code, the hardware and the rest of the information is
> available for anyone who cares to try. That is not a high bar and it
> would be misleading to suggest it.
>

This is a specific bit of information I was trying to verify, but
unfortunately the Libtech list and other peers have been unable or
unwilling to provide it.

In producing simple manuals, I feel it is important to be as exact as
possible, and where we believe something to be the case but could not
verify it, we have specified that. As I understand it, there is little
clear evidence of countries listening in on devices, though there is clear
evidence of the POTENTIAL and the CAPACITY to do it.

A second issue I'd appreciate further clarification on, specifically this,
from the bottom of page 13:

"When a file on a computer is deleted, it is not completely destroyed and
may be reconstructed without further measures. It is also possible your
satphone’s logs can be reconstructed from the satphone or data from the
service provider.. Deleting information is not a complete fail-safe, but
will make it harder for authorities to access information on a confiscated
phone."
It would be great to better understand how authorities/opponents might
reconstruct data deleted from a phone record, I assume this is demonstrably
true, but as with the "listening in" issue, I'd like to know more about the
limitations/accessibility of the tool necessary, and whether there are
other steps that can be taken by the user to destroy this data. (put the
phone in a blender or a microwave?)

> "Your location may be logged at the service provider’s Ground Earth
> Station (GES)"
>
> Or anyone watching...
>

>
> "Thuraya’s encryption has been broken, and more advanced
> governments may be able to break the encryption of other
> satphones. To learn more see Section 6.2.2"
>
> Which sat phone protocol isn't broken? I don't see a table for which
> protocols or devices you mean to support with this guide - so it's not
> clear why Thuraya is the security exception, rather than an example of
> the insecurity rule.
>

In section 3.3 just after that section we call out the decryption and
recording of GMR-1 and GMR-2 and point out that both Thuraya and
iSatphonePro Inmarsat phones fall under this. Are you suggesting that we
are unnecessarily expanding the "Thuraya is the only satphone to worry
about" myth? I certainly don't want to do that, this initial message about
Thuraya was written *prior* to the GMR-1 GMR-2 issue being published
(thats' how long we've been drafting and redrafting this guide). Perhaps
its overkill and even misleading to include both warnings now?

>
> "Voice calls are a very risky method for communicating via satellite."
>
> All times when a user is associated with the network the user is at risk.
>
> "It is best to keep your call under three minutes"
>
> Why three?
>

Three is the best approximation we could make based on a variety of
evidence, quantitative and qualitative: 1. the ability to recreate data
even in an unbroken GSM encryption, actual evidence of the targeting of
Dudayev and other anecdotes about satphone targeting, then working back
from this timeline (approximately ten minutes total from starting the call
to being hit by rocketfire) If it takes 1-2 minutes to activate the
network, 1-2 minutes to locate the signal, time to target and launch the
rocket, and time for the rocket to strike, 3 minutes seems like the
absolute maximum anyone should talk if they expect they are being targeted,
and expecting less than 3 minutes seems unlikely users will commit to.
Perhaps a call-out clarifying the relatively "qualitative" nature of this
comment should be inserted?

>
> "Email sent from your satphone does not provide the same protection as
> Email sent via computer or mobile data plans."
>
> While true, this implies that email is somehow secure, ever - which we
> all know to be totally bogus, right?
>

certainly HTTPS is *better* than HTTP, no?

>
> "On some mobile phones and all computers Tor can be used to
> anonymize your computers traffic and hide your identity and
> location. If at all possible use a secure internet connection to
> communicate, not a satphone."
>
> Tor can't protect you from hardware that spies on you - if your sat
> phone sends your GPS location, an attacker will know the exact location
> of the user, even if they do not know what they are doing or saying.
> This seems obvious but it is important to note - the GPS location is at
> a different layer.
>

Thanks for that clarification. Perhaps noting that a connection where the
phone is located some distance from the actual computer connection would be
helpful? Furthermore, should we now call out the fact that SATELLITE MODEMS
are just as bad as satellite phones??

>
> "Inmarsat’s iSatphonePro"
>
> Why? Rheinmetall, trltech, and others intercept that by brand name. How
> is that better than Thuraya? They're all doomed in terms of content
> security and location privacy - why suggest those in that case?
>

See above. Specifically aimed at helping users understand a "better option"
not a "good option" its standard public health practice, no?

>
> For example, it seems odd to me that you did not mention the
> Cryptophone[0] as an example of how to secure the content of the
> communications - that is probably the only tool on the market right now
> that has any such claim.  Combined with a Motorola 9501 Iridium
> satellite pager[1], I think you could do something interesting that
> actually improved the security of communications or at least assist in
> solving the rendezvous problem.
>
> The Motorola 9501 is entirely passive and so it can receive with a very
> minimal view of the sky, it does not transmit your location from the
> device, etc.
>

It would be great if you were interested in writing a first draft of such a
section, given the open source/creative commons nature of this project,
which I'm happy to edit. Knowing that you are also a very busy guy, perhaps
you are at least willing to comment on a draft that I may find time to draw
up int he future to suggest such a use-case?

I'll admit I was hesitant to read your email, but now I realize I was
mistaken for that. :)

Apologies to all for the delays, these emails came just before I was
returning home from traveling.

Please let me know what further questions this has arisen, or if anyone is
willing to assist with additional sections, particularly on other phones,
or developing a section for satellite modems or additional practices
relevant to use cases other than activists or solely satphone use.

regards

Brian

>
> All the best,
> Jacob
>
> [0] http://www.cryptophone.de/en/products/satellite/
> [1] http://www.outfittersatellite.com/iridium_9501.htm
>

-- 

Brian Conley

Director, Small World News

http://smallworldnews.tv

m: 646.285.2046

Skype: brianjoelconley

public key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEEF938A1DBDD587<http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE827FACCB139C9F0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20120316/075acda7/attachment.html>