Eccentric Authentication on Eccentric Authentication

On the internet, there is only Alice

Fri, 18 Nov 2016 00:00:00 +0000

Everyone who works long enough in the field of cryptography knows about Alice and Bob: They know each other, go their separate ways and – always – are in dire need of private communication. Eve is listening in on every message and Mallory actively tries to trick them into believing her words are genuine. Then the authors of the paper explain their cryptographic protocol that makes Alice and Bob safe again.

Classic Cryptography

The use cases for cryptography have almost always been royalty, military, business and lovers. What they have in common is that all participants already know each other, get separated and are in dire need of private communication. So before the mission, they get together to agree on a protocol and key. Then they hire couriers to transport their encrypted messages.

This is what I call Classic Cryptography.

On the internet, there is only Alice

On the internet, the situation is radically different. There are a few well known parties and there are many strangers who want to communicate securely with some of the well knowns.

Take banking, for example. There are a few banks and a lot of potential customers. Suppose I want to open an account at a bank of my choice. My needs are:

I need to connect to the correct servers (authentication), not that of criminals, or worse, a different bank pretending to be my choice;
I need the link to be private (secrecy) to safely transmit a copy of my passport to the bank without third parties to copy it;

The bank has these needs:

The bank need to be able to recognize (authenticate) me at recurring visits. Without this recognition, I remain a stranger to the bank and the bank can’t accept my transactions;
No one should not be able to impersonate any customer.

It should be clear that classic cryptography doesn’t work here anymore. It would mean that to open an account I visit a branch office of the bank in person. We then agree on a protocol and some keys and we get separate again.

What about a blog site?

Suppose I stumble upon an interesting blog site. I read a while and then I feel a need to write the blogger in private. The same asymmetric requirements show up: I need to connect to the correct server and I want the connection to be secure against eavesdropping and tampering.

The blogger and I need to be able to recognize each other later in the conversation. Otherwise, we wouldn’t know for sure if a message was part of the conversation or inserted by Mallory.

There is a third requirement: I want to remain pseudonymous, the blogger only knows me by a self-chosen identity. And I use that identity only to connect to the blogger, I don’t share identities.

Again, classic crypto doesn’t help me.

What about a whistleblower?

Suppose I had to blow a whistle on some secret government program gone haywire. I’d search for a trustworthy journalist at a respectable newspaper. The journalist is well known and I’m the stranger and I would like to keep it that way for everyone, including the journalist.

The requirements are the same again, I need to be able to authenticate the journalist before I send my first document. I want to do so without the journalist knowing my true identity, my chosen pseudonym ‘Deep Throat’ suffices.

There is a fourth requirement: I don’t want the government to track me while sending the documents so I want to transmit all communication via Tor.

Fifth requirement: The journalist doesn’t know how any of that techno-stuff works so it must work out of the box without brainpower from either party.

It’s clear that classic cryptography doesn’t fit the bill.

Eccentric Authentication to the rescue

What these cases have in common is that there is a well known party (Alice) and there are strangers who want to open a secure channel.

Both parties need to authenticate the other at later visits, while in two of these cases, the stranger wants to remain anonymous.

Eccentric Authentication is my protocol that allows strangers to contact well known parties, secure all their communication, mutually authenticate and remain anonymous and untraceable if they wish. This site is dedicated to the protocol.

Happy reading.

tor made easy

Wed, 06 Apr 2016 00:00:00 +0000

Tor is the well known Onion Routing network. It lets people communicate over the internet without revealing their location.

Using the Tor network is easy*) if all you need is browsing. Just run Tails or Whonix and browse. The sites can’t figure out where you are. This is good for your privacy, your anonymity. And good for people in countries that censor parts of the rest of the world.

Others use Tor to host a hidden server. It lets them run a site without revealing their location. This is good against censorship too. And to sell contraband to much chagrin of law enforcement.

We offer a different use case: Connect to friends via Tor.

The basics of Eccentric Authentication is to be able to authenticate someone. In other words: to make sure it’s the same person as before. Once that’s established, there is no limits on the form of communication.

In this blog, we’re going to show how to set up the stuff to make that happen. Then we show how to use it to chat with a friend, either with text chat or voice chat.

*) Using Tor safely requires a bit more consideration. One must make sure to obey certain do’s and don’ts to prevent leaking of identifying information. Especially against active attacks to determine one’s identity or location.

setting up

Download this virtual machine and run it. Direct: eccentric-demo-3.ova or via torrent: eccentric-demo-3.ova.torrent.

using it

In the VM, log in with username ‘user’ and password ‘user’. If you need, user root has password root.

Double click the “Ecca Proxy 1” icon.
It starts the user agent service. It opens in a terminal and will show lots of debugging. Ignore that for now.
Double click the “Iceweasel 1” icon.
It starts the Firefox browser that uses the Ecca Proxy 1 for its authentication services. In other words: it uses the Proxy 1 to do all the cryptographic work for you.
The browser opens with http://cryptoblog.wtmnd.nl
Notice: it doesn’t use https but don’t worry, the ecca-proxy takes care of security (and does use https).
Browse the menu entry “The Blogs”;
Feel free to read any blogs, just don’t press any buttons on those blog pages, we’ll get to them later,
After reading, get back to “The Blogs” and press the “Create blog” link.
Expect a page stating: 401 - Eccentric Authentication required. This page is your Ecca Proxy 1 telling you the site requires you to log in with an account.
As you don’t have any, it offers to create an account.
Either specify a username (the part before @@) or let your ecca-proxy generate an ‘anon-12345678’ random username. If the name is still available, you’ll get it, otherwise chose a (slighty) different one. It should take a few seconds to sign up.
When that succeeds, you’ll get a split screen. On top, it’s the ecca-proxy telling you it has created and account and logged you in. At the main part, it’s the cryptoblog site waiting for your blog.
Be creative and write something that would attract some followers. When finished, post your blog.

Now, we leave this browser window and pretend to be a different user who comes across your blog.

Double click the “Ecca Proxy 2” icon. It starts up a second (and independent) proxy.
Then double click the “Iceweasel 2” icon. It will represent your different user.
Select “The blogs” and select the blog you just wrote in Proxy 1.
You could write a comment and post it to the world. Feel free to do so.
Or you could send a private message that is encrypted so only the (from Iceweasel/Proxy 1 could read it).
Or you could invite your alter ego (from Proxy 1) for a chat via Tor.
To do so: click the “Send invitation to connect”-button.
Select ‘chat’; it’s simpler to test that two audio streams to and from your computer.

Your Proxy 2 now does a few things:

It creates a Tor Hidden Service for you. This will be the listening point for the other user to connect to.
It sends its address in a private message to your alter ego.
It keeps waiting for the intended computer to connect (your first user) and kicks everyone else out. It’s a private connection.

Now go back to Iceweasel 1. Browse to the ‘Read Messages’ tab and behold, there is an invitation from your second account. When you click the ‘Connect’-button, the Proxy 1 makes a connection to the Tor Hidden Service address and both sides start the chat app.

Happy chatting.

spot the differences

Sun, 30 Nov 2014 00:00:00 +0000

As a child I liked to do puzzles. One of these was called “Spot the Differences.”

Get all 15 differences correct and you may win a prize.

There is an adult version of this game. It’s much more challenging:

It is more difficult: Only one picture is shown at a time. Players
have to rely on memory to recall the differences;
It’s played by millions of people every day, yet many don’t know
they are playing;
The stakes are higher: If you fail to spot any differences
you might lose all the money in your bank account.

This game is also known as Internet Banking.

The Toxic Combination

The problem is not restricted to banking. The general issue is twofold:

People need to validate the authenticity of a site before typing in
their password;
The password gets transmitted to the other party.

Most people assume that if it looks like their bank and the
address bar is green then it should be safe. Regrettably, it’s
not. Criminals obtain valid certificates using stolen creditcards and
passports. The true method for authenticating a site requires
verification of server certificate fingerprints. And if you don’t know
what that means, you’re playing the game: you have to spot the
spelling errors, the differences in layout and other mistakes to
detect the scammers. Good luck!

The second part is just as problematic: The password must remain
secret, yet it must be transmitted to the other side to log in.

This is the Toxic Combination. One failure to detect a scammer’s site
and the password is compromised. The scammers can do everything that
you can do with the password.

A Way Forward

We present our protocol to eliminate this toxic combination.

We eliminate the need for people to validate a site, the protocol provides
sufficient data so that the browser can do the validation for the
user. We also eliminate the password and replace it with client
certificates. Again the browser will do the work for the user. Making security usable.

How it works is described in our paper: Usable-Security.pdf

Image Credits: Image by Muband from Wikipedia - Spot the Difference, Creative Commons Attribution-Share Alike 3.0 Unported.

scalability

Thu, 27 Mar 2014 00:00:00 +0000

There are three types of queries to be made against the Verification service:
- submit a certificate;
- query a CN;
- query any duplicate CN for a given domain.

The biggest load on the Certificate verification service are the
queries keyed on CN. These queries will be done every time a user
comes across a new certificate. On a blog site where every blog and
comment is signed with the users’ private key, it means one lookup for
each new participant.

Most communities are relatively small, so while newcomer to a
community has to do a lot of lookups initially, that amount quickly
diminishes. A stable community has very little lookups to expect.

Another source of lookups is when one person wants to send a private
message to another. To protect agaist MitM, both sender and receiver
make two lookups of each others’ and their own CN, one lookup of each
before sending the first message, one lookup after receiving the first
reply. This suffices to establish to both parties that the CN is
unique. Both parties have effectively communicated their public keys
between them. They will remember this fact. From now on, there are no
more lookups for messages between these two.

This key-exchange dance with 4 lookups needs to be done separately for
each person one communicates with. Once this association is made,
there is no further need for key lookups. This lookup is cemented, no
matter if the CA signs another

how to design a distributed client certificate verification service

Wed, 26 Mar 2014 00:00:00 +0000

With Eccentric Authentication, the goal is to make sure that each
client certificate has a globally unique, human memorable name. In
other words: there are no two certificates (with different public
keys) bearing the same CN.

With unique CN’s, people can trust that each signed message must have
been signed by the holder of the corresponding private key. This ties
human memorable names to public keys. When we make it globally unique,
we have squared Zooko’s Triangle.

To make sure that each CN is unique, we create a Client Certificate
Validation Service.

The main tasks of the Client Certificate Verification Service are:

Validate that each client certificate has a unique CN;
Raise an alarm when a violation is detected.

CN’s are a tuple of (nickname, sitename), for example:
user@domain. Each site signs the client certificates for its
clients. Client certificates contain no identifying data other than
the nick name and the user’s public key. This makes client
certificates pseudonyms for their owners. People have at least one,
perhaps more different pseudonyms for each site they’ve signed up for.

To make sure that only the site itself can sign certificates for that
domain, each site runs its own RootCA. That CA is specified in
DANE/DNSSEC, making the domain name point to a globally unique Root CA
public key. (Site identity).

The risk is that a site signs multiple certificates bearing the same
CN. This would enable the site to perform a MitM-attack on its users.

To counter that treat, people submit their client certificates to the
verification service. The service makes it detectable when there is
a violation. That’s sufficient for our purposes.

More requirements:

The CCVS must not refuse to add any valid certificate to its list;

This requirement is to ensure that when a duplicate certificate for a
CN is detected by someone, it will be added to the CCVS, so others can
learn about this incident.

The CCVS must not be able to withhold a certificate when queried for a CN.

The CCVS must answer truthfully. It may not be able to withhold
certificates that match a given CN. It must report them all. If not,
it could collude with the site’s CA to attempt a MitM attack.

The challenge

The challenge is to find protocol that fits these requirements. Bonus
points if it is scalable, distributable .

crypto renaissance

Sat, 21 Sep 2013 00:00:00 +0000

With ‘CryptoGate’ in full action, many people are trying to come
up with a solution. Some good, many bad.

Many people focus on the security aspect of cryptography. Although
necessary, it is not sufficient.

The thing most people take for granted is how to authenticate the
other end of your communication channel. With PGP/GPG you need a web
of trust to validate. WebID/FOAF tries to replicate that in
HTTPS. These trust connections are public knowledge. There is no
anonymity. And if you are not part of that network, you don’t have a
way to validate any of the keys.

X509 server certificates from the global certificate authorities are a
scam (due to the missing X500 directory that matches end point
identities to certificate authorities). Try to answer this one: Who is
the certificate authority of your bank’s web site?

End user client certificates from these same certificate authorities
are akin to digital passports, tying all use of it to one’s true
identity, for life. Besides they still suffer from the missing x500
directory. One can’t tell from the certificate, if Guido Witmond’s
certificate signed by Verisign is mine, a forgery, or someone else
with the same name.

Validate keys of total strangers

I’ve came up with my way of doing things. I believe the answer lies in
the fact that we need a way to exchange public keys between total
strangers, reliably. In a way that is backwards compatible with the
current web, as that’s what people are used to.

I call that effort Eccentric Authentication.

The central idea is that each website signs the client certificates for all
it’s customers. The site runs its own CA. The only (and utmost
important) requirement is that the user-chosen account name is unique
for the site. Users don’t have to provide email address, passwords, or
other identifying details. Certificates are anonymous. Especially when
Tor is used. Users will have a different identity at each site,
sometimes more than one at a single site.

The second thing is that whenever people write a blog or leave
comments, these messages are signed with their private key.
Other visitors at the site can recognize the message signature by the
fact that the CA is the one from the site.

This ties the message to the person holding the private key. But a
public key is not a human friendly identifier. The chosen
account name (as Common Name) in the signature is human friendly.

To protect against MitM attacks, we need a way to verify that the
site’s CA signs each account name only once. I propose we use a
central registry like CMU’s Perspectives but for client
certificates. Whenever a person signs up for a client certificate they
submit their certificate to this registry. Every once in a while
people look up to see if theirs is (still) the only one for their
account name at the site. The most important requirement for this
registry is that it cannot fake the answers, once a certificate has
been submitted, it cannot deny it has received it. It’s best if it is
set up as a distributed service.

These two ingredients, Local CAs that sign only their own clients and
the global registry, are sufficient to let total strangers communicate
privately and anonymously.

If a reader of this signed blog wants to, they can write an encrypted
message to the author of the blog using the public key in the
signature on the blog. A quick lookup at the registry will tell if
theirs is still the only certificate for the {account name, site name}
tuple.

Authenticated anonymously

Once they’ve exchanged the first messages between them, and they
checked that both their account name and that of the other party have
the expected certificate at the registry, they’ve authenticated each
others public keys!

Two total strangers, who have never met, have been introduced by a
third party (the site) that also doesn’t know anything about the two.

The site disappears from the picture. Once authenticated, the people
can send a message (encrypted of course) with a delivery end point
that is independent from the site.

Global unique names

As we have a way to validate the account-name sitename tuple, we can
distribute public keys by just writing down this name. One can
introduce one other by telling this name. The recipient can look up and
see that the name points to one certificate. Here is the seed for a
web of connections. No nasty fingerprints to validate.

There is more.

With the site’s server certificate signed by the site’s own CA,
clients can match the client certificates for the site against the
site’s server certificate. This makes the CA’s root certificate the
identity of the site. This protects against phishing, as the
phishers cannot fake the CA’s root key. It won’t match.

It also creates censorship resistance. The site can change names, go
dark on onion sites. When the site owner creates a new certificate
with the same Root CA, the new site assumes the old identity. People can log in
again with their existing certificates.

I use DNSSEC and DANE to make sure that new people can find the
correct site. In combination with the registry, people can validate
that the DNS registries have not been manipulated.

It doesn’t take much.

All that’s needed to bootstrap this is a browser plug-in that does the
crypto work. As proof of concept, I made a web proxy to show how easy the user interface can be.

Please find it at Run it Yourself

If you have any questions, I’d happy to clarify. Just use plain email for now.

With Regards, Guido Witmond.

a subversive idea

Thu, 05 Sep 2013 00:00:00 +0000

In the previous blog The Holy Grail of Cryptography,
we’ve shown how you can validate keys when you know the person. Once
validated, that key enables the use of the secure channel.

We’ve also shown how we can create a web site that lets total
strangers communicate securely between each other. The web site acts
as introducer, letting strangers exchange keys and provides the transport
for the messages.

Separate identity from transport

Philosphically speaking, the secure channel is an abstract channel.

The secure channel is an abstract channel. It comes into existence at
the moment the public keys become validated to belong to the other person.

The channel is not tied to a single transport mechanism. Although you
need a concrete transport to use the channel, it is not tied to that
channel. The channel can be manifest in severel different forms.

The first form is the channel that the web site offers. It offers to
transmit a message from one to the other. The sender encrypts the
message with the public key of the recipient so the site cannot learn
of the contents of the message. It can only forward the message to the
recipient. We are going to use that channel to create another one.

A dating site

Suppose we run a dating site. Bob has seen Alice’s profile and they
have sent some private messages back and forth via the site. Bob
decides he wants to take it a step further and wants to talk to
her. He opens a ZRTP-listener on his own computer. It’s a protocol for
encrypted (confidential) voice and video chat. He does three things:

He configures it that it only accepts connections that are
identified with the certificate of Alice. Thus, only Alice can call,
all others are rejected.
He configures it with his dating-site certificate and private key,
so Alice can verify it’s that Bob from our dating site.
He sends Alice an encrypted message through the dating site in
which he specifies the ZRTP-endpoint, inviting her to place the call.

Then he waits until Alice places the call. (If she decides to do so).
When he receives a call, it can only be Alice as she’s the only one
with the private key that matches her certificate.

Now they can talk in private. Not even the dating site learns that
they are calling. The site is not involved anymore. The call goes
direct from Alice’s computer to Bobs’..

What we have done here is to use the dating site as introducer between
two strangers so they can exchange public keys without ever having met
before.

All it takes is a public forum, a dating site, blog site or a comments
section at a newspaper to introduce strangers to each other so they can
communicate privately via different concrete channels.

A single message is all it takes

A single message is all it takes to create a new secure channel when
you have an existing secure channel.

Suppose the dating site went broke just before Bob wanted to invite
Alice for his call. The concrete transport that they’ve used so far is
gone. Bob doesn’t have to despair. The abstract channel is still in
place as both still have each others public keys.

All Bob needs to do is to try to create a new concrete channel by
getting the invitation across to Alice. Most likely there will be
some blogging sites that write about the demise of this dating
site. Bob can write a public comment at that blog that reads:

 Dear Alice, I would love to get in contact with you. 
 Please call me at <endpoint>, you can recognize me 
 by my certificate.

 In anticipation, Bob
 <signed with Bob's dating site-certificate>

He then plasters this message everywhere he expects her to see it. (It
helps Bob a lot if they’ve talked about hobbies and such.) When Alice
eventually finds the message, she sees that the signature is from the
same Bob as the one on the dating site. If she wants, she can place
the call.

What happened is that — at the moment Alice has verified the signature on
Bobs public announcement — the secure channel manifested itself.

The power of client certificates

The real power of client certificates is that they don’t get
invalidated when the website and its CA disappear. You may lose a
concrete channel but when you have enough independent other
channels, you won’t lose contact.

The Eccentric protocol makes it easy to create these introducers, so
there is not a single identity to block.

The rest of this web site is devoted to make this dream come true.

the holy grail of cryptography

Sat, 31 Aug 2013 00:00:00 +0000

… 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.

run it yourself

Fri, 07 Jun 2013 00:00:00 +0000

Safe, secure and as anonymous as you want.

It was already possible to test drive the Eccentric Authentication
Proxy. But it required you to compile software. Now we’ve flattend that
hurdle (a bit).

As of today we can offer the first download of our client software for
Debian GNU/Linux. It might even work at other linux-distributions.

The software is a local proxy service. It sits on your computer,
receiving requests from your brower. It does all cryptographic
operations that browsers are bad at.

Here is a walkthrough of what you can expect when you run it: walkthrough.

download

You can download the ecca-proxy software here: ecca-proxy.tgz

Notice that this is a 64-bit executable. (linux only).

run it

To run it, perform these steps:

apt get install libunbound2 libsqlite3 openssl
tar xzvf ecca-proxy.tgz

./ecca-proxy

configure your browser

You need to configure your brower to send all requests to the ecca-proxy. Here is how to do that:

start your browser (iceweasel/firefox)
click on Edit -> Preferences -> Advanced -> Network -> Settings

