Is it possible to build a trustless authentication system, that doesn't need certificates ? Cert-authorities have always been a attack-vector, which wasn't too bad because if they got compromised trust could be revoked, minimizing the damage. If that can't be done anymore because of legal or political risk, maybe a better system can be designed, which doesn't have this potential ?
Maybe technical design has to take into account the existence of bad political actors, and minimize the political and legal attack surfaces not just the technical ones.
The problem with certificates is they require a central authority, eg. politics. We need something that can work anywhere, without any third party or central authority.
Yeah anything that requires acking or creates distrust is a no go. I really want to transparently move all devices that support it to certificate-based authentication without training my wife to ignore or ack warnings. My fantasy is that IOT devices add support for it too, but that's just crazy talk.
Please do not bring a straw man argument to the table. I clearly said " Until a central-authority-free alternative exists". Such alternatives are readily available and already used to secure e.g. ssh connections, but are not without drawbacks. One alternative that might be less likely to suffer from the same weaknesses as a certifcate-free model is a distributed certificate authority that relies on a ledger like DNS.
That seems about as viable as allowing anyone to be a certificate authority. This system relies on a list of trusted keys, that chain of trust needs to be anchored somewhere. Notably, easy implementations depend on controlling all trust anchors.
The issue is you want cert based auth that is easily revoked. So you set up very short lived certs Yubikrys and the like is then only used for exceptional cases .
It's also the exact opposite of what you want in a certificate authority. You want simple, secure, and dependable, not complex, hard to verify, and easy to game.
Just out of curiosity, why aren't we using certificates for authentication instead of passwords by now? They can't possibly be worse overall, can they?
I think CA's are problematic nevertheless because they involve a third party I never invited. I would much prefer to have a ssh style public key fingerprint that you must verify and accept for one site, and know that once I've decided to trust them, nothing can come between me and them unlike with SSL certification chain. I would prefer to receive my bank's public key on paper when signing up for online banking and verify that it equals what I see when I first connect to their servers.
This reduces the MITM to the initial handshake. This could be worked out to a degree with some p2p scheme or a set of DHTs for popularity count. Fingerprints would be submitted to a public service that accumulates submissions from different users, identified by the same public key used to sign the submissions. Trustworthiness would be weighted based on the history and age of the users' submissions: someone who has used the same public key and submitted fingerprints for five years is likely to be a real user that you can trust instead of a bot that generates new identities in order to submit false fingerprints to launch a MITM. There are numerous ways to implement this.
One positive thing would be to bring the same attention to trustworthiness to people's minds that they must employ in "real" life as well, i.e. offline. A website that's never fraudulent or genuine (unless you got it in writing) but shades of trust more reflects the interactions we encounter in real life (can I trust this guy because my friend said he's ok?).
I think CA's are problematic nevertheless because they involve a third party I never invited. I would much prefer to have a ssh style public key fingerprint that you must verify and accept for one site, and know that once I've decided to trust them, nothing can come between me and them unlike with SSL certification chain. I would prefer to receive my bank's public key on paper when signing up for online banking and verify that it equals what I see when I first connect to their servers.
This reduces the MITM to the initial handshake. This could be worked out to a degree with some p2p scheme or a set of DHTs for popularity count. Fingerprints would be submitted to a public service that accumulates submissions from different users, identified by the same public key used to sign the submissions. Trustworthiness would be weighted based on the history and age of the users' submissions: someone who has used the same public key and submitted fingerprints for five years is likely to be a real user that you can trust instead of a bot that generates new identities in order to submit false fingerprints to launch a MITM. There are numerous ways to implement this.
One positive thing would be to bring the same attention to trustworthiness to people's minds that they must employ in "real" life as well, i.e. offline. A website that's never fraudulent or genuine (unless you got it in writing) but shades of trust more reflects the interactions we encounter in real life (can I trust this guy because my friend said he's ok?).
Interesting paper from Tatu Ylonen. He seem to be quick on throwing out the idea of certificates only because there is no hardened CA available today? Wouldn’t it be better to solve that problem, rather than going in circles and making up new novel ways of using keys? Call it what you want, reduced to their bare essentials, in the end you either have delegated trust through a CA or a key administration problem. Whichever path you choose, it must be backed by a robust and widely adopted implementation to be successful.
> I almost hate to say it because it's antithetical to the Internet and Hacker News ethos, but it's a testament to how well networked applications could work with a central authority and no anonymity. You don't need passwords. Accounts are provisioned automatically. SSO is global to the entire network. You only need one identity. But no, your office can't have Alexa.
I don't think it's necessarily a dealbreaker if you consider this: from a purely technical standpoint, there's nothing really stopping anyone from setting up a certificate authority- the only issue is getting service providers to trust it enough to accept those client certs as sufficient identification. I could easily imagine a world where I receive an "official" client cert from a government (which I can use to thoroughly prove my identity if needed) as well as several "pseudonymous" certs from various other CAs that I may use from time to time.
The main difference between CAs would be the kind of attestations they provide for a given certificate holder. For example, I could imagine a CA which (for example) is set up to attest that any holder of a certificate signed by them is a medical doctor, but will not (by policy) divulge any additional information.
Or perhaps a CA which acts as a judge of good character- they may issue pseudonymous or anonymous certs, but provide a way for application owners to complain about the behavior of a user presenting that cert.
I'm sure there are plenty of holes that can be poked in this model but I don't think it'd be completely out of the question?
Excellent thoughts!! This is definitely the sort of problem we're trying to solve. Certificates get us part of the way there in terms of solving the authentication problem, and then we can continue to manage authorization separately.. something to think about.
I think I'd like a version of this scheme which works a bit like email-based verification: you have a trusted provider (like an email provider today, you can self-host or use any of the many 3rd party hosts) that you use to vouch for your identity. When you want to log into a website you use a certificate authenticating you, the website checks if it's valid with your authority (similar to the current email-based verification on most websites). If you want to change your certificate for any reason you only have to do it with your authority and everything else keeps working as usual. The drawback of course is that you have a single point of failure, if the authority is compromised you're naked in the wild.
IIRC OpenID worked like that but unfortunately it never gained traction. It's a shame really.
More practically I do use a yubikey myself but mostly as a GnuPG smartcard, not for 2FA. I actually have the same key stored on multiple tokens as a backup, so if my current key breaks I just have to fetch an other one. Of course if instead I lose it or it's stolen I'll probably have to generate new keys (even though the PIN should theoretically still protect me) so the problem still exists.
The system we're building (and selling to big US administration groups) uses certificates to authenticate. I've never found installing a certificate hard.
This is a variety of SPKI[1], right? I was thinking of a conventional PKI approach, with an adapted web of trust to verify identities [2].
You are right - theoretically this could work. But it would pretty much take a "boil the ocean" approach to make it work.
Browsers would need to implement a secure (private) keystore, and presumably some way to sync that to other browsers.
A whole new standardized authentication flow would need to be created, which wouldn't be the same as the existing certificate-based authentication (which no one uses anyway)
Given that the certificates don't really need unique keys this would actually be feasible, yes (since then generating the cert only requires a RSA signature).
Maybe technical design has to take into account the existence of bad political actors, and minimize the political and legal attack surfaces not just the technical ones.
reply