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

1. It is more difficult: Only one picture is shown at a time. Players have to rely on memory to recall the differences;

2. It’s played by millions of people every day, yet many don’t know they are playing;

3. 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:

1. People need to validate the authenticity of a site before typing in their password;

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

It’s about how to get your computer to protect you against phishers.

The presentation shows how DNSSEC and DANE form the basis on which this can be built. All it takes is a user agent that does the work for you. The presentation describes how to reach that goal.

presentation

A. Instant loss of security and privacy properties.

Q. What good is a tool that uses encryption in a network of plain-text
connections? 

A. Instant suspicion.

Q. What good is a tool for circumventing censorship in a country that
forbids it? 

A. Instant confession.

Our proposal

Eccentric Authentication is a protocol that weaves cryptography into the normal workflow of the net. It hides all cryptography from view, yet performs its duties at every moment.

People would interact with web sites just like they do now except that they get: - easier account creation, log-in and log-out handling; no more passwords; - full pseudonymity, users have a different identity at each site; - private messages that only the intended recipient can read;

Users (ie, the people) won’t notice any cryptography at all. They find that the protocol offers:

• fully automatic identity management;

• their computer remembers their accounts for them;

• no more impossible to answer security or trust questions;

• their computer detects and blocks phishing attempts for them, keeping them safe;

• users stay in control of their privacy;

Site operators will have to set up their servers in a slightly different way than they do currently:

• replace passwords for client certificates;

• run https-only;

• run their own fully automated certificate signer; this does all the hard work for the site-operator; (fully automated, so easy to outsource to a hosting provider without losing its security and privacy properties)

Passing the Greenwald-test

Site operators can go further. When setting up a newspaper, a blog or a comment section, they can let people post signed messages, (fully automated by the user agent).

This offers journalists the option to sign their articles with their private key, which is no more dufficult than pressing the button at the user agent.

Over time there will be a large corpus of articles, all signed using that key. When someone reads an article, their user agent verifies the necessary cryptographic properties. If it validates, the reader can use the key to encrypt messages to the journalist. If there is a validation error, the agent refuses to let people to get into situations where a crypto-problem could lead to inadvertent disclosure of identity or confidentiality.

In other words: The readers of that newspaper have to determine whether or not they trust that journalist with their message, the protocol keeps it confidential. Without either party having to think about cryptography.

This same mechanisms works between bloggers and commenters. When a blogger posts a signed message and your user agent has validated its signature to be correct, you can use it to write a private message to that blogger, however he/she is in real life.

When you want to write a private message, the system makes it possible. Again, without any need to know cryptography.

Village square

What we have done so far create a way for strangers to exchange public keys between them. The only thing they need is a way to find each other. That’s the role of the web site. It’s like the village square where people meet and engage in public discussion or private chat. However, it will leave a trail of pseudonyms who meets whom at the square.

To protect the people from too much traffic analysis, the protocol offers people to do the equivalent of exchanging telephone numbers at the square, only more secure.

Once two people have met on a site and their agents have validated their keys, they can set up a private communication channel between them. This channel is independent of the site where they met, it goes directly between their computers. The site cannot learn of anything that these two people do once they’ve set up their independent channel. The only metadata leak we have is network traffic analysis but for that we have Tor which is also easy to automate at this point.

What this channel entails is upto them. It could be a VOIP-telephone like connection, a shared document editing platform, or one has invited the other to an existing community. All secure and private. There are many good crypto-projects to let people communicate either in private or in a a community. This project lets people find others to join them. The other projects makes sure it happens. For example: LEAP to mail to people, Ostel to talk, Jitsi to chat, Secushare to collaborate with others.

Conclusion

We make it possible for normal people to be safe and secure on the internet. Each person runs a user agent that handles all the key management tasks for them.

It makes privacy the default on the net. Every whistleblower can reach every journalist of their choice, the system keeps their communication confidential.

It’s backwards compatible with the current web. People without the user agent can still read all the public posted messages of everyone. It doesn’t exclude anyone from reading. And people who don’t have the user agent installed might still be able to participate in public discussions, albeit anonymously. They cannot create private channels, nor enjoy confidentiality.

It can slowly grow in momentum until there is a critical mass where it becomes a must have.

