Access to communications data by the intelligence and security Agencies

Have a look at this flow chart. It’s taken from the Intelligence and Security Committee’s report on the Communications Bill, and “illustrates how the elements of the Bill would work in practice.” It is UK democracy at work.

It starts with the authorities deciding that certain data is wanted. If the service provider objects, see how he has the right to appeal. If he accepts the request, he gets a notice to retain the required data. If he rejects the request, he gets a notice to retain the required data. If he still objects, it might go to court. If he wins the case, “HMG negotiates and serves a notice on a different Service Provider to collect and retain some or all of the required data using Deep Packet Inspection (DPI) or similar techniques.” In other words, they chose a different ISP and start all over again. That’s pure democracy: keep asking the question until you get the answer you want.

Of course, it’s not the only worrying thing about the Access to communications data by the intelligence and security Agencies report. My primary concern is that it is not an investigation into the Communications Bill at all. It is really a libation to the Bill. Its only criticism is that the government should have done a better job at selling the Bill to the population. But having said that, the Committee still tries to obfuscate and mislead.

Consider the section on ‘encryption’. It is heavily redacted (another example of modern democracy: ‘don’t tell the plebs what we’re doing’). It effectively says little more than

From the encryption section of the report

Makes you wonder, doesn’t it. What are those ‘options’? And what does it mean for the service provider to provide an unencrypted version of encrypted communications data?

I asked two interested experts to explain the issue for me – and rather than try to comment on their replies, I’m reproducing them in full.

James Firth, CEO of the Open Digital Policy Organisation Ltd

The problem arises because communications can be – effectively – layered. So a portion of ‘content’ at one (higher) layer is actually communications data at a lower layer.

A classic example is webmail. Alice logs in to mail service provider G via secure HTTPS and sends a message to Bob. All her ISP knows is that Alice has a web session with G.

Various proposals being touted – sometimes in the various drafts – include forcing mail service providers to abide by the Comms Bill. Jurisdiction could be enforced in some way for any company with a UK presence, but it would be impractical as the Bad Guys would just use other companies.

But there have been scarier options touted.

If Alice didn’t use a secure method to connect to her mail service provider her ISP could be forced to scan all CONTENT in order to detect nested communications data. In this model her ISP would scrape the email “to” and “from” fields from her web session. I doubt this would pass muster with various EU Directives but that’s been suggested.

Even scarier suggestion – if Alice DID use SSL to connect to her mail service provider it has been suggested – I have a very good contact confirming this – that legislation could be introduced to force her ISP to store the whole encrypted transaction, even though this includes the content.

The idea being that HMG could get a court order – here or in e.g. the US – at a later date to force her mail service provider to disclose their private SSL key. From that it would – in *some cases* – be possible to replay the SSL transaction to discover the session key and decrypt the contents, then extract the communications data, and – honest guv – ignore any content.

