end user trust model

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:

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

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

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

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

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

End User Trust Decisions

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

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

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

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

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

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

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

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

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

Solution

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

The system we are describing is Eccentric Authentication.

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

Sign up

The typical scenario for signup is like this:

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

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

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

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

Private messaging

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

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

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

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

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

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

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