It uses ubiquitous encryption, every connection is encrypted so Tor-traffic doesn’t stand out amongst the ‘normal’ traffic. On the contrary, it is advisable to use Tor or GnuNET every time. However, that’s a decision that everyone has to make for themselves.

The project aims to let people discover others and join their communities. The cryptography keeps them safe against warrantless spying or snooping. The weaving of crypto into the net makes this available to the common people, without requiring them to learn how to use it. (That’s the programmer’s job).

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:

1. Validate that each client certificate has a unique CN;
2. 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 .

End User Trust Model

The common user has these requirements:

1. Don’t think, just click.
2. Someone else must protect me.
3. For free.

On 1: Users don’t want to be bothered with anything that stands in the way of what they want to do. It won’t work.

On 2: Users assume that their computer keeps them safe from all harm. Or their virus scanner. Or their ISP, or faceboogle, or their government. But at the same time, these appointed chaperones must respect the privacy of their entrusted appointees.

On 3: Of course, users don’t want to pay for anything.

One might call it unfair of these users, however, I don’t blame them. It’s what has been promised time after time, albeit never delivered. It’s time we are going to deliver that: /No-Brain Security and Privacy./

End User Trust Decisions

1. Trust is binary. When people visit a website, either they trust it sufficiently to post their identifying details, or they don’t and refrain from using that site. Most likely, they click away to search for some site they do find sufficiently trustworthy.

2. Trust decisions can change at any time. It can be friends, family, or the local system administrator who is able to change a user’s trust decision. Or it can be an error on the screen to spark distrust. Or it’a s learned behaviour: “There is this green bar, so it is OK.” There is no rational thought process behind it.

3. When trust is given, security and privacy are expected. A user at a forum who sends a private message to another forum user expects that only that person can read it. The user might feel violated when that message gets leaked out by the forum administrators, or get spied upon by unexpected advertisers.

4. People have learned to distrust anyone on the net. A business that promised not to sell the customers’ email addresses to spammers, might sell it the moment the customer cancels the service. “They are not a customer anymore.” As most people don’t have easy access to throw-away email addresses, they are reluctant to sign up.

Current cryptography tools violate the End User Trust Model and the Trust Decisions.

• GPG requires people to refrain from sending a message until they are sure of a trusted path through the web of trust. In reality, what happens is that people don’t use GPG.

• S/MIME requires people to prove their Identity to a supposedly trusted third party before being able to communicate. It severely violates privacy and you have to pay for it through the nose every year. No wonder no one uses it.

• Global Trutsted CA-authenticated TLS fails the no-brain solution too. Even the green bar is not a guarantee that the site is the correct one. If there comes a warning, there is nothing that users can do to resolve the situation. In fact, clicking away the error makes it ‘work’ but

• Duck-validation: “If it looks like an email from the bank, it must be an email from the bank. I better log in to prevent that big deduction from going to happen.” Now banks are teaching people to trust an untrustable CA-infrastructure to protect their accounts. An infrastructure that cannot prevent harm. And with the secret services, all bets are off.

Solution

It is time we are going to deliver such an End User Trust Model where each of the End User Trust Decisions get addressed.

The system we are describing is Eccentric Authentication.

It uses pseudonymous client certificates. One for each account a at each site. The certificate does not contain any identifying information. Hence users are only known by their (chosen) nickname. There is a user agent at the user’s computer that does all the cryptographic work.

Sign up

The typical scenario for signup is like this:

1. User learns about a site, perhaps via a search engine;
2. User browses site, reads a bit on it; decides to sign up;
3. User directs the agent to request a client certificate with a user chosen nickname (a different nickname for each site); it sounds complicated but is just a single click;
4. Site signs the certificate. The certificate bears the chosen nickname and the sitename.

The trust decision happens in step 2. It’s a typical users’ decision: “I like it, and want to sign up.”

The Eccentric Authentication protocol keeps the user secure and anonymous. Nowhere is the user asked to provide any identifying information. No names, no email address at all. This gives the user the trust that they can sign up without giving it a thought.

In fact, a site asking for any personal identifying information is ranking lower on trustworthyness than a site that does not ask these details. Extra benefit, it’s easier to sign up anonymously than having to provide details.

Private messaging