You should see this:

Click ‘Manual…’ and fill in 127.0.0.1 and port 8000 at the HTTP Proxy setting and press Ok -> Close

Now you’re ready to play with it. We have two websites that offer Eccentric Authentication:

1. The worlds’ most secure dating site

It looks a bit like a dating site. You can get a list of aliens (as we
call humans that use this service). You can create your own
profile. And you can send encrypted messages. The proxy is handling
encryption and decryption. The dating site only sees the unreadable
bits (ciphertext).

To see the messaging in action, get a friend to sign up too and send
encrypted messages to each other. It’s free!

http://dating.wtmnd.nl/

2. The cryptoblog

It’s a rudimentary blogging site. You can create a blog or comment on
other peoples’ blogs. The demo showcases how one can exchange keys
with strangers - correctly - without any dificult prodedures. Instead,
just click.

http://cryptoblog.wtmnd.nl/

Free software

This is all Free Software with open source code. The source code of the ecca-proxy is at:
github.com/gwitmond/ecca-proxy.
The dating site is based at github.com/gwitmond/ecca-datingsite.

an end run around zookos triangle

Sun, 02 Jun 2013 00:00:00 +0000

An end run around Zooko’s triangle

Zooko’s Triangle
describes three properties of naming systems. Zooko states that you
can choose any combination of two properties but you lose the third.

Zooko may be entirely right that a single system cannot overcome this
limitation. However, using Eccentric Authentication in combination
with other cryptographic systems we can do an end run around
it. This way we overcome the limitations of a single system and reach
our ulimate goal of: 1: Secure, 2: Decentralized and 3:
Human-meaningful names on the internet.

This blog (tries) to explain how we can reach that goal.

The triangle

Zooko’s triangle states that there are three properties of
naming-systems, of which you can choose only two. The properties are:

Unique: each name maps to one unique value; (Zooko calls this one
‘Secure’)
Decentralized: There is no central authority on the names;
Human meaningful: you can read the name on the side of a bus and
type it in at home.

Examples:

Decentralized and human meaningful: “Mom” and “Dad”. Each one of us has
their own ‘values’ for the names “Mom” and “Dad”; You lose uniqueness;
Unique and human meaningful: google.com, apple.com or piratebay.org. These names
would point to the same well known identities for most of the worlds’
population. But it requires central control to map the names to
IP-addresses for their web servers. This central control can take away the names at will;
Unique and decentralized: This would be the totally unreadable names
of your documents in Google Docs with their unpronouncable long
character strings. Not something to put on the side of a bus to be
remembered correctly later that evening.

The triangle specifies the holy grail of naming systems: to create a
world wide mapping between human readable names and values without
relying on a third party that can take away names at will.

In human terms: To make sure that the same name always point to the same thing. All the time, everywhere.

With Eccentric Authentication we use a two-level approach.

The first level is the uniqueness requirement for the local CAs. Each
name that a CA signs must be used only once at each CA. Whenever
someone signs up for a certificate at a local CA, he publishes that
certificate with the username@@sitename at the Global Registry of
Dis(honesty). It allows the world to verify that the CA doesn’t create
duplicates.

The second level comes from tying the CAs into DNSSEC. This makes
domain names point to only one CA at every point in time. No one can
change a domain name without the whole world to notice it.

Together with the Registry, we can validate that all the certificates
that bear a certain domain name are signed by the same CA-root. The
DNSSEC and the Registry work together to detect deviations from the
uniqueness requirement.

once signed, no way to take back

Once you have a certificate from a CA, there is no way anyone can take
it back. As soon as you’ve got the certificate, it’s set in stone. If
the CA signs another public key with the same name, it will be
detected at the Registry. This single act of singing will taint the
whole CA as untrustworthy. It means than no one will use that CA
anymore.

Even though the CA becomes dishonest. A certificate that you already
use to communicate with others is still usefull. Every party you
communicate with remembers your certificate. And your computer
remembers the certificates of the people you communicate with. Once
you’ve exchanged the certificates, there is no need to look them up
again. The Registy is there to help people validate certificates at
introduction. Once introduced they stay valid. Only once in a while,
you’d check out the registry to see if any of the CAs has gotten
dishonest.

Cryptographic same origin policy

Sat, 23 Mar 2013 00:00:00 +0000

Using DNSSEC/DANE to protect your Javascript application against the
threat of CSRF and CSS.

Old fashioned Same Origin Policy

Currently, browsers use the protocol, domain name and port number as a
way to tell origins apart. It is used to tell browsers that some
disjount group of servers belong to the same trust domain.

In simple language: It tells the browser which servers belong to my
web site and all other servers are ‘some one else’. The browser can
tell which javascript is served by me and which is not. The browser
can decide to treat these two classes with different trust levels. It
can run my javascript and disallow that from other trust domains.

But it is based upon domain names. And these have been proven to be
unreliable.

The Cryptograhic Same Origin Policy has the same goal, to tell trust
domains apart but it deploys DSNSEC with DANE and web server
certificates to do so.

Cryptograhic Same Origin Policy

The Cryptograhic Same Origin Policy (CSOP) uses the new DNSSEC and
DANE protocol. It also uses server certificates (HTTPS). However,
these certificates are not signed by the current bunch of global
CAs.

