"The NHS will last as long as there are folk left with the faith to fight for it"
Aneurin Bevan

Friday, 29 June 2012

Snooping

Channel 4 news are reporting a possible new form of government snooping.

The government want ISPs to collect and store all the emails that we send. (Actually, the government have said that they only want to know who is talking to who, not what they are talking about.) Email via SMTP/POP3 is typically unencrypted and is the equivalent of sending messages via postcards. (Actually, postcards have some security because only the postal workers who handle the postcard - and clearly the people in your house after the postcard comes through your letterbox - can read the message.) SMTP and POP3 can be delivered through  secure sockets layer (SSL), that is, the messages are encrypted before being sent. Web based email systems like GMail also use SSL. Channel 4 News are reporting that they want ISPs to devise a system to intercept and decrypt such encrypted emails. 


There are several technical issues why this is difficult, but to explain why I need to explain some basic cryptography. The most important aspect of encrypting messages is key-exchange, and this is carried out by asymmetric cryptography, which is asymmetric because it uses two keys. Clearly if there is asymmetric cryptography, there must also be symmetric encryption. Symmetric encryption uses one password (known as a key) to encrypt and decrypt data. It is fast and, as long as the key is large (key length is typically described as how many binary bits of data is used in the key), it is secure. The problem is that if I encrypt a message with my symmetric key and pass the message to you, you have to have my symmetric key to decrypt the message, and so I have to find some way to send you the key. 


Here rears the problem of the man-in-the-middle attack. If someone is listening to the conversation between me and you, they will be able to hear when I pass my symmetric key to you. Once the man-in-the-middle has my symmetric key, he can decrypt any messages I send to you.


This issue is solved by asymmetric cryptography (also known as public key cryptography). In this situation there are two related keys. Data encrypted by one key is decrypted by the other key. Both keys can encrypt and decrypt, but the point is that they can only decrypt what has been encrypted by the other. It is known as public key cryptography because typically one key is made public so that anyone will have access to it and can encrypt data that can only be decrypted by the other key in the pair (which is called the private key). If you have one key it is not possible to deduce the other key, and the two work in absolute pairs, you cannot use the private key from one key-pair to decrypt data encrypted by the public key of another pair.


The problem with asymmetric cryptography is that to be secure it has to use large keys and the algorithms are slow. It is not feasible to encrypt large amounts of data with asymmetric cryptography. However, symmetric keys are relatively small pieces of data (256 bits is just 32 bytes), and can be encrypted quickly with asymmetric key cryptography. So typically, asymmetric cryptography is used to encrypt symmetric keys during key exchange. 


Imagine I want to talk to you, and you have an asymmetric key pair and publish your public key. I can generate a symmetric key, encrypt it with your public key and send it to you. A man-in-the-middle can intercept the message but cannot decrypt it without your private key. When you get the message, you can decrypt it with your private key to get my symmetric key. Now the two of us, and only us, know the symmetric key which can be used to encrypt other messages between us. Since. This key is only used for this conversation, it is called a session key.




The man-in-the-middle can intercept these messages, but because he does not have the session key he cannot decrypt these messages, nor can he pretend to be me and send you messages, or pretend to be you and send me messages.




Secure sockets layer, used by websites that use the https protocol, works like this. The public key for a server is provided by an X.509 certificate. This is the vulnerable part of the process because a man-in-the-middle could intercept your request for my certificate (which contains your public key) and provide their own certificate (with their public key). If this happens then you will send the session key encrypted with the man-in-the-middle's public key, and hence the attacker can gain the session key. The man-in-the-middle can then ask me for my certificate and use my public key to encrypt the session key and pass this on to me. Now the three of us know the session key that will be used in the conversation and hence the man-in-the-middle can decrypt messages passing between us.


To prevent this attack X.509 certificates use a trust model. Basically there are a few well trusted certificate issuers (certificate authority). A certificate is "signed". Signing uses asymmetric key cryptography and in effect is a secure way of identifying an entity. When you get a signed certificate you can issue certificates yourself and sign them. When another user gets a certificate they check the signature to see who has issued the certificate and ask that certificate authority for their own certificate. If the user does not trust that certificate (because they cannot verify who they are) the user can look at the certificate of the certificate authority who issues their certificate. Thus there is essentially a chain of signed certificates. The user can traverse this chain until they either get to the first certificate authority who they do not trust (in which case they reject all the certificates in the chain) or find a certificate authority that they do trust. 


For this trust model to work it is important that certificate authorities only sign the certificates of people they know. It is possible that someone could forge a certificate, but for others to trust that certificate it has to be signed by a certificate authority. Trusted certificate authorities are trusted because they refuse to sign forgeries. 


The Channel 4 News articles suggests that the government will forge certificates of well known email servers (Gmail, Yahoo Mail, Hotmail, btinternet.com, Talk Talk etc) so that they can perform a man-in-the-middle attack. To do this they will have to use a trusted certificate. The problem is that the certificate authority will know that they are signing a forgery, and will be complicit in the forging process. Certificate authorities (Thwaite, Verisign, GoDaddy etc) are commercial businesses and they make money based on their customers and other users trusting them. If such an authority is found to be signing forgeries they will lose trust and lose huge amounts of money. So it is not likely that this attack will be performed using certificates that can be traced back to a commercial certificate authority. It is possible for the UK government to issue their own certificates, but if the UK government is known to be perpetrating man-in-the-middle attacks then people will simply reject any UK government issued certificate (or any certificate that can be traced to them).


Thus, I cannot see how the attack suggested by Channel 4 News can work.

2 comments:

  1. Hi,
    It is possible that someone could forge a certificate, but for others to trust that certificate it has to be signed by a certificate authority.Thanks

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete