Eccentric Authentication in 5 minutes
Everything is done with cryptography!
No more unencrypted connections. Secure by default
All crypto is handled by user agents
User agent does all the cryptographic hard work. No need to trust anyone to get security. No difficult questions to answer.
We use server certificates to identify servers.
Each server get a server certificate. (nothing new here) What's different is who signs it. It's not a global trusted third party. (someone we have to trust not to betray us) (which some of them did anyway).
We use client certificates to identify users.
Client certificates are anonymous. There is no personal identifying information in a client certificate. Client certificates contain only a user-chosen nickname. (pseudonym) Or a user-agent chosen random id. Or a throw-away random id (use once and discard) Client certificates eliminates accounts with email address and password. No more password breaches when a server is breached. There is no personal identifiable information (at the CA, nor the site)
Each site owner runs their own certificate authority. (this is new!)
It creates a root key and signs two sub-keys. One subkey to sign the web server certificate Other subkey to sign the client certificates For its own site, only For users to log in at the site. Users specify a nickname and a public key to be signed. The nickname is the account name. Nicknames are unique at each site. (can't have two different users with the same name) Important: The root key stays offline, eg, a smart-card, crypto-stick, HSM. Only the subkey to sign the client certificates is online at the CA.
To reiterate: Each site runs their own CA
They only trust their own, not any CA from other sites. Each site creates their own accounts/identities. Nobody sees if two accounts on two sites belong to the same user. Unless a user uses the same nickname at different sites. Even if one can link an account to the users real name all their other accounts remain anonymous. The damage of leaking an account is limited to that account.
Validate uniqueness of the Nicknames
Nicknames are how people recognise each other at sites, if there are two or more certificates with the same nickname it could be a Man-in-the-Middle attack by a site/CA, Users need to be able to validate uniqueness of their identity.
Independent registry for nicknames
We need an independent registry for nickname -> certificate mapping. Independent of the CAs Could be part of the services of an ISP. Or a consumer organisation. Or a global decentralised network. After signing up for an account, Users submit (new) certificate to the registry Registry tells whether the nickname is unique, or not Everyone can lookup certificates for any nickname Should return only one certificate. If there is more than one bearing the same nickname: -> CA is dishonest -> untrustworthy or incompetent -> Run away! -> Blog about it at your favorite security blog. You have a signed confession by the CA. When to lookup a certificate at the registry? Your own nickname: every once in a while To check that the CA stays 'honest' towards you; The nickname of the people you are comunicating with: Once at first contact to verify it's them And not a snooping web site After that: no more lookups. You know who you're talking to. Store their public key in your address book.
These client certificates do not contain any personal identifiable information. Only a nickname and a random public key. They can be distributed globally without leaking information.
Create global names
So far, we have made sure nicknames are unique at each CA. We need to give unique names to CA. Each CA is unique by their fingerprint But that is unusable as a name for humans to reference. example: John @@ F3 AB 4C 6D .... (horrible) We need to give the CA a name. We use DNSSEC and DANE. DANE lets the site owners publish their CA-certificates in DNS. DNSSEC validates that you receive the correct response. Validation is done by end point (user agent) (against ICANN Root Key) Each domain name points to a single CA. DNSSEC and DANE are used for two things: 1. Efficient scalable distribution of all the site CA-certificates Needed each time you connect to the site 2. Using the fact that the domain names are unique! Trust anchor is the single DNSSEC Root Key. Well guarded at ICANN. Now we have fully verifiable, anonymous, global unique names. Each name points to a single public key. Publish the name, at a business card. People can retrieve the key (the correct key) To communicate message that no one can intercept and read. Or to set up a encrypted audio/video channel.
Some technical details.
Here we have some technical details that might be of interest.
User agent connects to site, retrieve server certificate (and validates against sites' CA) User agent only logs in with matching client certificates (agent lets user choose) A homograpgh attack may look the same to the user; It's a different site with a different CA. And thus, no client certificates that match -> End of MitM
Users can encrypt message to other user with other's public key. Site does the message delivery. either requires sender to log in (closed community, dating site) or allow any encrypted message (open mailbox, blog site) Notice, messages are encrypted with a users public key, only the intended recipient can decrypt it with her private key. The site cannot read the messages between the users. Nor can anyone else.