Instead the server certificates are signed by the site’s own
CA. This is called First Party CA. (FPCA).

First Party CA

The site owner runs his own Certificate Authority. He signs all the
server certificates of the servers that are under his direct control,
i.e. where he has the say over the contents of the sites.

He MUST only sign his own server certificates. It MUST NOT sign any other
server certificate.

The Root Certificate of the FPCA is what the server certificates have
in common. This root certicate has become the identity of the servers.

It allows browser to validate the root certificates of each resource
on the page and assign trust domains on the root certificates. Notice:
Browsers MUST only trust First Party CAs. Browsers MUST NOT assume a
trust domain for server certificates signed by global CAs. We solve
that with DANE.

DANE and DNSSEC

DANE is the
protocol that allows us to specify server certificates in DNS.

The site owner specifies the Root Certificate of his FPCA in a
DANE-TLSA record in DNS. As all servers are signed by that same FPCA,
all TLSA-records contain the same data.

The TLSA-record must specify Usage selector 2. That states the Trust
Anchor for the server. Other usage selector values cannot be used for
CSOP.

The DNS zone with the server records MUST be signed according to the
DNSSEC standard.

Browser

When the browser is requested – by the user – to retrieve a URL and
render it, it follows this procedure to determine which of the
resources are from the same origin.

The browser resolves and validates the DNSSEC/DANE TLSA record and
takes it that this is the Origin of the page. If there is any
validation error, the browser displays an error and refuses to render
this page.
The browser resolves the IP-address, connects and validates that
the server certificate matches the TLSA record. If there is any
validation error, the browser displays an error and refuses to render
the page.
The browser downloads every resource (image, javascript) that it
can retrieve from this connection and labels these resources to belong
to the Origin. (It comes from the same server).
For every resource specified in the that are on different
servers, the browser performs steps 1 to determine the Origin of that
resource. Then it performs step 2 to retrieve it. When there is any
validation error, the browser discards this resource and displays the
appropriate error in the page. Ie, broken image symbol.
The browser has established the origins of each resource. It COULD
treat all resources labeled with the Same value of Origin at the same
trust level. It MUST treat all resources with different Origin values
at a different trust level.

It’s up to the browser how much trust to give these trust domains.

For example, we can distribute a javascript application over serveral
servers, even cdn-hosted servers. For example, a web mail or photo
manipulation app. The browser can run our javascript while it forbids
the hostile code from a spying or hacked advertisement platform.

Notice: To prevent any trust where none should be granted, the
browser checks that the record has TLSA usage selector 2 and that the
Certificate specified is not a sub Certificate of any of the known
global CAs. They don’t deliver trust, they just establish a domain name)

a blog site

Tue, 23 Oct 2012 00:00:00 +0000

A blog site

This blog specifies how Eccentric Authentication can be used to design
a blog site. The most impressive aspect is that we can create a blog
site that allows anyone to blog using a pseudonym. Even the site
operators cannot learn the real identity of the blogger.

Commenters can write either anonymous or under a pseudonym.

And we show how participants can write private message to each other,
again without any third party being able to read the contents of the
messages.

We will address how to deal with trolls, spammers and other abuse.

Sign up for a blog

People can sign up for our blog site with an Ecca-account. As with
every Ecca-account, you choose your username. Your browser generates a
private key for the account and requests a certificate. When your
chosen username is still available at the site, you get the
certificate that binds the username to your public key. The signature
from the site binds it to the blog site.

The certificate is used by the site to control access to your blog. It
means, only you can write at your blog.

Writing your blog entries

Unless ordinary blog sites, this only publishes cryptographically
signed data. When you want to write a blog entry, you start your web
browser, type your text and have your browser sign it with your
private key. Then you send it to our blog site for publication.

The site verifies your signature and if that succeeds, it adds your
message and it’s signature to the blog. Under the hood it looks like
this:

<blog_entry><title>A sunny afternoon</title>
   <body>It was a sunny afternoon, time for a beer when .... happend. 
         I loved it.</body>
   <signature id="your-username" algorithm="sha256">[long hexadecimal string 
     representing the cryptographic signature of above message, signed 
     with your private key]</signature>
</blog_entry>

The readers will – of course – see a nicely formatted blog entry
with the signature string hidden, thanks to the wonders that is CSS.

Your readers’ browser on the other hand will check the signature. They
fetch your certificate from the site and actually validate the
signature against your private key in the certificate.

Writing comments

Readers can leave comments. It’s a blog, so comments are
expected. There are two kinds of comments:

anonymous comments;
pseudonymous comments.

The anonymous comments are written by people that love to read your
blog but don’t want to leave any identity when responding.

The anonymous comments can be held back for publishing until you
approve them. Or you can allow them up front and you delete them when
you disapprove. How these comments are dealt with it totally up to
you. It’s your blog. If you disagree with an already published
anonymous comment you can delete it any time.

To write a pseudonymous responses requires an Ecca-account. When a
reader wants to write a comment under a pseudonym, he registers for an
Ecca account at our blog site before he can write. Then his browser
signs the comments with his private key and delivers it at the blog
site. The site validates your message signature against your
certificate and posts the comment at the blog.

