Or, how any encryption apps you use may already be backdoored. Because, hey, that’s how these things tend to go.
In short, there are a lot of surprisingly easy ways to make encryption fundamentally broken even if it looks secure at first glance.
You can decrypt the data as it passes over the server. You can make yourself be in charge of key distribution, and then give out bad keys. You can say screw decryption entirely and just concentrate on metadata analysis — for many purposes, this is good enough.
You can use “key escrow” backdoor schemes. Or you can just push out backdoor code as part of an automatic update… or an “unofficial update” using a zero-day hole in the software you happen to know about.
And things get even simpler, in many respects, if you have some degree of serious cryptanalytic capability… it’s absurdly easy to introduce minor flaws into cryptographic implementations that only a cryptographer, tearing apart the source code, is likely to find. (And if they do, you can call it an honest mistake.)
PRISMatics: A while back I noted something about the entire Eastern Seaboard pulling an Atlantis if climate change keeps churning. It seems one reason PRISM etc exists is to control everyone inside the country and keep them from upending the government when it becomes clear that, well, loving your neighbor and being responsible for yourself works better than drone signature strikes. http://m.guardian.co.uk/environment/earth-insight/2013/jun/14/climate-change-energy-shocks-nsa-prism
Also, one more reason to design systems that don’t make lots of data accessible to random prying eyes: “”This is a little bit of an awakening to the government, that you can’t hold massive amounts of personal data with impunity,” he said. “Once you do, a lot of obligations and responsibilities kick in. One of the consequences of keeping data is that now you open yourself up to discovery.”” http://redtape.nbcnews.com/_news/2013/06/20/19061109-lawyers-eye-nsa-data-as-treasure-trove-for-evidence-in-murder-divorce-cases?lite
1. Don’t use end-to-end encryption in the first place (just say you do.)
There’s no need to kick down the door when you already have the keys. Similarly there’s no reason to add a ‘backdoor’ when you already have the plaintext. Unfortunately this is the case for a shocking number of popular chat systems — ranging from Google Talk (er, ‘Hangouts’) to your typical commercial Voice-over-IP system. The same statement also applies to at least some components of more robust systems: for example, Skype text messages.[…]
2. Own the directory service (or be the Certificate Authority).
Fortunately an increasing number of applications really do encrypt voice and text messages end-to-end — meaning that the data is encrypted all the way from sender directly to the recipient. This cuts the service out of the equation (mostly), which is nice. But unfortunately it’s only half the story.
The problem here is that encrypting things is generally the easy bit. The hard part is distributing the keys (key signing parties anyone?) Many ‘end-to-end’ systems — notably Skype*, Apple’s iMessage and Wickr — try to make your life easier by providing a convenient ‘key lookup service’, or else by acting as trusted certificate authorities to sign your keys. Some will even store your secret keys.**
This certainly does make life easier, both for you and the company, should it decide to eavesdrop on you. Since the service controls the key, it can just as easily send you its own public key — or a public key belonging to the FBI. This approach makes it ridiculously easy for providers to run a Man-in-the-Middle attack (MITM) and intercept any data they want[…]
3. Metadata is the new data.
[…]But you don’t need to attack the software to get useful information out of them. That’s because while encryption may hide what you say, it doesn’t necessarily hide who you’re talking to.[…]
4. Escrow your keys.
[…]f you want to add real eavesdropping backdoors to a properly-designed encryption protocol you have to take things to a whole different level. Generally this requires that you modify the encryption software itself.
If you’re doing this above board you’d refer to it as ‘key escrow’. A simple technique is just to an extra field to the wire protocol. Each time your clients agree on a session key, you have one of the parties encrypt that key under the public key of a third party (say, the encryption service, or a law enforcement agency). The encrypted key gets shipped along with the rest of the handshake data. […]
5. Compromise, Update, Exflitrate.
But what if your software doesn’t have escrow functionality? Then it’s time to change the software.
The simplest way to add an eavesdropping function is just to issue a software update. Ship a trustworthy client, ask your users to enable automatic updates, then deliver a new version when you need to. This gets even easier now that some operating systems are adding automatic background app updates.”