Five Minute Overview

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)

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.

About privacy

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.

Man-in-the-Middle protection

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

End XSS, CRSF, enable safe Javascript apps

Site owner signs all server certificates of all their servers under their control.
(all parts that form a single site: main site, /images, CDN-resources)

User agent can recognise the same root CA certificate at these servers;
give the same trust-level to all resources from these servers,
and lower trust level to all other resources from other sites
(signed by others, or unsigned)
-> End of XSS, CSRF
-> Create safe javascript applications

Local storage (at browser) can be tagged to CA-identity.
Safe against domain attacks to retrieve data that
belongs to another web site.

I call this: Cryptographic Same Origin Policy.
The CA is the Origin!
Not the domain name.

Secure messaging.

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.