Another aspect of Eccentric Authentication is that public messages, such as postings in a forum are signed by their writers’ private key. The signature is posted alongside the message.

This serves two functions. First, the poster can verify that their message get posted under their own pseudonym. It shows to the poster that the site is not performing a MitM attack against them.

The second purpose of the signature is to tie the posters public key (and certificate) to the message. This allows for truely private messaging to total strangers.

When a user (with a client certificate) wants to send a private message to some other user at the site, this will be the typical scenario:

1. User browses the site;
2. User comes across a message from someone; igniting the urge to send a private message;
3. User presses the ‘Compose Private Message’-button that the site provides;
4. Site specifies the account name and the other users’ certificate;
5. User agent verifies the certificate; Validating the embedded public key;
6. User writes the message and presses ‘send’;
7. Users’ user agent encrypts the message with the other users’ public key and hands it off to the site for delivery; The site only receives the encryted data;
8. Other user gets the message and decrypt it with their private key;

As the message is encrypted with the other users’ public key, only the intended recipient can decrypt and read the message. Not even the site operator cannot read the contents of the message. All they know is that one user sends a message to another. If those users did not provide their real name at signup, the users stay anonymous.

Here there is no trust needed. The user agent verifies that there is only one certifcate in the world that bears the nickname of the intended recipient. That’s easy to do with a PGP-like keystore. When there is no double detected, it must be that of the poster.

I was one of the recipients of a grant to work on an open source security project in their 5by5 program. It helped to keep me going with this Eccentric Authentication stuff. And they invited me to the conference to present the things I did.

I’ve made a small presentation on what I think is the tip of the iceberg of what you can do with client certificates. Here is the presentation

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.

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:

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

2. He configures it with his dating-site certificate and private key, so Alice can verify it’s that Bob from our dating site.

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

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

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

2. 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:

1. to recognize the names;
2. 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.

You can see my slide-like summary here: 5 minute overview

I’d love to see your comments. Please mail at guido @ witmond.nl.

It’s full of technobabble talk of how the security system operates. Feel free to ignore that at first reading.

We assume that you’ve installed the ecca-proxy as described. If not, you’ll see some Don’t panic messages. We describe those later.

Home page

This is the url for the dating site.

http://dating.wtmnd.nl:10443/

If you enter this into your browser you’ll see this page.

It’s a bit boring, just some plain text, no images. However, the proxy has done a lot of work already.

It uses DNSSEC to resolve the hostname (dating.wtmnd.nl) in the IP-address (either 37.59.38.18 or 2001:41d0:8:4d12::90). Yes, we use this alien IPv6 protocol. IPv4 is for earthlings.

It also uses a DANE, an extension protocol to lookup the TLS-certificate of the server. Every connection from the ecca-proxy to the site uses https under the hood. We have to deserve the claim ‘most secure’ somehow.

Now click on the button ‘The aliens”.

The aliens

Here is the list of aliens. This page is visible without logging in yet. Click one of the aliens and you see the detail page. It doen’t have much details, as we want to showcase the technology behind eccntric authentication. The most important thing is the “Compose a Poem” button.

If you have an account you can send encrypted messages to other participants. And you can receive messages too. To create an account, press the ‘Your profile’ button at the top.

signing up

Here it turns ugly. Although only the page layout. What we get is a page generated by the Ecca-proxy user agent. It is your computer that asks you what to do. The dating site just waits until we return with a valid account. It tells us with the 401 - Eccentric Authentication required that it wants an anonymous client certificate, signed by it’s own CA. See Anonymous Logins.

There are three options on the page.

The first option the proxy offers me (the user) to log in with my existing account (guidow). Pressing that button tells the proxyt that we want all subsequent connection to the dating site with that account. Behind that account, the proxy logs in with the client certificate.

The second option allows me to sign up for a new account. I come up with a nickname and press the ‘Register’ button. The proxy (running on my own computer) will create a new private key, and registers the public key at the site’s own Certificate Authority. It checks if the nickname is unique and signs it. Our proxy receives the certificate and uses that to log in at the site.

Notice there are two components: The site itself and the Local Certificate Authority.

Finally, there is a third option to register anonymously. My proxy will come up with a unique name ‘anon-’ and registers an account with that name at the Local CA.

