We take the protection of GOV.UK Verify and the security of our users and their data very seriously - we've posted previously about how we keep GOV.UK Verify secure.
GOV.UK Verify is Pan Government Accredited - an ongoing independent process to confirm we are effectively identifying and managing risks to the service. Our work to secure the service to protect users’ privacy and security is never finished. We appreciate that the range and nature of threats is constantly developing, as are the technologies and methods for protecting digital services against attack.
As part of our work to constantly develop and improve GOV.UK Verify, we are always working to make sure GOV.UK Verify reflects the very best in the current state of knowledge about how to protect digital services.
Risk is something we assess on all levels (not just technical or operational) and giving consideration to the service we offer, how that service affects users and their data and the consequences of actions and incidents that may occur. People often think of technical mitigations for risk such as cryptography but that is only part of the solution; we also need to consider people and processes.
Much of the change and innovation in the way we secure the service comes from within the GOV.UK Verify ecosystem of users, certified companies and government services. However, we also look to subject matter experts outside of government to challenge our thinking. In this blog post we thought we’d share a little about how we have learnt - and continue to learn - from these experts.
We work with security experts in other government departments, such as CESG (the National Technical Authority), and non-government groups, such as OASIS, as well as having our own experts. We take a structured approach to identifying risks and designing effective ways to mitigate and manage them.
The more eyes there are on a service, the better it gets as improvements and alternative approaches are suggested and developed. The feedback that has helped us develop GOV.UK Verify has come from a variety of sources: industry; other governments; and international standards organisations.
Last summer a paper was published by a group of researchers and security experts entitled: Toward Mending Two Nation-Scale Brokered Identification Systems. This paper provided a critique of not only GOV.UK Verify with regard to privacy and security but also to the identity scheme operated by Connect.Gov in the United States.
At the time we wrote about how the paper raised some interesting issues about how federated identity assurance systems like GOV.UK Verify work, and how users' privacy can best be protected. We invited one of the authors of the paper to join our independent Privacy and Consumer Advisory Group, and we’ve continued the conversation over the following months to explore the issues raised in the paper. We’ve found this process very useful, and we look forward to continuing to share knowledge and learning with the academic community and other experts as GOV.UK Verify continues to expand and improve.
The issues discussed in the paper centred on a particular type of potential security breach in relation to the GOV.UK Verify hub, and the idea of having such a hub. The hub is the part of GOV.UK Verify which allows communication between the user, the certified company, and the service on GOV.UK.
The overall design of GOV.UK Verify means that the amount of data passing through the hub is very limited, and it doesn’t store personal data. The hub enables a user to choose which certified company they want to use, and passes the user to that certified company. The certified company verifies the person’s identity. The certified company passes the user’s name, address, date of birth and gender (known as the matching dataset) back to the hub, along with a message to say that the person’s identity has been verified to the required level of assurance, for onward transmission to the service the person wants to use.
None of the data used to prove the person’s identity leaves the certified company. Once the person has accessed the service they want to use, no further data is passed back to the hub - the hub doesn’t see any data about what the user did once they accessed the service.
A big part of the reason for designing the hub in this way (rather than, for example, building a large database containing everyone’s identity information and linking together data about each person’s use of government services) was to minimise the value to potential fraudsters of the data passing through the hub. There is relatively little value in gaining access to data about a person's name, address and date of birth; that information can much more easily be obtained from other places, such as the electoral register or social media accounts. This means that although certain types of breach may be theoretically possible, it is highly unlikely that anyone would be motivated to execute them because of the effort involved in doing so significantly outweighing the benefit.
We’re always working to understand as fully as possible all the potential breaches that could affect our service, whether or not they have yet happened or are likely to happen. We are constantly iterating our approach to respond to new threats. The paper considered a particular type of potential breach that could theoretically allow someone to gain control of the GOV.UK Verify hub, enabling them to direct the user to use their credentials for a purpose not evident to the user (such as gaining access to the user’s records within a government service). It also considered a scenario is where the hub is ‘curious’ and becomes a tool for observing the data that passes through the hub. We were already aware of these types of threats, and had things in place to mitigate them. But we don’t assume we know all the answers and are always keen to learn from this outside expert opinion, so we met with one of the paper’s authors on multiple occasions to discuss the issues raised from a technical and policy perspective.
This type of research and engagement helps us validate our thinking, and it also shows us how security threats may be perceived elsewhere, helping us improve the way we explain our work.
What we’re doing
In the short term, lessons from the paper have fed into our thinking for how we can continuously improve the way we govern the federation, and also how we monitor for industrialised attacks on GOV.UK Verify.
The authors of the paper proposed some specific measures we could consider, and we have built some of the outcomes of those discussions into our work towards our objectives for taking GOV.UK Verify from beta to live. We’ve incorporated this into our ongoing risk management and accreditation work.
The paper highlighted some advanced cryptographic techniques that may be of use, such as sharing an ephemeral key from the government service provider which can be used to prevent visibility of user attributes at the hub by adding an extra layer of encryption.
What remains to be proven is the suitability of such solutions in a production identity system such as GOV.UK Verify. This is a limitation the paper’s authors recognise.
We currently use state of the art privacy technologies and techniques, and in the future we are interested in adopting new and more advanced privacy technologies and techniques as they become viable, something the researchers of this paper may be able to help us achieve.
From the start, we have known that there will be sophisticated and well-funded attackers, who aim to able to operate undetected for long periods of time. This thinking informed the overall design of GOV.UK Verify, our approach to security and the decision to take a federated approach, using a range of certified companies and building a hub to manage communications between users, certified companies and services rather than building one single identity database.
It's almost impossible to prevent all attacks to an online service, particularly as criminals can draw on huge resources when motivated to do so. Therefore, as well as our work to prevent attacks through the way we design and run GOV.UK Verify, we also have to build our monitoring capability so we can detect attempted attacks when they take place. This means we can mitigate the type of attacks discussed in the paper by making sure that we are able to very quickly detect these industrialised attacks as they appear and close them down rapidly, protecting the user.
We already have monitoring capability so that we can look for patterns of abuse, anomalies in usage, or simply odd behaviour that points towards these sophisticated industrialised attacks. This includes tools to automate some of the attack scenarios mentioned in the paper helping us to build a detailed understanding of how we would detect and resolve breaches should they happen, protecting our users and their transactions in an ever evolving threat landscape. We’ll be working to improve this capability in response to developing threats and technologies over time.
Working with industry and open standards bodies
The privacy of our users comes first in everything we do, so hearing about new approaches to the protection of personal data as it is used in identity federations such as GOV.UK Verify is very important to us.
Our engagement outside of government regarding technology and security has always been an important feature of GOV.UK Verify’s development and will continue to be so. The initial SAML profile and hub design was supported by experts from Microsoft, Oracle and IBM to make sure that we designed something that industry could easily adopt. More recently we have briefed the OASIS Security (SAML) Technical Committee, and the FIDO Alliance regarding our architecture, and continue to share our learning with the European Commission as we move towards cross-border access to online services.
We’re designing and building GOV.UK Verify to respond to a complex set of problems and we don’t claim to have all the answers. Working with - and learning from - a wide variety of experts helps us make GOV.UK Verify better for users. We welcome the input of experts, like the authors of this paper and, if that’s you, we’d encourage you to get in touch with us.