Crypto Regulation, Part 2: Regulating transport encryption

This is part 2 of a series on the crypto regulations proposed by Cameron, Obama and others. Part 1, explaining what it is all about and describing different types of cryptography, can be found here.

The declared goal of crypto regulation is to be able to read every message passing through a country, regardless of who sent or received it and what technology they used. Regular readers probably know my feelings about such ideas, but let’s just assume that we are a member of David Camerons staff and are tasked with coming up with a plan on how to achieve this.1)

We have to keep in mind the two types of encryption we have previously talked about, transport and end-to-end encryption. I will discuss the problems associated with gaining access to communication secured by the respective technologies, and possible alternatives to regulating cryptography. Afterwards, I will look at the technological solution that could be used to implement the regulation of cryptography. This part will be about transport encryption, while the next part will deal with end-to-end encryption.

Regulating transport encryption

As a rule, transport encryption is easier to regulate, as the number of parties you have to involve is much lower. For instance, if you are interested in gaining access to the transport-encrypted communication of all Google Mail users, you only have to talk to Google, and not to each individual user.

For most of these companies, it probably wouldn’t even be necessary to regulate the cryptography itself, they could just be (and are) required to hand over information to law enforcement agencies. These laws could, if necessary, be expanded to include PRISM-like full access to the data stored on the servers (assuming this is not already common practice). Assuming that our goal really only is to gain access to the communication content and metadata, this should be enough to satisfy the needs of law enforcement.

Access to the actual information while it is encrypted and flowing through the internet is only required if we are interested in more than the data stored on the servers of the companies. An example would be the passwords used to log into a service, which are transmitted in an encrypted form over the internet. These passwords are usually not stored in plain text on the company servers. Instead, they store a so-called hash of the password which is easy to generate from the password but makes it almost impossible to restore the password from the information stored in the hash.2) However, if we were able to decrypt the password while it is sent over the internet, we would gain access to the account and could perform actions ourselves (e.g. send messages). More importantly, we could also use that password to attempt to log into other accounts of the suspect, potentially gaining access to more accounts with non-cooperating (foreign) companies or private servers.

Regulation techniques

So, assuming we want that kind of access to the communication, we’re back to the topic of regulating transport encryption. The different ways this access could be ensured are, in rising order of practicality:

Let’s take a look at each of these proposals, their merits and their disadvantages.

Outlawing cryptography

Outlawing cryptography has the advantage of simplicity. There is no overhead of backdooring implementations, implementing key escrow, or performing active attacks. However, that is just about the only advantage of this proposal.

Cryptography is fundamental to the way our society works, and the modern information age would not be possible without it. You are using cryptography every day: when you get your mail, when you log into a website, when you purchase stuff online, even on this very website, your connection is encrypted.

It gets even worse for companies. They rely on their information being encrypted when communicating with other companies or their customers, otherwise their trade secrets would be free to be taken. Banks would have to cease offering online banking. Amazon would probably go out of business. Internet crime would skyrocket as people would hijack unprotected accounts, steal private and corporate information.

So, given the resistance any such proposition would face, outlawing cryptography as a whole isn’t really an option. An alternative would be to just outlaw it for individuals, but not for corporations. That way, the banks could continue offering online banking, but individuals would no longer be allowed to encrypt their private information.

Such a law would technically be possible, but would raise a lot of problems in practise. Aside from being impossible to enforce, some existing programs can only save their data in an encrypted form (e.g. banking applications). Some people have devices they use both privately and for their job, and their employer may require them to encrypt the device. There are a lot of special cases that would cause problems in the actual implementation of this law, not to mention the possible damage caused from criminals gaining access to unencrypted private information. There would definitely be a lot of opposition to such a law, and the end result would be hard to predict.

Mandating the use of weak or backdoored algorithms