We take that third - anonymous - option.

signed up - manage profile

With a second or two, we are back at the dating site. And the proxy has logged me in.

The top part of the browser window is the part of the Ecca proxy. It shows that I’m logged in at the dating site, with the account it has created for me. There is also a log out button and a link to the proxy’s management page where we can see all accounts we have for all sites where we have accounts.

The blue part of the page is the dating site. It shows the typical questions to create a profile. Select some at will and press Engage. That sets the profile at the dating site. Now we are ready to comminicate.

sending messages

Click on the ‘Aliens’ button, select one of them to whom you want to write a Vogon Poem. Click on the name to get to the details page. There, click ‘Compose a Poem’.

Here we are at another simple looking but interesting screen. It’s just a textbox and a Deliver-button. All the interesting things happen - invisible - inside the ecca-proxy.

It’s the ecca-proxy that receives the message and two hidden parameters that the dating site put there. (The site and the proxy work together on this.)

<form method="POST">
  <input type="hidden" name="encrypt" value="required">
  <input type="hidden" name="certificate_url" 
     value="https://register-dating.wtmnd.nl:10444/get-certificate?nickname=guidow%40%40dating.wtmnd.nl">
  <br>
  <textarea name="cleartext" rows="8" cols="80">I love the size of your ... ehm ... spaceship. Wanna dance?</textarea><br>
  <input type="submit" name="submit" value="Deliver">
</form>

This tells the proxy to encrypt the data in the form with the public key it can find in the in the certificate at the given URL. The proxy fetches the certificate, encrypts the data with it and submits it to the dating site.

The dating site receives the encrypted text! It cannot read the contents of the message. Only the recipient can. Now we wait for the recipient to read our message and reply….

… and wait …

Oh, wait, as I control both accounts, both the anonymous and the guidow-account, I’ve effectively sent a message to myself. We have to switch the account.

manage accounts

First press the logout-button in the top part. You get to the Eccentric Authentication Handler.

As you can see, I have seven accounts at three sites.

receiving encrypted message

Click on the dating.wtmnd.nl link. You get back to the home page. Now press the ‘Read messages’ button.

The site will want to know as whom we want to log in. The proxy offers our two accounts for this site, not the accounts we have at the other two sites.

Now we click ‘guidow’, to log in with that identity. The site receives our certificate with the name, looks up the messages and presents what it has for us. It looks like this:

That gibberish is what the dating site received from the ecca-proxy of the sender. It looks like a Vogon Poem indeed.

Below it is the link to decode. Press it and it will tell the ecca-proxy to decode the message with the private key is has for my guidow-account. Then the proxy shows me what it has decoded.

Just what we expected.

conclusion

At no point has the dating site asked for an email address, real names or identities. When it would be paid service, it can do so for listing the account name in the list of aliens. Or it could require payment for the alien-to-alien communication.

The user stays completely anonymous.

Here we’ve shown a way to create client certificates to log in to a web site. All the hard work is done by the Ecca-proxy. The user specifies the actions and the accounts to use.

How could it be more user friendly?

Safe, secure and as anonymous as you want.

It was already possible to test drive the Eccenric 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:10443/

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:10500/

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.

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:

1. Unique: each name maps to one unique value; (Zooko calls this one ‘Secure’)

2. Decentralized: There is no central authority on the names;

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

Arvind Narayanan has just pushed a two-part paper in IEEE Security& Privacy about exactly this point:

http://randomwalker.info/publications/crypto-dream-part1.pdf http://randomwalker.info/publications/crypto-dream-part2.pdf

Narayanan argues that “a mis-alignment of incentives frequently occurs” to discourage the use of cryptography to protect privacy (particularly in the strongest end-to-end sense) and that there is minimal demand for protecting data against intermediaries and service providers.

(I find this paper extremely depressing, but it does describe actual events. If I were writing this paper, I would continue to ask how we can increase demand for cryptographic privacy mechanisms rather than declaring defeat.)

The point he refers to is that the world has progressed cryptography to secure communications against tampering so we can have safe electronic banking but there has hardly any progress with respect to improving privacy.

Here is my reply to that list:

I’m not so depressed by it. In fact the paper clearly outlines the problems and the way out.