The major flaw in this plan is that Google, as one mail service provider, has rolled-out a feature called forward secrecy (http://en.wikipedia.org/wiki/Perfect_forward_secrecy).

Forward secrecy introduces, essentially, a second negotiated secret into the SSL transaction; a secret known only by the client web browser. The protracted SSL handshake with forward secrecy ensures that if one private key was later compromised – e.g. the mail service provider’s key – an attacker would still not be able to reproduce the plaintext from a captured encrypted session.

Clever mail service providers would never want to be in a position where they are forced by a court to hand over their private keys, so forward secrecy is actually in their interests as it devalues their private key as it won’t alone decrypt a captured session. In fact the second secret needed to decrypt a session with perfect forward secrecy should have been destroyed by the client and the server as soon as the session ends.

Alexander Hanff, managing director at Think Privacy Ltd

When an SSL connection is made a ‘tunnel’ is set up and as a result all of the HTTP headers are encrypted (these include the specific web page you are requesting from the server) but the TCP and IP data is not encrypted as they exist on different OSI layers – HTTP/SSL exist in layers 5-7 whereas TCP is layer 4 and IP is layer 3 (if my memory serves me correctly you might want to double-check that).

As you correctly state, it would be impossible to get the encrypted content to the server if the 3rd and 4th OSI layers were encrypted, so yes there is still a DNS lookup (which means the ISP knows the domain and the IP address you are trying to communicate with) but they would not know which web page you are trying to access within that domain.

The same should be true of emails which are not hosted by the ISP (for example I run my own email servers) they would know which email server I am trying to communicate with but since my emails are transported over SSL/TLS the would not know whom I am communicating with or anything else which is held within the encrypted packets (I run my own email servers to circumvent the Data Retention aspects of RIPA/Data Retention Directive).

That said, the ISP could easily set up Man in the Middle attacks similar to how Phorm did with their DPI boxes which would allow them to decrypt everything (including the content) which is what I presume was the redacted content in the report released yesterday when they were talking about the government has a feasible method of dealing with encryption. This of course would be completely illegal under RIPA (without a warrant) so they would need to introduce legislation to do this (which would put them in breach of the EU Data Retention Directive but as we know the UK gov are not good at complying with EU Directives so they probably wouldn’t care).

So in summary, yes encryption restricts them from obtaining some of the higher level data they want but not the low-level data such as domain and IP.

Notice that there is one common element in these two replies: further legislation. It seems highly likely, then, that this Communications Bill will be supplemented by altogether more intrusive legislation (the ‘options’) when the authorities finally realise what everyone has been telling them: this Communications Bill isn’t what they say and will not work. And that, of course, is democracy at work: keep asking the question until you get the response you want.

The Data Protection Regulation should be amended to force companies to disclose how passwords are stored

Over the last couple of days it has been disclosed that an amazing amount of personal data on 1.1 million Americans has been lifted from the US Nationwide insurance group. Passwords do not appear to be involved – it’s a storage of data rather than an interactive site. But the point is that this data would appear to have been unencrypted – at least the company concerned hasn’t specified one way or the other; and that’s the problem.

Time and again we learn of plaintext passwords being stolen. Plaintext is unacceptable, but it happens. Sometimes, they are stored hashed by SHA1. This is unacceptable because dictionary attacks and Jens Steube’s newly announced brute force attack makes them surprisingly vulnerable; but it happens. At the very least, passwords should be stored hashed with SHA1 – preferably better – and salted.

I for one would be reluctant to commit my password to any site that stores that password with anything less than salted SHA2. But they don’t tell us, do they.

So I call now for the European Commission to amend the proposed Data Protection Regulation to include a requirement for all sites that store user passwords to make it clear on their site, at registration, precisely how those passwords are stored: plaintext, hashed (with what), or hashed and salted. This is the only way we will be able to force vendors to improve the way in which they handle our data.

See also: Storing passwords: why you should flavour your hash with salt

Is it safe to carry on using Dropbox? Yes and No: Part II

Ever since the news of a potential breach at Dropbox emerged, my old post “Is it safe to carry on using Dropbox?” has been getting an elevated number of hits. It is time perhaps to update.

Firstly, what’s this about a breach? Well, Dropbox wasn’t breached in the traditional sense of the word. The likelihood is that a number of Dropbox users had the same log-in credentials (email address and password) that they used on a different web account that was breached. The criminals were able to reuse the credentials stolen from elsewhere, and gain access to a number of Dropbox accounts.

Unfortunately, one of these accounts belonged to a Dropbox employee. The criminals gained access to his account and found a file containing an unknown number of users’ email addresses. It was probably these users that were subsequently spammed, leading to the suggestion that Dropbox had been hacked.

This leaves us two questions: is Dropbox safe to use; and what lessons should we learn?

Dropbox is no more nor less safe than it was before; that is, it is not safe. This for two reasons: firstly, it is in the cloud; and secondly, Dropbox is a US company. You don’t know what is happening in a cloud that is not your own; so it is not safe. Dropbox is registered in the US, and is subject to the PATRIOT Act – the US authorities are able to demand details of you and your account simply because they want them. So Dropbox is just not safe for confidential or incriminating content (and nor, note, is any other US-based cloud company).

But why worry if the data you store is neither of these? You can increase the level of security by locally encrypting the files (with something like TrueCrypt) and storing only encrypted files. The basic rule is simple: if it is important that nobody else ever sees the data, don’t use Dropbox; if it doesn’t matter if other people see your files, you can use Dropbox. If you’re somewhere in-between, encrypt.

What should we learn from this? Well, it is good that Dropbox has or will be initiating additional security – including two-factor authentication. This will make your data more safe from hackers, but it has no effect on law enforcement intrusion. And judging from Google’s 2FA, few people will bother using it.

I also very much like the new security page (partial screenshot below). It’s available at your Dropbox settings location, and shows who has recently accessed your account and who is currently accessing your account. This is certainly worth checking regularly. Note also that this is where you change your Dropbox password.

The new Dropbox security page

But despite this good response from Dropbox, the fact remains that these are reactive and not proactive steps. Security is still an afterthought, added on to systems rather than designed into them. That’s one lesson we don’t seem able to learn. Secondly, it is sad that a Dropbox employee should be guilty of fundamental security no-nos: he stored a file with user emails in plaintext; and he was reusing the same password on at least two different accounts.

These are the main lessons that we all need to learn: do not trust other people or systems to do security for you. It is your, not their, responsibility (or at least, even if it is their responsibility, you cannot assume they will do it).

And finally, and fundamentally, and beyond all others: when will we ever learn to stop re-using the same password on multiple accounts? Tens of millions of passwords have been stolen from tens of major providers this year alone – and that’s just the ones we know about. Are you sure that your own password is not included? If it is, and you re-use it on multiple accounts, then you simply don’t know who has access to your accounts. And if that includes your email account or bank account, not to put too fine a point on it, you’re screwed.

So, is Dropbox safe? Probably not; but that doesn’t mean we shouldn’t use it under certain circumstances. I shall certainly carry on using it. But are we safe? Absolutely not until we start using unique, strong passwords for every different account. Hint. Use a good password manager.