loading...

Effective Communication Security / Beyond 'Use Signal Use Tor'

ondrejs profile image Ondrej Updated on ・3 min read

alt text

Effective Communication Security / Beyond 'Use Signal Use Tor'.

Devoted to people who live under oppressive regimes.

"The “tools first” brigade love to advance “use ${this}” as if whatever ${this} is will implement all sequences of the process for you. Then any tool which fails to address a real threat, or provide the appropriate protection, can be blamed for not addressing arbitrary threat models. This entire approach is backwards." Grugq

Key points:

Real problems associated with bad communication practices are usually on endpoints, not really in SW/apps/protocols. Keep in mind that bad implementation of technology is human problem.

Laptop - Do use ephemeral messaging apps as often as possible, which cannot be traced to your physical identity (e.g. Ricochet - https://ricochet.im). Another choice with good UX could be CoyIM (https://coy.im).

Mobile device - Do use Signal/Wire, prefer encrypted voicecalls over messaging or make sure you use self-destructing messages for all sensitive conversations. Do not use their Electron-based desktop versions (possibility of XSS attack vector but with the OS level access as a sweet bonus). Also realize that these apps are bound to your physical identity (to your phone number, e-mail or simply IP address), so you're not really pseudonymous/anonymous.

Rule of thumb - no logs, no crime. Avoid logs, even on the client side. Also this is one of reasons to avoid IRC for sharing sensitive info / organizing events.

Avoid proprietary messaging apps (e.g. Telegram, Messenger). Try to always use open-source software audited by professionals.

In general, a laptop is significantly less secure than an iOS device. Even a Pixel Android device (kept patched) is more secure than a laptop. If possible, use iPhone, always updated to newest iOS version. Do not jailbreak it. If use Android, do not root your device & do not enable developer mode. For both platforms - disable cloud backup. Require a password to unlock. If possible, register Signal/Wire with pre-paid SIM card.

Avoid private communication via e-mail at all costs, even via encrypted e-mail. Use communication channels listed above instead.

Enable two factor authentication (YubiKey, Google Auth., Duo, Authy) whenever possible.

If you want to present your ideas & future plans on any social media/event-sharing platforms (eg blog, Twitter feed), always use Tor (note: Tor does not mean extremely insecure Tor Browser).

Enable full HDD encryption. Encrypting only /home/ folder is often not enough in case your machine will be seized. Always turn off your PC/Mac after usage. Never store decryption keys on non-encrypted drives.

Consider using VeraCrypt containers for sensitive stuff (on top of full HDD encryption) because you could be forced to hand over your keys to authorities by court (This is especially relevant for citizens of Australia, Canada, France, Norway, Russia and United Kingdom).

Never ever contaminate your online activist identity with your real identity. Learn to compartmentalize.

What's wrong with Snowden's simple 'Use Signal Use Tor' statements ?

Well, you'd better use endpoint of your endpoint (i.e. your brain, my friend) in the first place. Consider your threat model and behave appropriately. Do not rely solely on technology. Majority of serious communication security problems are generated on endpoints (i.e. user's bad OPSEC practices).

Security is the holistic and never-ending process, not the final product (to quote Bruce Schneier).

Stay safe, my friend.

Posted on Dec 15 '18 by:

ondrejs profile

Ondrej

@ondrejs

Philosophy, maths & human rights focused technology

Discussion

markdown guide
 

Welcome to being a poster here :)

I do like the Grugq comment at the top - threat modelling sounds hard, so when it does get done it becomes the starting point for a lot of advice that then gets cargo culted by the tools brigade.

I would recommend having a go at it though, the Wikipedia page is a pretty decent introduction.

  • Identify who your threat actors are, at work we use the following classifications: Non-criminals ('script kiddies'), Lone criminals / insiders, Organised crime, State sponsored actors. These are IT focussed, yours may differ depending on your domain.
  • Identify assets at risk, this could be data assets, people (you!), systems (eg: emergency services).
  • Consider the motivations and capabilities of each actor towards each asset, estimate the impact (cost) of their successes, prioritise them.
  • Consider the attack vectors towards each asset, I like Bruce Schneier's Attack Trees method. Estimate 'cost' to the attacker and prioritise those routes that impact higher priority assets at lowest cost.

That's it - you have a threat model, now you can look at mitigations to the identified risks through controls against the attack vectors eg: telephone network failure impacting emergency services - provide an alternative communication system.

Typically a threat model for one of our products at work is a one-page document in confluence.

To follow up the Schneier quote about never-ending process: put a threat model review into your development lifecycle, they'll thank you in the end :)

 

Thanks for excellent comment, Phil! In fact I am little ashamed that I did not make this post more comprehensive and holistic, but even some basics are sometimes hard to grasp for ordinary people. Also thanks for notice on threat modelling, yes, one should definitely put a threat model review into the development lifecycle, and think about it at the first place. Maybe (if there'll be enough time), I'll write more comprehensive post later, but I am really not sure if whether it belong here, on forum focused primary on development.

 

gets cargo culted by the tools brigade

I have lived this. And I'm still trying to get myself dishonorably discharged from the tools brigade.

Gotta critique you on this, though:

Identify who your threat actors are, at work we use the following classifications

It's hard to get across how low, really low, the confidence should be in those identifications, which I've rarely seen based on much beyond past history, the results of garden variety monitoring tools, and intuition. I'm speaking from bitter personal experience here, and from my on and off reading of Hubbard and Seiersen.

 

Good point on how fuzzy/loose actor classification is - there is a vast array of motivations and personalities out there that this very crude slicing cannot reflect. I find it's a useful process to categorise your own assets though, asking 'who would be interested in this, and why'?

I have more recently started to consider if this 'outside -> in' approach is always appropriate, as there are other 'inside -> out' approaches that start with what we know about our own systems and their weaknesses, then consider if it's worth mitigating those, rather than the attackers view.

 

Did you use TOR to post this?

 

This is something on slightly different note, but could be useful for some people. Feel free to criticize me :)