As the comments are signed with the commenters’ private key, just like
blog entries are, it allows the other blog readers to validate the
signature. When that signature is valid, the readers have linked your
public key and your ecca-identity to the message.

When writing under a pseudonym you can establish a reputation where
others may recognise your nickname. Even though they don’t know your
real name.

Scoring

There is a difference between anonymous and pseudonymous
commenters. Anonymous commenters know their status. Their messages
need approval upfront and face deletion any time.

The blog-site keeps track of a reputation score. For every comment you
write that gets published, you score a reputation point. At first,
your messages are held back for vetting by the blog owner.

When you acquire a certain number, say 5 points, your future messages
will be published without pre-approval of the blog owner, while still
scoring points.

When your messages gets flagged as spam by the blog owner, you lose
half your points. It’s the electronic version of trust that comes by
foot and leaves by horse. It’s more difficult to gain trust than it is
to lose it.

With a reputation management scheme, such as this we can keep the
spammers and trolls at bay.

Private messaging

What we do differently than other sites is that we publish your
message together with the signature and a way to obtain the
certificate. It allows your browser to validate the signature and it
ties your public key to the message.

With the public key, people can encrypt a message that only your
matching private key can decrypt. This is the basis for truly secure
private messaging.

Here’s how it works: A commenter writes a message in his browser, when
he’s finished writing, his browser signs it with his private key and
encrypts it with your public key. Then the browser drops the message
at our sites’ drop box for delivery. Next time you log in, you receive
the message. Your browser decrypts it with your private key and you
can read it. As the message is signed, you can validate its signature,
and when that succeeds, you have the correct public key of the person
who wrote the message. That key also validates every other message
written by the person, you now know the persons’ “history”.

Using the same method, you can respond to the person.

Now that you’ve exchanged keys you can bootstrap any other security
protocol between you and the other.

Trust considerations

The trust requirements for this blog application are quite low. The
impact it has is quite large.

Anyone can read any blog and comment without having to log in. Anyone
can comment anonymously. Anyone can validate the blog entries against
the sites CA-certificate.

Once you decide to open a blog, you implicitly decide that you trust
the site to run their Certificate Signer correctly. Still, you can
sign up without providing any personal details.

By writing the blog signed entries you spread your public key and
certificate around. Other people can link that key to your
writings. At the same time, you can connect the public keys of people
that comment on your blog to their username and to their writings.

With the blog site providing the link between people’s writings and
their public keys, you can send encrypted messages to the other
people, knowing it can only be read by that person.

Effectively, the blog site acts as an intermediate to introduce
strangers to each other. All it needs to do is to check that usernames
are unique and publish signed messages.

If you are a blogger with your own blog at the site but you want to
blog under a different pseudonym on someone else’s blog, just create a
second, or third/fourth ecca-identity. Let your browser do the hard part of
making it easy for you to switch identities.

announcing eccentric authentication

Mon, 22 Oct 2012 00:00:00 +0000

Eccentric Authentication

Eccentric Authentication (Ecca) is a protocol to replace password
authentication with client certificates. By doing so we can:

make it easier to login and log out of web sites;
make it anonymous; you can sign up to site without providing any
details that would tie the account to your person;
make communication more secure; you can exchange encrypted
messages securely without revealing your identity to anyone.

It’s ideal for a dating site. Once you’ve exchanged a message,
you can use the cryptographic keys in
the message to set up an encrypted VOIP-telephone call, or an
encrypted video-chat. Until the moment you see and hear each other,
you don’t know who it will be. But you can be sure that it is the
person from the message and no one else. The cryptography behind Ecca
guarantees that.

How it works.

We install a Certificate Signer at our web site. We don’t use the
certificates from the global Certificate Authorities. Our website
accepts only the certificates that its own Certificate Signer signed.
And we don’t expect other sites to accept our certificates.

When you sign up at our web site, you specify the username you want
to have. If the chosen username is still available, our Certificate
Signer signs a certificate with your username and hands it to you.

You now have a certificate that allows you to log in at our site with
your chosen username. No one else can use this username at our
site. Just like email addresses are unique.

Your web browser takes care of all the cryptography details such as
creating a private key and most important, keeping it secret.

Why? Privacy!

The Ecca protocol allows users to benefit from the power of
certificates without losing privacy, as is the case with certificates
from Global certificate Authorities.

When you request certificate from a Global Certificate Authority, they
verify your real identity by validating your passport. Once the Global
CA has sufficient proof that you are who you claim to be they sign a
certificate that bears your real name. It allows you to identify you
to banks, shops and other places that you show your certificate.

It means, that every time you use this global certificate, it tags
your digital actions with your real life identity. No denial
possible. Every email you sign with this certificate will tie it to
your person. For many people this is too high a price to pay. For
example, you might not get that dream job if your future boss finds
out that in your blog you support a different political party than him. And
there in no denial that it’s you who wrote it. As you have only one
global certificate, you would have to use it to log in to the blog
site and sign your job application.

Ecca-certificates work the same as a global Certificate but it doesn’t
carry your full identity. On the contrary, it only contains your
chosen username. It is no more than a digital pseudonym. The
ecca-protocol does not even need an email address. So you have more
privacy with an ecca-certificate than with a username, password and
email address that most sites ask for.

