[liberationtech] New Satphone Safety Guide

[Jacob Appelbaum]

Heya Brian,

On 03/16/2012 02:48 PM, Brian Conley wrote:
> 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.
> 


See, I'm just not convinced there is a practical difference; there are
off the shelf devices for both kinds of phones with intercept, tracking
and other nasty stuff. Additionally hobby level gear is nearly
identical, except in terms of usability/availability. The main
difference between the commercial and hobby gear is that money is traded
for talent or knowledge. So if you're money poor and time rich, it's
still bad news for the user....

Don't get me wrong, I appreciate that the perception of Thuraya security
is bad in an absolute sense. It's good to alert people, obviously. But I
think it's also really bad to suggest that then people should try this
other kind of bad tech which is bad in some super subtle manner that is
hardly understood by reasonably technical people...

> 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 think it would be good to outline that by default, short of a crypto
phone, everything is doomed. And with the cryptophone, it's still
location privacy doom, I think.

I imagine something like this page for sat phones would be quite useful:
https://www.eff.org/pages/tor-and-https

> 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
> 

I'd imagine a wiki where people in the field comment on their models of
phones would be useful...

> 
> 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.
> 

Sure, the end result is mostly the same though, right?

I mean, I surely mentioned cryptophone previously, I thought. I don't
expect all things to be integrated but I do think that the overall feel
is pretty heavy for users who are non-technical.

> 
>>
>> "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.
> 

So, I think it's good to invert the pyramid, so to speak - what is
secure? Nothing? If nothing, say nothing. If something, set the default
to insecure and enumerate the things that are actually secure, how it is
secure and well, in what threat model it is secure?

> 
>>
>> "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.
> 
> 

Ah, well, I suppose that I understand that reasoning. Though my concern
here is that the risk doesn't change that much if the threat is a cruise
missile or a drone strike but it might for an artillery shelling.

>>
>> "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.
> 

Ok.

>>
>> 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.
> 
> 

This strikes me as a thing better represented as a graphic rather than
words.

>>
>> "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.
> 

Hrm, well, here you go:

http://gmr.osmocom.org/trac/wiki/Receiver_Setup
http://gmr.crypto.rub.de/
http://gmr.crypto.rub.de/paper/paper-1.pdf
http://gmr.crypto.rub.de/paper/paper-2.pdf
http://gmr.crypto.rub.de/ciphers/a5-gmr-1.tar.gz
http://gmr.crypto.rub.de/ciphers/a5-gmr-2.tar.gz

> 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.
> 

I'd invert this assumption as well - if they have the potential and the
capacity, why not simply assume it is happening? If you wait for proof,
as long as the spies don't give proof, you'll just keep waiting. Take
counter measures as if it were the case and you'll be safer.

> 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?)
> 

Well, I guess these guys are the GOTO guys for cell phones:
http://www.cellebrite.com/


I thought there may be good news as they don't appear to offer Thuraya
forensics yet:
http://www.cellebrite.com/component/search/?searchword=Thuraya&ordering=&searchphrase=all

But then I found this:
http://www.idealcorp.com/products/index.php?product=STRIKE
http://www.idealcorp.com/products/strike-docs/STRIKE_1-19_TechSpecs_RevA.pdf

"The System for TRIaging Key Evidence™ (STRIKE™) is an extremely fast,
accurate, and easy-to-use digital media exploitation kit."

And this:
http://www.cellebrite.com/ufed-phonelist/model_details.php?vendor=Satellite%20phones&model=all

Perhaps buy a copy of this and test?
http://www.cellebrite.com/mobile-forensics-products/forensics-products/ufed-ultimate.html

Anyway, I presume that one would read out every bit from the on board
flash and look at the data left around. Phones without full disk crypto
are probably leaving stuff around, even if they "securely delete" files
because of hardware wear leveling or other weird flash disk properties.

> 
>> "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?
> 
> 

Yeah, I think what I'm saying is - "everything is doomed, Thuraya is
doomed because of x, iSatphonePro Inmarsat is doomed because of y,
you're screwed in these ways...."

Now what you do when you know you're doomed? That's up to you but
hopefully with the facts on the table, it's just a matter of knowing the
truth and taking risks that you find understandable and acceptable.

>>
>> "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?
> 

Yes. I am now motivated to agree that more than 3 minutes is certainly
unsafe for a number of people. I bet people will consider themselves
exempt and ignore this because it seems so far fetched but I am
convinced now that your number is not just crazy hand waving. Also, I am
totally convinced that I don't want to use the phone for even one minute
after reading that. I highly encourage you to put that exact detail into
the guide! Also - perhaps don't forget to mention "now, get out of
here!" as the sign off as a usual security encouragement...

"Can you keep your call short? Rockets!"

I mean, I guess I'm joking but it sounds like it's not a very funny joke
because of the elements of truth involved.

>>
>> "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?
> 

HTTPS is HTTPS, email has nothing to do with it. You may read your email
over HTTPS but that's a web interface to email. And yes, HTTP may be
better but HTTPS has major problems too - people have been owning SSL
CAs left and right in public in the last few years.

In any case, if you use HTTPS to interface with email, it's not more
secure email, it's perhaps more secure when you read or compose it on
the web. But really, anything less than PGP/GnuPG is pretty much bad
news as far as the email while being sent through the net; it lacks
forward secrecy but hey, perhaps that's better than no secrecy at all...
YMMV?

> 
>>
>> "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??
> 

I mean, I haven't seen any evidence to suggest that satellite modems are
somehow better - most of the stuff with SIM cards seems to be identical
in terms of scary privacy violating stuff, bad crypto and sometimes no
crypto at all.

> 
>>
>> "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?
> 
> 

Well, I guess so. I think that this is like a suggestion of pulling out
rather than using a condom. It's tough to swallow but I suggest actual
protection to the degree that is possible while still allowing
engagement. ;-)

>>
>> 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?

Consider using it by paying anonymously, activating it for many regions
around the planet, having people post messages to the pagers with their
web interface using Tor, etc.

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

Well, try to take it constructively, I think it's positive feedback and
I generally think you're doing something positive here. :)

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

No worries.

> 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.
> 

I really think you should encourage people to use the cryptophone as the
gold standard or some kind of data terminal with secure VoIP like services.

All the best,
Jacob