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

End to End Encryption is useless

Sun, 17 Jul 2016 00:00:00 +0000

There is a lot of news about end-to-end encryption. Every chat app and
their neighbours are implementing it, even the big names: the Russians
with Telegram, the Americans with Allo, Facetime, Skype, Whatsapp and
what not. So that’s good, isn’t it?

Yes, end to end encryption is good! It makes sure that your message,
your love letter, voip or telephone call can only be read by the one you
intend it for and no one else.

End to end encryption is easy

End to end encryption is easy. All the tools have been
written in the last 30 years. As programmer, just use the latest
version, follow some do’s and don’ts and you’re done. Your users can
generate and exchange keys and enjoy privacy of end to end encryption.

Google, Facebook, Apple, VKontakte, they provide the ways for people
to find each other. Just sign up at their platform, create an acccount
and you’re done. With some platforms, signing up is implicit as your
phone number is your identity. Easy and secure, right?

Who holds the address book?

No. Regrettably it might not be so secure. You see, what happens is
this: If I were to send a private message to a friend, I need his
public key to encrypt it. Now, public keys are those big unwieldy
numbers around 200-300 digits long. No way he’s going to read it over the
telephone to me, let alone that I can type it in without errors. I
need to get that key some other way.

No problem, my device asks the service for the public key of my
friend. I encrypt the message using that key and hand the encrypted
message to the service for delivery.

Wait … a … minute.

Let’s state that again: I use the key I get from THEM to encrypt a
message and hand it to THEM for delivery to my friend - without any
verification. That’s a classic Man-in-the-Middle attack scenario.

Here is how that attack goes: I request the platform to provide me the
key of my friend but instead of handing me that one, they could send
me a different key - one of their own. I’d encrypt the message and
hand it to them. Now they decrypt the message, store it, hand it to
NSA or whatever. Then they re-encrypt it with my friend’s real public
key and send it on for delivery. I’d be none the wiser, nor is my
friend.

The problem is threefold:

I use the address book of the platform to fetch my friend’s key;
I use them to deliver the message to my friend;
I use their software to write and encrypt the message.

This means, I have to trust the platform to do all three correctly to
be sure that only my friend is able to read my message, not them. If
they mess with either the address book or their software I’m using,
they can read or even modify my messages to my friend.

Aside: This is already a step ahead from the unencrypted past. In the
past almost everyone could read my message to my friend. My ISP,
every network operator along the path up to my friend’s ISP could read
along, and the spies who wiretap the cables. Now only the message
platform can read along - if they would decide to do so. So I would
have to trust a lot less people. But I still have to trust the platform.

Is that trust warranted?

That’s a question that each of us has to answer. For the stuff I write
to my colleagues - if the boss is OK with that - it’s ok for me
too. It’s his decision, I can only advise. On he other hand, pillow
talk to my wife, I don’t want that to leave the bedroom ever, so I
wouldn’t trust these platforms for that, so on business trips I’ll
have to refrain from pillow talk.

Solutions

The key to solve this trust issue is to separate the three
components: address book, delivery platform and client software.

We need End to End Authentication

What we need is End to End Authentication, a way for end points, like
you and me, to verify that there is no tampering with the public keys
of our communication partners.

With that verification in place, it eliminates the risk of a Man in
the Middle-attack by the platform operators. With the push from
governments to backdoor communications, this could be a welcome
improvement.

How to achieve end to end authentication? There are many ways. This
website is devoted to one proposal: eccentric authentication. It’s a
protocol designed to make people interact publicly while remaining
anonymous. The key exchange happens transparant as part of the
interaction, no explicit actions are needed to validate keys.

But there are many more ways to exchange keys in a way that instills
confidence that there is no hidden tampering. Expect more in future
blogs. Or read those alreade there…

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.

talk for icann

Wed, 25 Jun 2014 00:00:00 +0000

Today I’ll be presenting a short talk at the ICANN DNSSEC Workshop in London.

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

making crypto invisible

Thu, 01 May 2014 00:00:00 +0000

Q. What good is a tool that requires complicated rituals such as key signing parties, or fingerprint verification?> A. Instant loss of security, privacy and usability.

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

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 .

end user trust model

Sun, 24 Nov 2013 00:00:00 +0000

There is a huge gap between the way the current deployed crypto-tools
work and the requirements of the normal end user.

End User Trust Model

The common user has these requirements:

Don’t think, just click.
Someone else must protect me.
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

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

User learns about a site, perhaps via a search engine;
User browses site, reads a bit on it; decides to sign up;
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;
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:

User browses the site;
User comes across a message from someone; igniting the urge to send a private message;
User presses the ‘Compose Private Message’-button that the site provides;
Site specifies the account name and the other users’ certificate;
User agent verifies the certificate; Validating the embedded public key;
User writes the message and presses ‘send’;
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;
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.

talk for brucon

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

Last week the 5th BruCON was held in Ghent, Belgium. It’s a small (and
friendly) security conference. Their motto is: “Hacking for
b33r”. Topics ranged from a workshop on breaking old crypto algorithms to
pinpointing GSM locations and how to make the compliance process less
headache inducing. Too bad there was no beer brewing workshop
this year due to pregnancy of the brewer.

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

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.

walkthrough datingsite

Wed, 12 Jun 2013 00:00:00 +0000

This blog gives a simple walk through “The world’s mode secure dating site”.

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/

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) into the
IP-address 94.142.241.226.

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?

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.