The Evolution of Identity and Access Management Through Authentication
Last month, Charles Dray of Resonance Security organized a chat between me and Ofir Paz, the CEO of WiKey, in which we talked about the problems we are facing in Identity and Access Management (IAM), and online authentication. This article is the result of that conversation.
Introduction
The web has an identity problem. For the most part, we are using a system that is over sixty years old system for authentication — the username and password; a method of digital authentication invented way back in 1961 by a MIT computer science professor named Fernando Corbato.
Since then, numerous bolt-on improvements have been put forward to fix the problems with this simple system: password managers for storing stronger and longer passwords, confirmation codes by text or email, authenticator apps that produce a new code every 30 seconds, and the use of public/private key cryptography (also known as asymmetric key cryptography).
The latter is the focus of this article, but before we dig into that, there is a question that needs to be answered.
What is authentication?
Authentication is the process whereby one party determines that the entity they are talking to now is the same person they were talking to last time (and the time before that).
And authentication is important, because if a server out there thinks someone else claiming to be you is you, they may gain access to potentially sensitive information relating to you, and may be able to change that information. So it is essential that you, and only you, can log on to servers as yourself.
For example, a file server may be holding confidential and proprietary data, medical data, or financial data. If the wrong person logs on as you, they could read about your company’s secret inventions and business plans, look at your health history, or download your personal photographs.
If the server also allows users to take actions based on their identity, then a hacker who manages to log in as you might be able to delete your files or even your whole user account, transfer funds, and cause all sorts of other problems.
Just a few days ago, my son lost his Minecraft account and his Roblox account because he used his name in capital letters as a password. This is despite the lecture I gave him on password safety a year ago. Some miscreant out there guessed what he used, and was therefore able to impersonate my son, log in, and then ruin a couple of years’ worth of gaming by deleting his accounts.
If only my son had used a better method of authentication than a username and password, and if only Minecraft and Roblox had insisted that he do so…
Asymmetric key cryptography to the rescue
In 1995, Finnish researcher Tatu Ylönen invented the “secure shell”, or SSH, using public key cryptography for the authentication process. When used properly it applies a different kind of authentication using public key cryptography.
ssh login command line prompt
Here’s an analogy for the login process:
Imagine that to start with, you provide the server with a copy of your signature — a scrawl that only you can produce. That creates your account.
And then, whenever you want to log in to your account, the server presents you with a challenge: a piece of paper with a random number, or the current date and time written on it, or something like that.
You then sign it, return it to the server, and the sever compares the signature on the challenge with the copy of your signature it has stored. If they match, you get in.
And here’s the technical description:
You generate a public/private key pair on your computer, and share the public key with the server you want to access. Typically, an administrator of the server checks that the public key is yours through an out-of-band communication channel, such as email, a secure message, over the phone, or even in person.
To log on to the server you identify yourself by sending the public key again, the server then sends back a unique challenge which you digitally sign with your private key, and then you send the digital signature to the server. The server then checks that the signature is valid, and that the public key within the signature matches the public key it has stored. If they do indeed match, you are logged in.
How common is this?
This public/private key challenge/response method is used in Web2 by FIDO2 “passwordless” authentication, where a hardware device such as a USB dongle or a phone app connecting to your computer through Bluetooth or NFC handles the key generation and challenge signing. The combination of “having a private key plus sharing a public key plus challenge response signing” is called a “using a passkey.”
And Web3 uses the same mechanism for logging on using your blockchain wallet, because a browser extension such as MetaMask or a hardware wallet such as Trezor or Ledger can also generate public/private key pairs and digitally sign stuff.
Provided users (or more often the devices they bought) look after the private keys safely, the public/private key challenge/response method is probably the most secure system we have for robust and reliable authentication.
And that is the problem that developers often overlook. Lose the private key or the device that it is on, and you lose your identity.
Where’s that hardware identity device now?
Identity loss
Everyone has lost something at some point. Misplaced car keys, sunglasses left on the beach, phone stolen while shopping, or passport left in a drawer at the hotel. That was just me for one week on holiday in Corfu.
And so ensuring security for account login is important, but possibly even more important is the recovery strategy when users inevitably lose the things they need to log in.
When you sign up for an account on a FIDO2-enabled website using a Google or Apple solution, your private key is backed up in the Google cloud or iCloud, which means your key is sitting there on a third-party server. Instead of there being the risk of hackers stealing and brute-forcing a database of password hashes, the risk is that the private keys may be extracted.
Perhaps these companies will take good care of your private keys, and perhaps they won’t. The evidence is that every company eventually gets hacked, and as companies don’t publish details of their security processes and security clearance reports of their administrators, we have no idea how diligent, competent, and honest they are.
And identity recovery
In this section I am going to talk about a decentralized methodology (read: not run by a Silicon Valley tech giant) for providing key recovery and replacement. Note that this is a general discussion — there are many technical challenges and edge cases to overcome to make the outlined solution safe and secure, but the principle is there.
If storing your private key in the corporate cloud is ill-advised, what other options are there? Counter-intuitively, one is to store it on a decentralized system not owned by anyone that has shown it is here to stay. For example, a public permissionless blockchain such as Bitcoin or Ethereum.
Of course, you can’t just put the key up there in public where anyone can take it and use it to impersonate you. How about getting a friend to encrypt it with their public key first? That way, if you lose it and need it back, they can retrieve it and decrypt it, but no one other than your friend can get their hands on the private key.
This won’t work unless you have one friend with whom you trust your digital life. Enter multi-party computational (MPC) key recovery:
Split the key into multiple parts and share the parts with a plurality of friends and trusted colleagues, such that any combination of “N out of M” parts allows the key to be regenerated.
For example, you might split the key into five parts in such a manner that any three parts can be used to produce the whole key. That means that if two out of five of your friends prove to be unreliable, your private key and hence your digital identity remains secure. As long as three friends are still around and honest when you need the backup of your key due to losing it, you can recover it.
3-of-4 key sharing example
Note that splitting up the key isn’t as simple as cutting a pirate treasure map into separate pieces — there is some extra obfuscation that is used. Otherwise, just as anyone who has read a kid’s adventure book knows, a few or even just one of the pieces might be enough to allow the rest to be inferred.
This prevents your friends or coworkers from conspiring against you by reassembling your secret key. When a recovery process starts, the user can be notified and therefore can stop the recovery (or take over) process,
The only functionality that friends or recovery helpers can do is to attest that you are indeed the same person as before. Because the key is split up and encrypted among many unrelated validators on the blockchain, no one individual can access it from there: not you, not your friends, and not any centralized system.
Clearly there are many other moving parts: how to cancel a compromised key and authorize a new replacement, for example, but these are beyond the scope of this article.
Federated identity
We have looked at the danger of relying on companies for managing your online identity, but there is one further risk that bears examination:
Tying your identity to one provider, or the “federated identity censorship” problem. If you create accounts and log on to various online services using one key account and the “Sign in using Google/Facebook/LinkedIn” button, then all it takes is for the identity provider you are relying on to block or cancel your account, and you are locked out of absolutely everything.
To illustrate — just a couple of weeks ago LinkedIn accidentally blocked my account because I used the word “Bitcoin” in a comment. As a result I couldn’t log on to my patent search database of choice.
Federated identity management is not selling your soul to a corporation, it is giving it away freely.
Conclusion
The world is finally starting to take our digital identities seriously, even if reluctantly. In the blockchain world we have a couple of frequently quoted sayings that really should be applied more generally to the online world. The first is:
Trust, but verify
The caveat to this is that you can only verify if the systems you are relying on are transparent. Corporations are, generally speaking, opaque entities that are legally required to put the interests of their shareholders ahead of yours
The second saying is:
Not your keys, not your coins
This one is simple. If not owning your keys means not owning your coins in crypto, what does giving the keys to your identity away say about how much you respect yourself?
These two key points are why managing your online identity yourself in a way that still allows interoperability with the services provided by companies out there will become more and more important over time.
About the author
I’m Keir Finlow-Bates, often known as Blockchain Gandalf, and am primarily a blockchain researcher and inventor. I started out on this journey in late 2010 by examining the original Bitcoin code, and have been obsessed with blockchain ever since.
I am also the author of two books on the topic: Move Over Brokers Here Comes The Blockchain, explaining blockchain, and Evil Tokenomics, illustrating through practical examples how web3 scams work.
You can find more at my website: https://thinklair.com
About Resonance Security
Resonance Security is a curated platform for end to end cybersecurity products and services. We function as a concierge for your organization’s end to end cyber-security needs, aggregating valuable security offerings into one platform with the goal of spreading awareness on what it takes to secure your technology stack end to end.
Our platform and security certified team cover: penetration testing, smart contract auditing, blockchain systems and web3 auditing, DevSecOps, and cloud security.
For inquiries visit https://www.resonance.security