A Saudi Arabia Telecom's Surveillance Pitch (2013)
moxie.org
moxie.org
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.
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.
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.
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.
FYI, spiped provides perfect forward secrecy by default. (But you can turn it off if you want to; short-circuiting the handshake this way makes it possible to perform about 1000x more handshakes per second.)
The UN has always been a joke in my eyes because of this.
Sounds like a perfect candidate for the UN Human Rights Commission.
- 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
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.
For 2. We already have that model running in USA and I hear it is the absolute worst place to live in.