In this case, some party would come up with a list of ciphers which are considered secure enough against common “cyber criminals”, while offering no significant resistance to law enforcement or intelligence agencies. This could be achieved,  either through raw computational power (limiting the size of encryption keys to a level where all possibilities can be tried out in a reasonable timeframe, given the computational ressources available to law enforcement / intelligence agencies), or through the introduction of a backdoor in the algorithm.

In cryptography, a backdoor could be anything from encrypting the data with a second key, owned by the government, to make sure that they can also listen in, to using weak random numbers for the generation of cryptographic keys, which would allow anyone knowing the exact weakness to recover the keys much more quickly. This has, appearently, already happened: It is suspected (and has pretty much been proven) that the NSA introduced backdoors into the Dual EC DRBG random number generator and it is alleged that they paid off a big company (RSA) to then make this algorithm their standard random number generator in their commercial software.

The problem with backdoors is that once they are discovered, anyone can use them. For example, if we mandated that everyone use Dual EC DRBG random numbers for their cryptographic functions, not only we, but also the NSA could decrypt the data much more easily. If we encrypt everything to a second key, then anyone in posession of that key could use it to decrypt the data, which would make the storage location of the key a very attractive target for foreign spies and malicious hackers. So, unless we want to make the whole system insecure to potentially anyone and not just us, backdooring the cryptography is a bad idea.

The other option we mentioned was limiting the size of cryptographic keys. For example, we could mandate that certain important keys may only use key sizes of up to 768 bits, which can be cracked within a reasonable timeframe using sufficient computing power. But, once again, we encounter the same problem: If we can crack the key, other organizations with comparable power (NSA, KGB, the chinese Ministry of State Security, …) can do the same.

Also, because the computational power of computers is still increasing every year, it may be that in a few years, a dedicated individual / small group could also break encryption with that key length. This could prove disastrous if data that may still be valuable a decade later is encrypted with keys of that strength, e.g. trade secrets or long-term plans. Competitors would just have to get a hold of the encrypted data and wait for technology to reach a point where it becomes affordable to break the encryption.

So, mandating the use of weak or backdoored cryptography would make everyone less secure against intelligence agencies and quite possibly even against regular criminals or corporate espionage. In that light, this form of regulation probably involves too much risk for too little reward (cracking these keys still takes some time, so it cannot really be done at a large scale).

Performing a Man-in-the-Middle-Attack on all / select connections

A man-in-the-middle (MitM)-Attack occurs when one party (commonly called Alice) wants to talk to another party (Bob), but the communication is intercepted by someone else (Mallory), who then modifies the data in transit. Usually, this involves replacing transmitted encryption keys with others in order to be able to decrypt the data and re-encrypt it before sending it on to the destination (the Wikipedia article has a good explanation). This attack is usually prevented by authenticating the data. There are different techniques for that, but most of the actual communication between human beings (e.g. eMail transfer, logins into websites, …) is protected using SSL/TLS, which uses a model involving Certification Authorities (CAs).

In the CA model, there are a bunch of organizations who are trusted to verify the identity of people and organizations. You can apply for a digital certificate, which confirms that a certain encryption key belongs to a certain website or individual. They are then supposed to verify that you are, in fact, the owner of said website, and issue you a certificate file that states “We, the certification authority xyz, confirm that the cryptographic key abc belongs to the website blog.velcommuta.de”. Using that file and the encryption key, you can then offer web browsers a way to (more or less) securely access your website via SSL/TLS. The server will send its encryption key and the certificate, confirming that this key is authentic, to clients, who can then use that key to communicate with the server.3)

The problem is that every certification authority is trusted to issue certificates for every website, and no one can prevent them from issuing a false certificate (e.g. confirming that key def is a valid key for my website). A man-in-the-middle could then use such a certificate to hijack a connection, replace my cryptographic key with their own and listen in on the communication.

Now, in order to get into every (or at least every interesting) stream of communication, we would need two things:

  • A certification authority that is willing (or can be forced) to give us certificates for any site we want
  • The cooperation (again, voluntary or forced) of internet providers to perform the attack for us

