… is to create a secure channel in an insecure environment.

A secure channel is where you can communicate with someone knowing
that no one else can impersonate your communication partner.

Knowing whom you talk to the is the most important
aspect of all cryptography protocols. Even more than keeping the
message confidential, or preventing people from learning who you
communicate with. (Don’t get me wrong, these are very important.)

Many great security protocols take it for granted that you already
know who you want to talk to, so these designers focus on the
confidentiality and anonymity aspects.

However, there is no easy way to communicate securely with the strangers
you meet on a web site. You can communicate, for sure, but there is no
way of knowing that you talk to the same person next time. Only when
you can verify that you are indeed talking to the same person, you
have a secure channel.

Getting that secure channel, that’s our Quest.

Shared secret

When you meet with someone in person, you can agree on a secret
password to encrypt future communication. As long as you keep the
password secure, you have your secure channel.

If you’ve never met in person, you obviously can’t establish a shared
secret. We need something else. It’s called Public Key cryptography.

Public keys

A very short primer on public keys. Both of you (independently) create
a key pair. It consists of a private key and a public key. Both of you keep
your private key private. Tell it to no one. The public key gets to travel the world.

There are two things you can do with the key pairs:

You can encrypt a message with someones’ public key. Only the owner
of the matching private key can read it with that private key. You
have a one-way secure channel. The recipient uses your public key to
encrypt the response to you. As you are the sole proprietor of your
private key, only you can decrypt it. That is the return channel.
A private key can sign a message. Everyone can validate
(with the public key) that is was that private key that signed it.
This signature is the proof that a message is actually send by the
other party, not by someone else. It establishes the identity of the
other party.

In simple terms, when you can exchange your public keys,
you have created a secure channel between the two of you.

The not so simple part is to exchange your public keys. You need to
make sure that the public key really comes from the person you expect
it to be. If not, you are encrypting your secret message to someone
else.

  We need to make sure we get the correct key from our partner. 
  We need a secure channel for that. Ouch.

Authenticating relatives

If you know the person and don’t mind the traffic analysis, send them
your public key by insecure email. Ask for their public key in
return. When you have exchanged keys, you need to validate these keys.

To do so, set up an encrypted voice and video chat channel that uses
these keys to secure the connection. You use your private key and
their public key on your end. They use their private key and your
public key at their end. When you have established a connection and
you recognize each other, presto. Keys validated. You have a secure
channel from now on.

The reason it works is that if one of you have gotten a wrong key, the
connection would not get established, as it does not match the other
end’s private key.

(There is a small chance that you might get tricked by a Man in the
Middle-attack. You have to do a little more work than just described,
but that’s easy.)

Authenticating strangers

The problem is more difficult when you want to communicate with
strangers. You can’t rely on voice recognition, nor meet in person. If
you could meet in person, just exchange the public keys like you did
with the password.

As public keys are just big (somehow random) numbers, they
don’t have any identifying properties. We need to attach a name to a
public key. What we need are Certificates.

Certificates

A certificate is quite simple. It’s a name attached to a public
key. That combination is then signed with the private key of the Certificate Signer.

As you remember, a signature from a private key can be validated against the
corresponding public key.

The private key that signs the certificate belongs to a Certificate
Authority (CA). That private key the most important asset of any CA. It binds
names and public keys together in a signed statement.

That’s the whole task of CA, binding names and public keys
together. It means that if you can trust the CA, you can trust that
the public key belongs to the name.

In other words, the name becomes the human readable identity of the public key.

We’ve split the the problem of creating a secure channel into two sub-problems:

to recognize the names;

the finding a way to trust the certificate authority.

There are several attempts at solving these problems.

Classic Trusted Third Parties

Classic Certificate Authorities solve the problems by requiring you to
prove your identity to them with your passport. Once they are
satisfied of your identity (and you paid them) they create a
certificate that contains your name and your public key. It proves to
the world that you own that public (and matching private) keys.

But you lose all anonymity. The certificate is like a digital passport.

The Trusted Third Party CAs solve the problem of identifying Public
Well-Known people. For example, a mayor could get a certificate
stating that he is the mayor of a city. It would be signed by the CA
that signs all certificates for civil servants.

It allows you to send your complaint about your neighbours’ fence to
the correct person, (the mayor) and not a major newspaper editor who
bears the same name. Whose certificate is signed by that of the journalists union.

These digital passports are not a good idea to use on the broad
internet, as they tie every action you do with your true life identity
for ever.

We need a different solution.

Eccentric Authentication

So far, in this blog, we established a way to create a secure channel
between two (strangers) who meet in person. They just exchange the
public keys and they’re done.

We established away to create a secure channel between two relatives:
thay exchange the keys in an insecure way and validate the keys by
setting up an encrypted voice and video chat. When they recognize each
other, the keys have reached their correct destinations. (With some
extra work to prevent a MitM).

We’ve also shown a way to esablish a secure channel with a publicly
known person. They need to get a certificate from a well-known Trusted
CA to proof you have the correct public key. That allows anyone to
validate that the key belongs to the person.

To sumarize: In all these cases, you need to know the identity of the person you
want to communicate with. Once you’ve confirmed the identity of the
person, you’ve validated the public key. Then you can use the key to
use the secure channel.

The identity of the person confirms the identity of the public key.
The key becomes the substitute identity of the person.

The key is the substitute identity of the person. The key is an identity.

Turning identity management upside down

We have to ask ourselves this question:

Question: Why would two strangers want to create a secure channel?

Answer: They don’t.

They don’t have any reason to communicate with each other. They’re
strangers to each other. They stay that way unless they would meet each other.

That’s what we are going to do, we are going to create a site as a way
to introduce people to each other. Say, a blog site. It will certainly
attract people. Most of them strangers to each other.

Our blog site lets people start a blog on a topic. And it offers both
public visible comments as well as private messages. Just like any
other blog or forum software.

Our site is different in the way we authenticate people. We don’t ask
for email addresses, nor passwords. We use certificates to let people
log in. Remember that cerficates bind a name and a public key? That’s
all that people need to provide when they sign up for an
account. People come up with the nickname, it’s how they want to be
known on our web site. It will be the name under which they write their
blogs and comments.

Make sure that you create a nickname when you sign up, not your real
name.

Our own CA.

We run our own CA to sign the certificates for our visitors. It signs
client certificates. Our web site only accepts our client certificates
signed by our own CA.

There is one more difference. When people post a blog or a
comment. Their computer signs the message with their private
key. This signature is placed together with the message on the blog.

When you read the message, your computer verifies the signature. It
uses the certificate to do so. It means that if you want to write
a private message, you already have correct certificate (with the
validated public key) to encrypt a message. Hand it to the site for
delivery and wait for the reply. As the message is encrypted, not
even the site-operators can read the message. How’s that for private
messaging?

With this design we have solved the dual problem of recognizing the
names and trusting the CA.

The site has become the introducer.

The site has become the introducer of both the people, and their public keys.

This is the biggest benefit of the Eccentric Authentication design. It
enables people to exchange cryptographic keys in the most easy
way. Just by signing up for a web site and blogging, you distribute
your public key. By reading the messages and responding, you exchange
keys.

The public key becomes the identity of the person behind it. Although
you don’t know the person, you have their key validated through their
use of the site.

Proper authentication is the key to anonymous connections.

We left out the part of making sure that the site is not performing a
Man in the Middle attack on its users. See the section on
Global registry.
It deals with that part.

Read our next blog A subversive idea
on why we call identity management a secure channel.