Over a year ago I wrote a blog post about how we protect users’ privacy when signing in to a GOV.UK service with GOV.UK Verify. In that post I gave an overview of some of the things we do to protect your data. Now I’m going to dig a little deeper into why we go further than most digital services where security is concerned.
Most users will know from headline news stories that cybercrime is an ever-growing threat, not just to big business and government, to all of us. In recent weeks articles in national newspapers have highlighted the risks of identity fraud in relation to online services resulting in the theft of personal information. What many people are unaware of is that malware is very widespread and an unprotected browser and device can be infected in just a few minutes.
There are precautions we can all take and sites such as Get Safe Online have some great advice. But even the most cautious of individuals can be fooled by a well crafted phishing attack or a simple public wifi hack so simple children can do it.
For GOV.UK Verify our basic assumption is that your device has already been compromised. That doesn’t mean you have been attacked or malware installed, it just means we can’t take the risk that something isn’t lurking in your browser trying to steal personal information. By taking this approach, we can best protect everyone from loss of data and identity fraud, whether or not their device has been compromised.
Protection beyond the browser
Our security is in multiple layers. Firstly, there are the more usual precautions you would expect to find in any digital service. These include designing GOV.UK Verify with security in mind and always using web standards such as HTTPS and TLS. This means we don’t expose your data unduly or ask you for data we don’t need. It also means we protect what is called the ‘transport layer’, the way data moves between your browser and a web server.
The next layer is concerned with the messages and data we use specifically for signing in to GOV.UK Verify and the service you’re trying to access. To protect your data in transit we use strong cryptography techniques to encrypt your data before it leaves one of our trusted companies or when we send that information on to the government service you are trying to access. So that we can trust the integrity of the data in each message passed between government services and our trusted companies, we also use those techniques to create a digital signature for each message and each data payload.
Why do we do all of this? Because we care about the integrity of those messages. For example, we want to know who created them and that they haven’t been changed as they pass from system to system. We also want to encrypt the personal data so that even if your browser or PC is compromised malware won’t be able to read that data either as it won’t be able to decrypt it without private keys that only the intended recipient has access to.
The final layer is monitoring. This monitoring is split into two areas: protective monitoring and transactional monitoring. Protective monitoring allows us to set controls and alerts across our infrastructure to identify anomalies in the use of GOV.UK Verify or to help in the identification of potentially fraudulent activity. Our transactional monitoring capability analyses the messages being sent through our infrastructure, as well as the devices being used to send those messages, helping our analysts and services to better detect attacks.
Security is an ongoing task
It doesn’t stop there. We are continually adding to our defences such as Cyber Threat Intelligence that alerts us to potential and known attacks or vulnerabilities, and monitoring and responding when a known compromised credential is being used. We also work with experts to continue to understand and respond quickly and effectively to rapidly developing security threats, technologies and approaches - we’ll be blogging more about that shortly.
Subscribe to the blog to keep up to date with GOV.UK Verify's ongoing development
4 comments
Comment by MarkK posted on
The https certificates for the IdPs are from companies few users will know, and they are in the US or Netherlands. The government services also have a variety of certificates from trust anchors in Bermuda (which has no Data Protection legislation yet), Ireland, Sweden, and one provided from Utah but with a Salford address. Most of these have policies with limitations of liability in the low hundreds of dollars or Euros.
The privacy principles include "I can have confidence in any Identity Assurance System because all the participants have to be accredited". How can the potential user tell that these have been accredited, assuming that they have been?
Comment by Adam Cooper posted on
The HTTPS certifications do come from various sources but our trust actually comes from the message integrity and confidentiality not the transport layer, which is why we go much further with our use of cryptography and security controls.
All certified companies have to go through a rigorous onboarding process and users can be assured that the companies have completed the process before being allowed to connect and display the certified company logo.
We’ve blogged about the process in more detail here https://identityassurance.blog.gov.uk/2015/07/17/gov-uk-verify-making-sure-certified-companies-are-ready-to-connect/ and here https://identityassurance.blog.gov.uk/2014/12/11/what-it-means-to-be-a-certified-company
This process includes tScheme accreditation. All of the companies will have been audited by tScheme before they are able to connect. The final stage will be an audit to check that the service is operating correctly. This can only be done once the service is connected.
Comment by MarkK posted on
For the user, the machinations of the innards of your system are irrelevant if he or she has been connected instead to a bogus site, let's call it gov-uk.id displaying all the relevant easy-to-copy logos.
The HTTPS certification is the first step of the reassurance for the user, but if the genuine certificates are coming from an unknown Californian provider that has never heard of tScheme the claim that 'all the participants have to be accredited' rings hollow.
Why not use qualified certificates for website authentication in line with eIDAS chapter 3 section 8?
Comment by Rebecca Hales posted on
Hi Mark
I have the following response from our risk and assurance team:
The risk you describe is not mitigated by requiring a qualified certificate. A user may still be drawn to a bogus website with a qualified certificate. The bogus website doesn’t even need that to be a qualified or extended validation certificate to perpetrate this fraud as many users will only check they get a green padlock on the screen, which will happen if the certificate matches the domain name, regardless of any other details. For users that read the certificate details, most of it will be meaningless unless they happen to know exactly what to expect it to contain.
That’s why we encourage users to always start at GOV.UK and why certificates are just one part of the wider work we're doing on GOV.UK Verify to protect user data.
With regard to using an overseas certificate authority, all of our certified companies are required to use an extended validation certificate. This process confirms the organisation details that are to be put in the certificate are correct.
The identity provider certification from tScheme is not related to the certification of the Certificate Authority.