But there is the crypto-trap, it must be perfect or it is useless. It doesn’t have to be that way. Here is a simple way to start. We won’t start to solve the privacy problem. We attack other simpler problems with crypto. From there we can venture into more privacy.

Here’s how.

With anonymous client certificates, we can solve the password problem when people sign up for an account. It eases the usability of websites (no more hassle with passwords or email addresses) and it makes site building easier as client side crypto is already part of every mature web server.

By making it easier, time will come that passwords are considered more expensive than client certificates. The push comes from companies that need to pinch money.

Once we’ve replaced password authentication, the same client certificates can be used to write authenticated messages. At first, it could be used by banks to communicate with their clients. By using client certificates as third-level authentication (in addition to pin-based TAN-generators) it can defeat most phishing attempts. Even if the customer falls for it and tries to log in at the phishers’ site, the bank detects it and blocks the account.

Here the demand for crypto comes from the financial pressure on banks to solve the phishing problem.

The end user, although he has a wish to protect him/herself against advertisment networks, neighbours doesn’t have a clue on how to get that protection. He doesn’t need it. He needs computers that do the protection for him. The system above to end the password problem and phising problem is aligned with the financial pressure.

The things we need to get there are pointed out by Arvind Narayanan in his papers too:

1. We need completely automated key management, invisible to the user;

2. We need computers that are trustworthy.

The good news, is: there is light at the end of the tunnel.

I’ve been working on the first part with my eccentric-authentication ‘protocol’. It shows what we can do with anonymous client certificates.

And there are plenty of people working on the trustworthy computers. Just like the drive to virtualisation on the server is a drive to compartmentalization, we see a rise of operating systems that bring that to client computers: genode.org, coyotos.org, qubes-os.org.

With the high speed of replacement in the mobile and tablet markets, it offers opportunities that better not be wasted.

example

Here is an example of how two current trends might help to align the security and privacy alignment.

• To pick up on Narayanan’s argument, even if this kind of service is legal and even if carriers thought it was a reasonable service for them to offer, we might expect problems with demand for it. One problem for the level of demand for blinded e-cash payments for telecommunications services is that if users lose their mobile devices and don’t have suitable backups, they lose all of their prepaid account value (because it existed only in the form of e-cash on the devices).

To answer this with another current development: real time synchronization.

Many people already use dropbox to synchronize their phone with their PC. Combine that with a fingerprint scanner (and pincode) at the phone to identify yourself to the phone and the loss/theft of the phone won’t mean the loss of data nor e-cash.

[1]. http://eccentric-authentication.org/

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.

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

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

3. 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).

4. For every resource specified in the html 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.

5. 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)

Most articles about security and passwords make the trade off between security and convenience. The authors state that you can have it secure or convenient but not both.

There is actually another trade off to make: the trade off between security and privacy.

The world of cryptography knows of server certificates and client certificates. Server certificates allow users to verify that they are connected to the right servers and not to a man-in-the-middle attacker. I’ll leave out the problems like Diginotar that undermine this security.

Client certificates identify users to servers. To make it work, a user needs to have his credentials (ie. passport) validated against his person and when the Certificate Authority is satisfied, they sign a certificate. The problem is that the certificate binds the full -real world- identity of the user. To use the certificate means to fully identify yourself at every internet login, with every message. It obliterates all privacy you have.

Obliterating privacy is a too high a price for most people to gain some extra security. On top of that, you have to pay a lot to get this privacy-smashing certificate.

I believe that this trade off is the reason we still use passwords. It offers the right balance between convenience and privacy, but at an alarming price for security.

If you browse the web and it falls victim to a drive-by download and installs spyware, you’re hosed as well.

If your computer detects that you do something that would jeopardize the security and privacy of your data on it, your computer should prevent you from doing it. If you really insist, of course it must comply.

It’s like Asimovs’ Law of Robotics but for security systems:

1. Your computer obeys you, and only you;
2. Your computer protects you from any harm to your data on it;
3. Your computer destroys all the data on it when it cannot fulfill the requirements for rule 1 and 2.

On 1. Your computer obeys you, and only you.