Both of these things can be written into law and passed, and we would have a way to listen in on every connection protected by this protocol. However, there are a few problems with that idea.

One problem is that not all connections use the CA model, so we would need to find a way to attack other protocols as well. These protocols are mostly unimportant for large-scale communication like eMail, but become interesting if we want to gain access to specialized services or specific servers.

The second problem is that some applications do additional checks on the certificates. They can either make sure that the certificate comes from a specific certification authority, or they could even make sure that it is a specific certificate (a process called Certificate Pinning4)). Those programs would stop working if we started intercepting their traffic.

The third problem is that it creates a third point at which connections can be attacked by criminals and foreign intelligence agencies. Usually, they would have to attack either the source or the destination of a connection in order to gain access to the communication. Attacking the source is usually hard, as that would be your laptop, and there are an awful lot of personal computers which you would have to attack in order to gain full access to all communication that way.

Attacking the destination is also hard, because those are usually servers run by professional companies who (hopefully) have good security measures in place to prevent those attacks. It is probably still possible to find a way in if you invest enough effort, but it is hard to do at scale.

However, if you introduce a few centralized points at which all communication flowing through the network of an internet operator is decrypted and re-encrypted, you also create one big, juicy target, because you can read all of those connections by compromising one server (or at least a much smaller number of servers than otherwise). And experience has shown that for juicy targets like that, intelligence agencies are willing to invest a lot of effort.

So, performing MitM-Attacks on all connections would not work for all types of connections, it would not work for all devices, and it would create attractive targets for hostile agencies to gain access to a large percentage of formerly secured traffic. That does not seem like a good trade to me, so let’s keep looking for alternatives.

Key escrow

Key escrow (sometimes called a “fair” cryptosystem by proponents and key surrender by opponents) is the practise of keeping the cryptographic keys needed to decrypt data in a repository where certain parties (in our case law enforcement agencies) may gain access to them under certain circumstances.

The main problem in this case is finding an arrangement where the keys are stored in a way that lets only authorized parties access them. Assuming we want to continue following a system with judicial oversight, that would probably mean that the escrow system could only be accessed with a warrant / court order. It is hard to enforce this using technology alone, and systems involving humans are prone to abuse and mistakes. However, with a system as security critical as a repository for cryptographic keys, any mistake could prove costly, both in a figurative and a literal sense.

Then there is the problem of setting the system up. Do you want a central European repository? A central repository for each country? Will every server operator be required to run escrow software on their own server? Each of these options has its own advantages and drawbacks.

  • A European repository would mean less administrative effort overall, but it would create a single point of failure, which, when compromised, would impact the internet security of the whole EU. As with the issue of man-in-the-middle attack devices, history has shown that foreign agencies can and will go to a lot of effort to compromise such repositories. A central European repository would also assume that European countries do not spy on each other, which is a naive assumption.
  • Country-wide repositories fix the last problem, but still suffer from the others. They are attractive targets for both foreign intelligence agencies and cybercriminals.
  • Individual repositories face the problem of compatibility (there are a LOT of different operating systems and -versions running on servers). They are less centralized, which is good (the effort to break into them increases)5), but they also imply that law enforcement would have to be able to electronically retrieve the key on demand. If someone knew that the police was onto him, he could thus disable the software or even destroy the key and server in order to prevent the police from retroactively decrypting potential evidence they had already captured.

Again, we have encountered administrative problems and important security aspects that make this option problematic at best. So, why don’t we take a look at how things are done right now in great britain and see if it made  sense to at least expand this law into the rest of Europe.

Key disclosure laws
Key disclosure in practise
Key disclosure in practise (Image: “Security” by Randall Munroe, Licensed CC BY-NC 2.5)

