[Cryptography] On the internet, there is only Alice. was: Re: On the deployment of client-side certs

[Guido Witmond]

On 11/14/16 23:45, Ray Dillinger wrote:
> In response to recent discussion on the list:


> This sounds like a proper use case for self-signed certs (on the
> consumer side) with pinning (on the host side) to prevent fraudsters
> from impersonating consumers.

> That's within practically everybody's capability, (in the sense that
> code to create self-signed certs is all over the place and most SSL
> implementations allow certs to be used on both sides) but nobody's about
> to do it (consumers) or require it to be done (bankers, merchants, etc)
> or facilitate doing it (servers, browsers, mail clients, etc).

Hi Ray,

I've asked myself these questions too and I came up with what I call
Eccentric Authentication, a protocol to make it possible to mutually
authenticate a stranger and a well known identity.

Classic cryptography assumes there are two (or more) parties (Alice and
Bob) that know each other and need secure communication trough an
non-secure network. The meet upfront and agree on a protocol and
exchange keys.

That model doesn't work on the internet, as *there is only Alice*.

On the internet, there are a well known entities and lots of strangers
who want a secure connection with some well knowns. The strangers need
to be able to authenticate at a well known site, the site needs to be
able to recognize (authenticate) recurring visitors reliably.

See my blog:
http://eccentric-authentication.org/blog/2016/11/18/on-the-internet-there-is-only-alice


My protocol implements the well known entities by using a private CA for
each site. It signs the server certificates and client certificates. The
Root certificate goes in a DANE-record. The CA is the identitiy for the
site, user know sites by domain name.

The user runs a user agent (a browser?) that verifies the DANE-record
against the server certificate at connection time.

When the site requires a user to log in, it points to the site's CA
where to get a client certificate. Users can get one - for free - when
offering public key and a nickname. The CA signs a certificate with the
nickname@@<site's domain name> and returns it in a single https
request/response. Now the user can log in.

The protocol describes a verification service that detects sites who
cheat by signing mitm-certifcates for their users.

Given this protocol, the private CA, the verification service and the
user agent, it's getting much easier for the users:
- easy signup;
- users remain anonymous; ( a new key pair and different nickname per site)
- sites that post signed messages from users become key echanges;
- that leads to end-to-end *authenticated* private messages;
- that leads to independent private channels through Tor, invisible for
the site.
- these channels remain, untouchable by anyone except the two participants.

On local hardware reliability:

As Thierry Moreau mentioned:
> My bet is that is is impossible to come up with a sound API design
> (between the secure chip and the hostile general-purpose digital
> computing environment). Basically, if the secure chip provides a
> service to a legitimate application and refrain from doing so for
> something else, the secure chip needs another secure scheme for
> deciding which application is legitimate.

To solve this, I forsee that we need to get rid of the Unix-model of
ambient authority and move towards explicit authority, such as
Genode.org provides. That makes it easy to run untrusted software in a
sandbox without any risk to the keys to the kingdom.


It's all on my site: eccentric-authentication.

Try the demo:
http://eccentric-authentication.org/blog/2016/04/06/tor-made-easy/

With regards, Guido Witmond.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161119/e5db909c/attachment.sig>