In an episode of America’s Got Talent, an aspiring stand-up comedian puts on a despondent expression and sighs “I had my identity stolen. It’s okay. They gave it right back.” That’s funny, right? Except for the fact that in the real world it isn’t funny at all. Your identity is your cultural, familial, emotional, economic, and social anchor, at the very least. So, if your identity is stolen, you don’t get it back just like that. It’s a personal integrity catastrophe that’s very hard to recover from.
eID Forum 2019 in Tallinn
eID Forum 2019 – Shaping the Future of eID took place on 17 and 18 of September in the lovely Hanseatic city of Tallinn. The aim of eID Forum was to bring together representatives from the public (governments) and private (industry) sectors. They achieved a presence of more than 300 participants from 34 countries to share ideas and emphasise the urgency of facilitating trustworthy civil and business digital transactions across national boundaries.
The Forum focused on high-level overviews of the processes and technologies used to develop contemporary eID solutions. We noticed a technology-centric focus and marketing of ready-made solutions. The focus topics for this year were:
- a cross-border digital standard for mobile driving licences,
- the future of digital borders, and face recognition and its use cases in airports, and
Should you be able to identify yourself or just your right to drive?
Huge efforts are being made to standardise driving licences that can exist in a form other than paper or plastic. But first, what is an eID (e-Identity)? An eID is a unique and immutable digital proof of identity for citizens and for organisations. One’s eID is a right and cannot be suspended or revoked because it is akin to, for example, one’s birth certificate. While an eID’s core attributes must be fundamentally self-sovereign and immutable, a wide variety of attributes can be granted to it and revoked from it. For example, privileges such as holding a driving licence. And one’s eID must be multimodal for use across a variety of digital identification-dependent systems and communication channels.
In Estonia, one does not have to carry any type of driving licence with him/her; not a physical or a mobile version of it. If it is possible to identify the person, then all the needed information can be checked digitally (the right to drive, having insurance, etc). This data exchange has, of course, to be done in a secure way. In Estonia, these data requests are done over the secure data exchange layer known as X-Road, which Gofore has had a role in developing since 2015.
Challenges with interoperability and rapid technological change
The idea behind eID standardisation and interoperability is that government services become more user-friendly, flexible, convenient, and resilient to many kinds of risks caused by otherwise divergent designs and implementations. But despite the fact that electronic identification is regulated in the EU by eIDAS (electronic Identification, authentication and trust services), its implementation in different countries is progressing at significantly varying speed and scope. There was recurring mention by presenters of the urgent need for eID standardisation, whether it be de jure or de facto, and the need for cross-border interoperability of the various eID solutions already in existence.
At the same time, the main challenges concerning eID are, in our opinion, twofold:
- Technological advancements for eID (including secure devices and identification capabilities like face recognition) are evolving fast and we do not know how regulation could keep up in this race.
- Did you know that according to the World Bank Group’s 2018 #ID4D Global Dataset, an estimated one billion people around the globe do not have an identity that they can prove? So for them, provable identity is not just missing in the digital society, it is totally missing. Since they face difficulties in proving who they are, they do not have access to services requiring digital identity. Might we consider having oneself listed in population registers as a human right?
Such fast-paced digital evolution as presented and debated at eID Forum is affecting every organisation in some way or another. We can help you rise to the challenges of fast digital change that you are facing your business domain. We can support you with organisational and technological change. All these consultations are available in Europe or world-wide through your nearest location: Estonia, Finland, UK, Germany or Spain.
This blog series is split into four parts:
- General information of secrets management
- Example how to store secrets into a version control
- Example how to use encrypted secrets in CI-pipelines
- Security issue and threat analysis based on previous examples
I’ll provide a small threat and security issue analysis based on this blog post series and the examples used, case-by-case.
Compromised personal or service account cloud credentials
It is possible that some member’s or service account’s credentials are compromised one way or another.
Simple steps for protecting compromised accounts:
- Revoke and reissue credentials
- Regenerate API keys
- Look logs for unauthorised access and usage
- Remove unexpected resources on a cloud platform
At least the Google Cloud Platform (GCP) has its own detailed guide for compromised credentials which can be read here: https://cloud.google.com/security/compromised-credentials
Last but not least: always use the multi-factor authentication for personal credentials.
Reducing vulnerability to a key compromise
If an attacker gets access to the key and encrypted secrets then all the secrets can be exposed – well, game over. The attacker can take your skeletons from version control and use them to carry out harmful acts like exposing IP addresses, passwords, API keys or even something worse.
However, you can reduce vulnerability to a key compromise with a few simple things.
Don’t re-use keys too often
With proper secrets management, you should never use a single, “one-and-only”, key for encrypting and decrypting all the secrets you have. You should create a new key which has its own purpose and encryption and is only for specific data.
In this blog series, I’ve used only one key to demonstrate how Mozilla SOPS work. You could make environment or version control repository based keys which would make things harder for an attacker. In the Very secret development operations, part II: Storing skeletons into a version control -blog, there was an example of how multiple different keys can be used with environment-specific rules (Advanced usage – Creation rules configuration).
Rotate keys and remove old versions of a key
Key rotation is a simple method to prevent key compromise: the old version of the key is versioned to history and a new, primary version of the key is created. Only the primary key is used for encrypting (and decrypting) the secrets while the old versions of key are used only for decrypting the secrets. Still, an attacker can have an old version of the key and use that for data leakage – but not for long if you remove old versions of the key!
You can manually or automatically rotate or destroy keys in cloud platforms. GCP has multiple guides regarding key management like:
In the Very secret development operations, part III: CI-pipelines -blog, there was an example of how to setup rotation period for a key, so GCP rotates keys automatically.
With SOPS you can renew the data key from the secret by command:
For further reading about key rotation with SOPS: https://github.com/mozilla/sops#key-rotation
A person leaving the project/organisation
If a person is leaving a company or a project they can be a sort of security issue if they still have access to resources after they have left. You have to always revoke access to all systems and keys which they have used.
While SOPS handles access to keys automatically, you only have to revoke access to cloud platforms and servers where your keys are stored. GCP has a good guide for revoking access to different resources: https://cloud.google.com/security/data-loss-prevention/revoking-user-access
Also, remember to revoke access to a version control – like remove a member from a Gitlab group or project.
What could happen after a compromise?
As I mentioned earlier, an attacker could use a compromised key to make harmful acts like exposing IP addresses and passwords. But things can be even worse than that, so I’ll mention a few aspects.
- Loss of sensitive information
- Personal data
- Industry secrets
- IP addresses
- Financial losses
- Illegitimate financial transactions
- Compensation to customers
- Loss of reputation
After all, your business can close down pretty quickly after the security breach. So keep your skeletons well hidden and secure secrets with proper secrets management, follow common security practices and follow, or even create security policies for your business and project.