And why stop with a single pseudonym, if you were to blog on several
subjects, create a certificate (with different usernames) for each
topic. You can have as many certificates for our site as you wish, they are free.

Private messages

But with Ecca-certificates, we can do more. Our site allows you to
look up other peoples’ certificates by just specifying their
username. The certificate you retrieve contains the users’ public
key.

With that public key you can encrypt a message so that only the
owner of that account can read it. When you sign your messages with
your private key, the recipient can validate that the message is from
another user at our site.

Inside the message is also your
certificate. Now your recipient has all the data he needs to send you
an encrypted reply that only you can read. Not even, us the site
operators can read these private messages.

This allows us to design the worlds most private dating site.

Or we can design a blog site.

Read More

I’ve a made single page flyer with most of the characteristics of Eccentric Auhtentication. Feel free to download it: Eccentric-Authentication-flyer.pdf.

the worlds most private dating site

Mon, 22 Oct 2012 00:00:00 +0000

The worlds most private dating site

With Eccentric Authentication we can design the worlds most private
dating site. Ecca gives us benefits that other authentication
mechanisms cannot provide. Namely: Completely anonymous and fully
secure.

Similarities

Like any other dating site, ours allows you to create a profile and
search for other peoples’ profiles. When you’ve found a
Profile-of-Interest, you can write messages to the person behind the
profile.

The similarities end here. See what we do diffently.

Sign up

We require our users to sign up with an Ecca account. As with every
ecca-account you choose your nickname. It’s how you wish to be known on the
site. Names can be anything, say “Beer Belly” or “Biker Babe”.

When you’ve chosen your username, your browser creates the account for
you:

it creates a private and public key;
it offers the username and public key to the site for signing;
it receives the certificate;
it keeps the private key secure.

The certificate allows you to log in and create your profile.

After you’ve paid the membership fee, our site lists your profile.
Now you can browse profiles and other members can view yours.

Private messaging

Say you have registerd under the name Beer Belly. You find the profile
of Biker Babe interesting to start a private conversation with
her. Would you use a conventional dating site, you only have their promise
that they won’t read your message. Or at least that they have the ‘decency’ not to
tell you that they do read your messages.

With Ecca, you don’t have that worry. No one except Biker Babe can
read your message. Here’s how that works.

You press the ‘private-message’ button on your browser. It fetches the
certificate of Biker Babe. In the certificate is her public key.

You type your message, your browser encrypts it with Biker Babes’
public key. That makes the message only readable to her. Now you sign
it with your private key. Then you hand it over to our dating site for
delivery.

When Biker Babe logs in, your message will be delivered. She fetches
your certificate from the site. That allows her to: 1. verify that you
are a member of the site; 2. send messages back to you.

Going further

When the two of you like your conversation so much you can take it up a
notch and do a voice chat.

Each of you feeds the certificate of the other into your (privacy
preserving) voice chat application and the systems will set up a
encrypted voice channel, ready to talk ~~dirty~~.

This chat application is not connected to the dating site. It doesn’t
need to be. All that it needs is the the certificate of the other
party and your private key. Technically, it also needs a common ground
where the two programs can find each other before they validate the
certificates and set up the audio channel but that’s out of the scope
of this blog post.

Abuse handling

Suppose one of the BB’s is too liberal with the private channels and
behaves too inappropriate to the other BB’s opinion. Let’s say that
BB1 finds the message of BB2 inappropriate.

BB1 has now several options:

Block all messages signed by BB2;
Report the messages to the dating site staff; If they agree that
BB2 went out of line, they close the account. BB1 cannot falsely
accuse BB2. The messages are signed with BB2’s private key, so
there’s the proof.

In both cases BB2 now needs create a new account and pay the
membership fee again to be able to contact BB1 ever again.

Closing an account

Our dating site doesn’t have to do much to close the account. It just
blacklists your public key from login in and refuse to accept your
messages to other members.

There is no need for a CRL or other crypto revocation
protocols. We keep it simple but effective. Eventually the certificate
expires and we can clean up our blacklist.

Wipe your trail

When your subscription to our dating site expires, it
would be in your best interest to delete your private key.

Would you ever use that private key to sign a message and you somehow
you would need to public with your real world identity, it allows your
dating partner to match these messages and publish your love letters,
fully attributed to you. Although embarassing at best, it could be
worse if you where the one so rude that the site closed your account.

The Ecca protocol almost makes that problem a non-issue because it
generates a new private key for every account you create and your
browser handles all the crypto-bits.

Trust considerations

When you decided to sign up for our dating service and pay the fee,
you made a trust decision. Your decision is most likely based upon
recommendations from people that you trust.

You wouldn’t make that decision because some global CA has signed a
server certificate that made the address bar green.

It’s the other way around. By trusting our site enough to sign up, you trust
us to have our cryptography in order so you can communicate
privately with the other members of the site.

If we don’t have our crypto in order, or we turn out to be
crooks, you’ve only lost some money. You never gave us your real
world identity. (And you did pay in bitcoin, didn’t you?)

Deployment

The bad news: To deploy this we need to improve our web browsers. The
good news, we can start with just three – not too complicated –
browser plug ins to get things going. That’s for another blog.