Usability on Eccentric Authentication

On the internet, there is only Alice

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

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

Classic Cryptography

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

This is what I call Classic Cryptography.

On the internet, there is only Alice

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

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

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

The bank has these needs:

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

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

What about a blog site?

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

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

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

Again, classic crypto doesn’t help me.

What about a whistleblower?

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

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

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

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

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

Eccentric Authentication to the rescue

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

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

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

Happy reading.

tor made easy

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

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

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

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

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

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

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

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

setting up

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

using it

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

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

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

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

Your Proxy 2 now does a few things:

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

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

Happy chatting.

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

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.

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.

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?

we need better computers

Sat, 01 Jun 2013 00:00:00 +0000

On the mailing list (libertationtech@lists.stanford.edu) Seth David Schoen wrote:

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:

We need completely automated key management, invisible to the user;
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/

why we still use passwords

Wed, 21 Nov 2012 00:00:00 +0000

Why we still use passwords

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.

asimovs laws for security

Fri, 09 Nov 2012 00:00:00 +0000

For any computer security to work effectively, you need to be able to
trust your computer to put your interests above those of anyone
else. If your cleaning lady can access any data on it while you are
absent, it fails basic 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:

Your computer obeys you, and only you;
Your computer protects you from any harm to your data on it;
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.