Friday, 6 September 2013

Cracked crypto?

Interesting article in the Guardian.

Of course, anyone involved in any news story will have some idea of the quality and accuracy of reporting, and even if the reporting is accurate, there is no doubt some usefulness in these agencies spreading FUD (Fear, Uncertainty and Doubt) by saying they can crack stuff that they cannot.

Ultimately any security system is crackable, what matters is whether that takes micro seconds (and so is done on every message monitored) or takes until the sun burns out, or somewhere between. The key to any security is ensuring data stays secure long enough not to matter, or in a way that it is not worth the effort and cost of cracking it.

The claims in the article are quite varied...

At one point it is claims they have worked to have control over setting of international encryption standards. This would suggest that they have influenced the actual standards used in a way to dumb them down in some way to make them easier to crack. My understanding is that this did happen in the design of GSM encryption where, at a late stage, changes were made at the insistence of governments to dumb down some of the protocols. However, open standards would be very difficult to dumb down like this - they are designed in an open and public forum.

Then they talk of the use of supercomputers to break encryption with "brute force". This seems unlikely, and is where the cost of breaking a message is high, so has to be very targeted. In practice you can't just brute force encryption, but anything with a user chosen password can be, as people are stupid when it comes to picking passwords. Again, this would be somewhat targeted.

Then they talk of the most closely guarded secret of all – collaboration with technology companies and internet service providers themselves. This is not entirely clear. Obviously encryption is end to end, and so if you access a secure web site, anyone working with the site owner can access everything without cracking any encryption. I am not sure how working with ISPs fits. If you are using end to end email encryption then this will have no effect.

And finally: Through these covert partnerships, the agencies have inserted secret vulnerabilities – known as backdoors or trapdoors – into commercial encryption software. This is interesting. The key word here is "commercial". There are lots of non-commercial, open-source, widely checked and validated systems for encryption and you use them every day. The most popular web servers in the world are apache based, which is open source. One of the key email encryption systems is PGP which is still available open source (GPG). Open source means that anyone can see every line of the source code, and can see any back doors that have been added - there are a lot of very smart people all over the world that make a point of checking this stuff.

What they seem to miss in the article is one simple thing that is widely believed to be happening. The provision of certificate authority keys to the NSA, GCHQ, etc. This allows man-in-the-middle attacks on https without warnings on your browser as they can create valid certificates for their interception systems on the fly and decrypt your traffic just as the endpoint could. This is risky to use as it is something that could be detected.

There is one final point which is rather odd. GCHQ team has been working to develop ways into encrypted traffic on the "big four" service providers, named as Hotmail, Google, Yahoo and Facebook. This basically makes no sense. These are web based services that use https. For any form of legal interception they simply need to work with those companies, via their hosting governments, to request the data from them. They do not need to decrypt anything.

The real messages here are, use open source software, you have to trust the endpoint, use GPG to send encrypted emails wherever possible so that it is normal and not a sign of "hiding something".


  1. much the same as the advice given for gmail users after the google comment "you cant expect privacy if you're using 3rd party providers"

    gpg up your block of text and send that

    Like you say revk ... make the use of privacy tools the norm

  2. I presume they don't give a rats backside about "Legal" interception and are instead interested in getting at the data quickly and most likely without anyone knowing they're doing it.

    As you say Bruteforcing the encryption probably isn't that effective, probably easier to bruteforce the password that generates the key.

  3. There is still (a stronger) likely hood that any SSL certificate provider doing business within the USA has been served with a subpoena to provide root certificate private keys

    Still leaks so far talk about "delayed" monitoring (like the 30 mins buffer at GCHQ). Having root certificate key, in my understanding would only help man in the middle attack... but of course nothing prevent to have man in the middle proxying, store unencrypted traffic for later analysis.

    So ideally protect your site with self-signed certificate, or alternatively with non-US top level (not sure if there are that many without any business in the US...)

    1. It does seem quite likely that various governments have access to the root CA keys. However, there are serious limitations with what you can do with them: you can use them to forge a certificate, and therefore do MITM attacks. You *can't* use them for an offline attack (i.e. you're going to have to intercept and modify all the traffic in real time, rather than just capturing it for later analysis. That makes the ISP-side infrastructure needed to support the NSA much more complex). Also, the real certificate and the forged certificate are different, which means that its possible to compare them and spot that they are different - this means that whilst I don't doubt that they could intercept the traffic for a specific suspect and decrypt it, using a dragnet approach on all traffic is likely to be spotted quickly and the offending CA keys rapidly revoked from all the browsers.

      And this brings us onto another issue - any CA that is caught leaking keys is basically doomed. They would instantly be revoked from everywhere and the CA would never be trusted again and would rapidly go out of business. So I would assume that CAs would only agree to this when they hare leaned on extremely heavily, and the governments who are leaning on them would need to take every precaution to ensure they don't get caught.

    2. I was under the impression that the root signing keys were stored only in specially designed hardware devices that provide no access to the key at all and can only be used to sign things. And which take extensive precautions to prevent access to the keys. These devices are used for less important things such as signing bacs transfer requests so I would expect them to be used for this.

      So they couldn't reveal the keys even if they wanted to.
      Of course that just moves the trust around. You have to trust they are using these devices, and that the devices are properly secure with no backdoors...

  4. Open source software is not entirely safe. You missed one avenue mentioned, the incorporation of intentional flaws into *standards*. Schneier (who's been working on this, and who can probably be trusted if anyone can) has suggested perhaps avoiding forms of cryptography that involve large tables of constants, such as elliptic curve crypto: the NSA and/or NIST (for which read "the NSA") has oftwen been involved in the selection of these constants, and the leaks suggest that they may have picked constants with subtle flaws.

  5. Stuxnet and its ilk have now used, I think, two "stolen" code-signing certificates. A private team managed to factorise a 768 bit composite (RSA-768) four years ago, so it wouldn't surprise me at all if the NSA had done that for a couple of code-signing certificates quite easily.

    Man-in-the-middle with your own certificate is likely to be too obvious though: after a few attempts at that, the likes of Firefox have options to detect exactly that sort of tampering and alert the user.

    Brute-forcing for individual messages wouldn't make sense unless they have a major advantage over known approaches - which, of course, isn't impossible: remember they had RSA 4 years before anyone else knew about it, not to mention knowing about differential cryptanalysis decades before the public. Could they have some factorisation shortcut? Not at all impossible, and it might be an explanation for the NSA's rather bizarre hamfisted attempt to sabotage the elliptic-curve PRNG recently - not an effort to get people using that algorithm, but to make them use the others...

  6. Ahh, if only AAISP would encrypt their billing communications to me....

    1. Actually, I think that is an option. We can encrypt if we load your PGP key. We already sign.

    2. Is that a will do? :-) - give me somewhere to upload my key :-)

    3. That is a catch me on irc in the morning on a work day and I'll look in to it. I am 99% sure we have a system for that in place and I can take you key subject to whatever checking is sensible.

    4. Do you do TLS on the outbound mail delivery, too? (I see you accept it inbound, though there seems to be a certificate mismatch for on, and won't speak TLS.) That's one where a lot of mail providers seem to fall down right now.