ONS Digital

[A guest post from David Carboni – Head of Open Platforms at Methods Digital and our Tech Lead on the Beta project.]

The ONS produces a lot of sensitive and market-moving data. If this gets out, even seconds before the official publish date and time, the results could damage the UK economy. It is of paramount importance that this information is carefully secured and that the measures put in place to keep it safe are checked and validated.

As part of becoming a digital organisation and reducing costs we’re looking to make use of commodity services rather than maintaining our own infrastructure. We’re not a hosting company, so moving operations into the cloud means we can focus on core business whilst delegating supporting resources and activities to specialised providers.

Cloud computing is now broadly accepted to be secure but we’re still not comfortable handling market-sensitive data in someone else’s data-centre. We trust our providers, but if anything should go wrong, it is in everyones interest that no one can raise any questions about this trust.

So how do you put sensitive government data into a cloud providers capable operational hands? One answer is encryption.

The actual maths and mechanics of encryption are the stuff of Beautiful Minds, Bletchley Park and GCHQ, so you may be curious as to how we’re able to build it in when it’s not far off rocket science. There are a few basic principles to building with encryption which, if followed, allow you to stand on the shoulders of giants and keep the national economy safe. All before bedtime. Interested? Here goes:

– The first rule of encryption is, to mis-quote Churchill, “Never, ever, ever, ever, ever, ever, [implement an encryption algorithm]”.
– The second rule of encryption is, don’t implement an encryption algorithm. Seriously. Just don’t.

It’s not worth the effort, the tears, the maths degree or the inevitably leaked information. If you’re smart, you’re not the smartest. Unless your role is specifically intended for this, run screaming for the hills. Use existing, well-established, known technology to do the work.

The answer to building with encryption is to understand how to make use the building blocks at your disposal (rather than try to build those blocks yourself). Like cloud hosting, learning how to put it to good use is useful – and you don’t need to learn how to run a data centre for that.

Some of the most common cryptographic building blocks are:

– Encryption keys: these come in two varieties, Secret (or “symmetric”) keys (much like the settings for the famous Enigma machine cracked at Bletchley) and Public-Private (or “asymmetric”) key pairs, typically used for proving identity.
– Standard encryption: this is what you probably think of as encryption and has been going on for centuries in many different ways. From A=1, B=2 … codes you may have used as a child, through to the industry standard Advanced Encryption Standard (AES) cipher, this is about keeping information secret.
– Digital Signatures: you may not be familiar with these, but they are fundamental to secure access to websites. They are an important part of the https protocol, used for example with your Internet Bank to prove the identity of the website you’re accessing so that you can trust it.
– Key exchange: there’s no point encrypting something if the person who needs access doesn’t have the key to decrypt it. The question is, how do you get that key to them without it falling into the wrong hands? Key exchange is the process of ensuring that encryption keys can be safely shared with the right people.
– Key wrapping: once you have a key, you’ll need to store it somewhere, but you wouldn’t just leave it lying around. To safely store an encryption key, it needs to be wrapped (encrypted).

There are other building blocks, but these are the ones you’ll most commonly use when building with encryption. You may have spotted that most of these relate to keys rather than encryption. There’s no point locking your door if you leave a key under the mat. Assuming the encryption algorithm is secure, the true problem is not actually encryption. It’s the management of encryption keys.

So how do we keep national statistics safe?

– We use the https protocol, along with secured access to our publishing platform, to ensure that information is protected from the publishing desk all the way to the cloud.
– Once it reaches our infrastructure, we use standard encryption to secure storage of the data.
– Each release of data to the website is secured with a separate, unique key.
– This key is securely exchanged between only those members of the organisation who are authorised to work on the information.
– There is no “master key” to the system and none of the information needed to unlock a key is ever stored in the cloud.
– Each authorised user is able to unlock the keys they have access to only when they log in with their password.

For the technically minded and curious, this means:
– AES keys for encrypting Json stored to disk
– RSA Public-Private key pairs for each user, for key exchange
– AES wrapping of each user’s private key, using a key derived from the user’s password
– PBKDF2 hashing of user passwords. We could have used bcrypt, but that would mean an additional library, rather than using a standard algorithm. It’s a judgement call.

No sensitive information – passwords, keys or data – is ever stored in the cloud. The only way to recover content being prepared for release is with users’ passwords, and those are stored in secure wetware.

And that means no one can get hold of market-moving data from the publishing platform before time.