We take this for granted but it is far from reality. In fact, you may not even be the real boss. If you have an iPhone, you live in the ‘gilded cage’ that Apple has set up for you. They decide what you can do with your phone. If you have an Amazon Kindle, they may revoke your license to any ‘books’ you have ‘bought’ and remotely (from their offices) delete those ‘books’ from your device. Search for ‘Amazon deletes 1984’.

On 2. Your computer protects you from any harm to your data on it;

Whatever you do with your computer, which website you visit, or what games and screen savers you might download, these cannot touch your data, at all.

Each app gets run from a sandbox that prevents it from accessing any data you have. The app doesn’t get access to the file system, let alone any hardware, such as the modem to dial numbers or the GPS. It doesn’t even get access to the website where it was downloaded from.

It cannot list a single phone number on your phone.

If the app needs anything, it can ask your computer for it. If the app is a screen saver, you tell your computer that it is a screen saver. Your computer knows it can start it after some idle period. Your computer gives it a screen buffer to fill and some cpu-time to do the work and your computer displays the screen buffer on behalf of the screen saver. This will continue until you press a button. The screen saver app will be killed and that’s it.

If the screen saver ever tries to access the phone book, your computer will abort the screen saver with a message to you stating that it discovered the screen saver in the cookie jar. (Rule 2).

You can start the screen saver again and again (rule 1) but that app will never get to your phone book. (Rule 2). Of course you have the option to give your phone book to the screen saver app (Rule 1) but the consequences are yours, especially if the screen saver then asks for internet access to CIA.gov or facebook.com.

A screen saver is very simple. It just needs a display buffer and some cpu-time. It’s a good example to show the rules. Now we exand to a more complicated app. A photo manipulation app.

A photo manipulation app

Once we’ve learned the basic security requirements for a screen saver we can make it more complicated. We download an instagram-like-app.

It allows to manipulate an image, either from the phone’s memory or taken fresh from the camera. When we are finished with our editing we send it along to someone or some site.

If you want to take a picture to edit, you press the take-picture on the app. It ask your computer to take a picture and deliver it to the app. Your computer starts the camera-software, tells you that the instagram-app asked for it and lets you take a picture that it delevers to the app. At any time you can abort this operation (Rule 1). And you are sure that the instagram app only gets the picture just taken. (Rule 2).

If you wish to edit a previously taken picture, press the button for that in in the app, it will ask your operating system for the pictures. Your operating system will ask you for some pictures for the app and delivers only the one(s) you’ve selected to the app. (Rule 1). The app doesn’t even know there might be more photos. It only knows what you give it. This is called a powerbox in Capability design.

To manipulate the picture, the app needs: the picture, screen space to show you the results, read user input to know what photo manipulations you want to do. It also needs some storage space to stow the intermediate and final results. Your computer provides it with that. (Rule 1).

The storage space is dedicated to the app. Only this app can reach this storage space and only as long as the app runs. Whenever the app finishes the storage space is given back to you. And you can select it next time you run the app. Or you delete it. (Rule 1).

When you are satisfied with the results of your photo-editing it is time to send the image along. You press the publish-button in the app. The app asks your computer to publish the image for it. Your computer asks you where you want to have it published and does so. It can also ask you to remember these details to automatically publish any updates you make to the picture at any later date. (Rule 1). Notice, the instagram app never gets to know to whom you’ve sent the picture.

On 3. Your computer destroys all the data on it when it cannot fulfill the requirements for rule 1 and 2.

If you ever lose the computer (laptop/tablet/phone) in the train. It will be found by someone. If it is found by the train employees you can pick it up at the depot, for a small fee.

If someone else takes it and who hasn’t the intent to call your telephone number you’ve attached to the back. It still obeys rules 1 and 2. It only obeys you and it protects your data. The ‘thief’ won’t get to control it. Remember the screensaver, your computer requires your password/pincode and perhaps your image in front of the camera before it allows access to the content.

As you have synchronised the device with your other devices, these other ones already have all your latest photo edits. When you discover the loss of your device, you order it to destroy all data on it. As soon as the thief lets the device connect to the internet, your device wipes all the data on it ceases all operation. It really makes the theft usesless as all the thief has is a dead device. Only you can revive the thing from the group of other devices it belonged to.

That’s what I call secure computing.

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:

1
2
3
4
5
6
7

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

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:

1. Block all messages signed by BB2;

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

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.