
A Saudi Arabia Telecom's Surveillance Pitch (2013) - JoshTriplett
https://moxie.org/blog/saudi-surveillance/
======
drewcrawford
Shameless self-promotion, as this article is one of several that inspired me
to work on this.

I have been secretly working for several years on a drop-in iOS technology
based on the latest peer-reviewed crypto research, pinned certificates, PFS,
and implemented in a safe language that doesn't buffer overflow.

It's invitation-only right now but many customers are running it in
production. We have to position it as a performance technology (and it's very
very fast) since security doesn't make sales. But my personal goal is to Make
Things Dark Again™.

Unfortunately the hardest part of security work is funding it–performance and
business concerns drive a lot of the conversations which limit how much time
is left to work on making bulletproof transport security dead simple for app
developers. And it needs to be dead simple to get deployed in enough apps to
protect the average user from pervasive surveillance.

But if you believe in the problem, and your employer can create a budget for
the problem, I would love to chat with you (email in my profile). There is
still time to rewrite the future and keep totalitarian governments out of our
communication. We just have to decide we actually care enough to make it
happen.

~~~
Canada
How does your idea compare to noise protocol or QUIC?

~~~
drewcrawford
Noise is not really a protocol but a toolkit to build one. It's really a
symptom of the problem. We expect individual developers to take these tools
and figure it out, when they won't because they don't care enough. If by some
miracle they care they will probably screw it up unless they like reading
crypto papers. It also has various practical problems (e.g. the 64k message
limit) that you have to deal with some way, probably at the expense of
performance which is a useful vehicle to sell security technology, possibly at
the expense of security (e.g. early session termination).

QUIC is more interesting and I'm evaluating if we can deploy a modified form
of it into our transport layer. The key problem with QUIC alone is that in
practice many networks block UDP traffic, so you need a TCP fallback solution
so customers don't complain that every other app works except yours. But when
your threat model is "government compels certificates" then you can't fallback
to TLS. The government will just block UDP traffic at the router, downgrade
you to TLS, and now they've got you. This is one consequence of a larger
design issue: QUIC is trying to provide "equivalent" security to TLS, but if
your threat model is "something is wrong with TLS" that's not enough.

~~~
Canada
How about something like spiped?

~~~
drewcrawford
spiped is GREAT tech, and shares a lot of the same philosophy: small
implementation, simplified protocol, no negotiation, key pinning, etc. It is
really, really solid for the problem it solves.

However, it's designed around a simplified threat model. In spiped, you use
pre-shared keys (the same key on client and server), that "somehow" you got a
copy onto both systems without anyone seeing them. But you can't just drop
your key into a mobile app binary, submit to the app store, and expect people
not to reverse-engineer it and start reading other people's traffic. So now
you need to figure out how to derive spiped keys on a per-session basis in a
cryptographer-approved way™ and distribute them securely and verify the key
someone told you to use is not actually from the NSA, and then on top of that
think about perfect forward secrecy and certificate pinning and various other
"beyond TLS" guarantees.

There are solutions to all those problems, tarsnap ships really cool
solutions, but we are not talking about spiped anymore, we're talking about
spiped _and_ a long list of other things, and the other things are easy to get
wrong if your name is not cpervia.

Another practical problem with spiped is the performance degrades for small
messages. This doesn't matter if your use case is doing backups, but if your
use case is "I typed the letter 'c' in the search bar and where are my search
results? I thought this was supposed to be a performance technology" it
matters a LOT.

~~~
Canada
What about Axolotl, with the addition of the server signing a hash of the
master key with an ed25519 private key whose corresponding public key is
shipped with the app? Perhaps with a fixed 2 step "CA" trust path so each
individual server can have its own signing key.

The server would be authenticated to the client, but not vice versa. Clients
would have to provide some credential in band, but it could be bound to their
identity key after that so it shouldn't need to be done again even when
creating a new session (eg. fresh connection with different server)

If a server is compromised its signing and identity keys can be replaced. The
DH ratchet heals the compromised session keys, compensating for the lack of an
out of band key revocation mechanism. Sessions could be time bounded to
mitigate the damage of clients sending with compromised message keys in
between DH ratchets. Where that fails the server could reply with a message
disclosing the compromise, forcing DH, limiting the damage of continuing to
use the compromised hash ratchet.

For additional security clients could sign all their messages with their
identity key. If the server logged all of them, then it would be possible to
check after a server compromise that the attacker didn't forge anything.

You'd have to do something to break up big messages into chunks for UDP
transport. There's a BSD licensed ratchet implementation from Silent Circle.

------
Mao_Zedang
[https://en.wikipedia.org/wiki/United_Nations_Human_Rights_Co...](https://en.wikipedia.org/wiki/United_Nations_Human_Rights_Council#Saudi_Arabia)

The UN has always been a joke in my eyes because of this.

~~~
ZainRiz
"In January 2016, Saudi Arabia executed the prominent Shia cleric Sheikh Nimr
who had called for free elections in Saudi Arabia"

Sounds like a perfect candidate for the UN Human Rights Commission.

------
lifeisstillgood
A few things leap out

\- WhatsApp's TLS is insecure but twitters is ok? I assumed everyone would use
the same stack.

\- hang on - whatsapp now uses silent protocol right? Isn't it now really
secure and a billion people have it?

But apart from that, I am honestly burying my head over this stuff.

I have a job and family and tv to watch and now I have to "Understand a
complex moving environment and make sure I am secure whilst still providing my
family with access to Facebook and hang on that printer wants to send photos
to where!. I give up"

I think a set of good baseline practises would be good to start with. Begin by
flashing your commercial Router with openWRT or building a router with RPi and
then moving onwards. How can we live a connected life without polluting - it's
a hard problem and one I realise I need help with. Speak up though, I have
sand in my ears

------
therealasdf
What bothers me most is most Saudi's are aware that they are being monitored.
They assume if you have nothing to hide you shouldn't care for privacy.

~~~
tn13
Among the things that Saudis are aware but fine with, concern for telecom
privacy is at the bottom. :D

~~~
Eyght
It would be interesting to see how people feel about money vs. privacy. If the
choice was:

1\. Guaranteed employment for everyone, at middle class- or higher, living
standard. But with 100% surveillance of communications and movement.

2\. Privacy and democracy but with no guarantees of employment or living
standard.

~~~
tn13
For 1. We already have that model running in North Korea and I heard the
people love it absolutely.

For 2. We already have that model running in USA and I hear it is the absolute
worst place to live in.

------
jaryd
Please add 2013 to the title.