The british Regulation of Investigatory Powers Act of 2000 (short: RIPA) includes a provision requiring suspects in a crime to hand over encryption keys or face jail time of up to two years (or up to five in cases of terrorism or suspected child pornography).6) The law has already been used to imprison at least three people for refusing to give up encryption keys.

However, all members of the European council have ratified the European Convention on Human Rights. While it is not specifically mentioned, the European court of human rights holds that

…the right to remain silent under police questioning and the privilege against self-incrimination are generally recognized international standards which lie at the heart of the notion of a fair procedure under Article 6 [of the European Convention on Human Rights].

Requiring an individual to surrender keys would probably be in violation of the right to remain silent (although there are different opinions on that). Any such law would almost certainly be annulled by the Court of Justice of the European Union, as it did with the Data Retention Directive.

However, such a law could conceivably be used to compel companies or witnesses to disclose encryption keys they have access to. These laws exist in some European countries, and could be expanded to all of Europe. It would remain to be seen what the European Court of Justice would think of that, as such a law would definitely be challenged, but the potential of a law being annulled by the ECJ has not prevented the European parliament from passing them in the past.

There exists another, more technical concern with this: More and more websites employ cryptographic techniques that ensure a property called (perfect) forward secrecy, short (P)FS. This ensures that even if an encrypted conversation is eavesdropped on and recorded, and even if the encryption keys are surrendered to law enforcement afterwards (or stolen by criminals), they will be unable to decrypt the conversation. The only way to eavesdrop on this kind of communication is to perform an active man-in-the-middle-attack while in possession of a valid key.

This means that even if law enforcement has a recording of evidence while it was being transmitted, and even if they could force someone to give them the relevant keys, they would still be unable to gain access to said evidence. This technology is slowly becoming the standard, and the percentage of connections protected by it will only grow, meaning that laws requiring the disclosure of keys after the communication has taken place will become less and less useful over the next years.

Conclusion

We have taken a look at five different proposals for regulating transport security, and have found that each is either extremely harmful to the security of the European internet or ineffective at providing access to encrypted communication. Each of the proposals also holds an enormous potential for abuse from governments and intelligence services.

This concludes part 2 of my series on crypto regulation. Part 3 is discussing possible ways to regulate end-to-end cryptography.


As before, thanks go out to niemalsnever, FreeFall and DanielAW for proofreading and suggestions. Any remaining mistakes are my own.

Flattr this

Footnotes

Footnotes
1 I’m playing “Devil’s system engineer” here and am obviously completely opposed to any of the measures I describe in this article, in case there was any doubt.
2 Again, this is a simplification. In the real world, there are important considerations, including the choice of the proper hash function and salting of the passwords, but that is out of the scope of this article.
3 As always, I am simplifying matters here, but the exact inner workings of TLS are not relevant to this article.
4 There is a Firefox extension that does that
5 …assuming the key escrow software does not have a security hole itself, which is an optimistic assumption in itself.
6 Distressingly, it does not even distinguish between willingly not giving up the key and being unable to give up a key. This means that if the police thinks something is encrypted, and it is not, you can be sent to jail for refusing to give up a key to decrypt imaginary encrypted data.

2 thoughts on “Crypto Regulation, Part 2: Regulating transport encryption

  1. Nice article, although I think you could have emphasized the fact that backdoored algorithms already exist a little more, instead of putting it in a footnote, especially since in the next paragraph you assume that the reader has in fact read the footnote.

    Certificate Patrol seems like it could be a useful addon, but the comment about it possibly downgrading TLS connections kind of deters me from trying it out…

    1. Good point about the backdoored algorithms, I moved that sentence from the footnote to a regular sentence in the article.

      Regarding Certificate Patrol: I have not experienced any problems with it (and I continue to negotiate good ciphers every time I check manually). The only bad thing about it is that some sites (looking at you, Twitter) have different server farms using different certs from different CAs, resulting in frequent warnings when I use their website. But that’s hardly the fault of the addon.

Comments are closed.