A basic tenant of online authentication is to try and achieve a zero-trust solution. That is our secret authentication credential should be generated by, and only known to, ourselves. However since we are authenticating to other parties it would seem inevitable that the other party should have access to a copy of those credentials, so that they can check their validity. So we would like to restrict our trust model to just ourselves, and maybe in part also to that second party that we need to recognise our credential.
Once third parties get involved, and our trust boundary expands, then while authentication can get a lot simpler, we are often no longer really in control of our own identity. We choose to call these trust-me solutions, where we give a single third party at least partial control over the generation and storage of our credentials. Almost always what is touted as a zero-friction authentication solution, is revealed to be a disguised trust-me solution.
Such a third party may (a) be malicious, (b) be subject to a court-order mandated requirement to reveal credentials to law enforcement, (c) may employ lousy security and be vulnerable to hacking.
A middle way would be a solution based on distributed trust, where multiple third parties are involved. As long as at least one of these parties does not betray our trust, we remain secure.
Registration If a client wishes to authenticate to a server, then some sort of registration process must take place. This is a one-off process, and we will assume here that it can be carried out without outside interference.
Passwords Let us first consider the use of passwords as credentials. At its simplest a password is just a secret key shared between a client and a server. The client holds the password in their head, and the server maintains a database of all of their client’s passwords.
The clever bit that gets us closer to zero-trust is that the server actually maintains a salted hash of client passwords, rather than the passwords themselves. When the client authenticates with their password, the server adds in the salt, hashes the received password, and compares the hash with what it has stored against that client’s public identity. If it matches, authentication succeeds. So the server does not keep a copy of the client credential, only its hash.
Assume for now an ideal scenario where all clients choose a strong unique password, say a random string of 12 characters and numbers, for each server they subscribe to. If that were the case then a server could in theory allow public read access to their database without any concerns. An attacker will not have the brute-force computational capability of trying all possible password guesses in order to find a hash that matches a database entry.
But as we all know the problem is that people choose weak, easily memorised passwords, and server databases get hacked, resulting in massive numbers of passwords being revealed.
Another problem with passwords is that during the authentication process the password is simply handed over to the server to be checked for validity. So just before hashing it, the server can see it. This raises a number of concerns. First if a client has re-used the same password with multiple servers, then a malicious online dating server might steal it and use it to log in, say, to our online banking account. However in our ideal scenario this will not be possible.
Have we achieved a zero-trust solution? Actually we have come surprisingly close. OK the server does get a glance at our secret, but they do not store it. Our secret credential is carried around in our head and moves seamlessly with us from device to device.
So how do we realise our ideal scenario? Well since few would have the memory capability of remembering multiple unique random 12 character strings, the answer would appear to be a password manager, which remembers them for us. Now we only need to remember a single password to access our password manager. But look a little deeper and see how quickly we have slipped from zero-trust to trust-me! Obviously we must trust the password manager to not be leaking our passwords through some hidden back-door. But worse than that, to be really useful the password manager (and all our passwords!) must be stored somewhere up in the cloud if they are to be available to all of our devices. Can we trust the cloud to keep our secrets? The cloud is after all just another server which is as liable to be hacked as any other.
So that is the problem with passwords. We cannot achieve the ideal scenario without slipping back into a trust-me solution, and hence losing control of our credentials.
Zero knowledge proofs (ZKPs) What if we could prove possession of our credential without actually handing it over for inspection? This is what is known in the trade as a zero-knowledge proof. That is I can prove possession of certain knowledge while revealing exactly zero about it. This is often touted as something quite magical. But its not really. If I follow you up a narrow corridor to a locked door and you open it, I can assume that you have possession of a key even if I didn’t actually see it (I was after all standing behind you). So a simple enough concept, but a very useful one in the world of authentication. By using zero knowledge we do not have to reveal our credential to the server, as we do when we hand over our password. And this can be achieved using a challenge-response protocol, where the server issues a challenge that the client responds to, using its secret. The main thing a ZKP brings to the party is immunity from being phished out of our credential – if it’s never handed over, we can’t be fooled into handing it to a bad actor.
What can modern cryptography do for us? Now lets try a different approach to authentication, using asymmetric cryptography. Here a client generates a key pair, a private key and a public key, which are mathematically related. The beauty of this is that only the public key needs to be shared with the server, and the client can prove possession of their private key using a ZKP. The private key, the important part, can be generated by ourselves alone and never revealed to anyone. We seem to have arrived at zero-trust.
But there is a potential problem. These private and public keys are very large, maybe equivalent to at least 32 random characters. Memorising them is completely out of the question. So the private key must be securely stored somewhere. The industry solution to this problem has been to make use of secure hardware. The private key is generated and stored inside of a secure enclave on our device, which can be accessed only by entry of a PIN number or via some kind of biometric recognition.
The almost universal possession of a smart mobile phone has meant that it has become become the ideal host for such a secure enclave. Even better, this type of solution can be plausibly touted as two-factor authentication as we need both the phone itself and the PIN/Biometric that unlocks the private key.
A short Digression on the limitations of cryptography Here is a simple rule about the capability of cryptography: Secrets in transit can always be effectively encrypted by a low-entropy key (like a PIN number). Secrets at rest on the other hand need to be encrypted by a high-entropy key (like a long complicated password). But every good rule also has an exception. Secrets at rest can also be encrypted by a low entropy key if and only if the secrets reside inside of secure hardware.
A consequence of this rule is that if you want to encrypt long term secrets using a simple PIN (or biometric), you must use secure hardware. Three issues with this. First if the secure hardware is lost, so is the data it contains. Second, you can’t create a local copy. Third, you need to trust the hardware to be secure. So its not a free lunch – in fact given the cost of hardware its quite an expensive lunch.
Lets go asymmetric The public key/private key type of solution has been heavily promoted by the Big Tech Companies( BTCs). It is almost always based on the FIDO specification (google it).
But wait a minute, in return for all this convenience we are bleeding trust all over the place. First we must assume that the secure hardware (made in country-you-don’t-trust) is secure and that it can be trusted. In fact it is a poorly kept secret that manufacturers always maintain back-door access to “secure enclaves”. The private key is not actually created by ourselves, but is created by the hardware (so its not really “our” private key).
And despite its apparent potential and the effort but into it by the BTCs, such a solution has not achieved dominance. We still find ourselves using passwords. The Mobile phones involvement in authentication seems to be mostly limited to receiving SMS messages (itself a rather fraught mechanism) to confirm that we possess the phone we used during the registration process. This is a process that completely bypasses the secure enclave, and instead leverages that other long-standing secure hardware component of our phones, the good old SIM card.
The reason for slow adoption? Us fallible human beings keep losing our mobile phones. Which is a complete disaster. Our private keys are gone forever and we are locked out of everything. An experience that might lead one to regret the passing of passwords.
So how to make a solution based on asymmetric cryptography more palatable? The industry seems to be settling on something now renamed Passkeys. The concept is simple enough. Our private keys and other secrets are communicated up into the cloud, moved from our secure hardware into their secure hardware - in practice multiple Hardware Security Modules (HSMs) up in the cloud. Since this is data-in-transit it can be effectively end-to-end encrypted. From there our secrets can be shared across devices and if a device is lost a replacement device can be provisioned from the cloud. But we have lost control of our credentials!
When reading some documentation describing this technology (and the description did seem more intended to obscure than enlighten), I came across this revealing sentence at the very end - “The keys to reprogram HSMs are destroyed by
So in fact we have again slipped back into what is an elaborate smoke-and-mirrors trust-me solution. Our authentication credentials are under the control of a third party, and we have in effect lost control of our identity. Back to square one. Passkeys are in reality not much of an improvement on a cloud-based password manager.
Solution? We need some new thinking. Our M-Pin product uses a combination of a password (but one that is easy to remember) and a software token generated using a distributed trust mechanism. That password component is only known to ourselves, so we retain control of our credential. The software token can be simply copied across all of our devices. Our credential is never exposed to the server but is rather used in a ZKP, so the server can be convinced that we possess it.
