Last month our Crypto chief, Doctor Michael Scott, compared FIDO to our MFA, zero knowledge proof verification system: MIRACL Trust, culminating in the publication of a new white paper - https://miracl.com/blog/fido-a-noble-attempt-but-alternatives-required/ - Today, in part one of a two part series, he challenges the ‘Trust-me’ concept and highlights it’s dangers and the vulnerability it brings to the user.
Authentication is quite a crowded space with multiple Username/Password replacement proposals out there. One thing we all agree on – Username/Password is no longer fit for purpose. But what are the alternatives, and how might they be categorised?
Dig down into many proposals, and you find that they are FIDO-based, even though this may not be advertised front-and-centre on their websites. And we have discussed FIDO at length elsewhere. Another large category are what I call Trust-Me schemes.
Imagine you are responsible for a service, and need to allow access to only registered clients. You can deploy the technology to do it yourself (FIDO, M-Pin), or you can employ a third party to take care of it for you. Rather like employing a bouncer to control access to a night-club, this entity is typically impressive looking, and seems happy to take care of all of the details for you. Of course all concerned need to trust this new entity to do the job fairly and securely. Trust-Me and all will be well.
Now security is all about minimizing your trust exposure, making your trust surface as small as possible. Less things to trust, the less things can go wrong. Open source technology (FIDO, M-Pin) can provide a solution without requiring an extension of trust to anything other than the underlying technology and its mathematics.
Another feature of good security is the absence of any single point-of-failure. As we know attackers will head straight for these, as a successful attack can often unlock everything. For example with Username/Password the password file represents a classic single point-of-failure.
So by deploying a Trust-Me scheme one is deliberately extending one’s trust exposure, and at the same time allowing inside the gates a massive potential single point-of-failure. So why on earth would anyone do that?
Trust-Me schemes are typically sold on lots of spin and blather, and are very short on hard technical detail. But if you are a classic Trust-Me mark, you don’t care. You actually quite like that aspect of it. These guys seem to know what they are talking about, lots of others seem to trust them, why shouldn’t I? Which is fine until something goes wrong. The idea that Trust-Me is itself as vulnerable as any other internet entity, and may be hacked, and all its secrets spilled, doesn’t seem to be imaginable.
I have looked at a few of these schemes, and dug down in vain to find any solid cryptographic foundations. There aren’t any. In fact details of any kind are very scarce, and anyway not required, as of course we are working on a Trust-Me basis. So it makes perfect sense to not reveal any details as (a) the customer isn’t interested, and (b) such details may actually be of use to an attacker. Until of course you are unfortunate to attract the attention of an attacker who is not so easily deterred. In the world of cryptography we refer to this disparagingly as ``security through obscurity’’. It holds up for a while, and then it spectacularly collapses. Your bouncer may turn out to have a glass jaw!
The reason cryptography is important, is that it is a requirement to prevent so-called phishing attacks. Through the magic of modern cryptography it is quite possible to prove possession of an authentication credential, while revealing nothing about it. Sometimes we call this a zero-knowledge proof. On the other hand a Trust-Me solution invariably requires the user to hand over their credential. Which means that they can be fooled into handing it over to a bad actor – you have been suckered by a phishing attack. Of course the Trust-Me entity may itself be that bad actor!
In part 2 we look at a Trust-Me example that falls into this category!
Discover more at www.miracl.com or follow on social media: Twitter @MIRACL | LinkedIn MIRACL
Dr Michael Scott is Chief Crypto Officer at MIRACL, one of the pioneers of Pairing-based Cryptography and the “S” in the widely used BLS and KSS families of elliptic curves. Following a distinguished career of almost 30 years at Dublin City University and an active consultant to both public and private sector, his unmatched depth in knowledge is drawn not only from his academic expertise - he’s published over 100 highly cited papers – but his genuine love of cryptography and the science behind this.
