[liberationtech] Announcing a privacy preserving authentication protocol

[Guido Witmond]

Thank you for your concerns,

I think I have the issues you mention covered in the 'protocol'


On 03/13/2013 12:31 AM, Kyle Maxwell wrote:
> I appreciate the intention, but I see a lot of problems here. Without
> doing an exhaustive analysis:
>
> A. This doesn't eliminate phishing because users will still enter
> their credentials at a site that doesn't actually match the one where
> the cert was previously signed. Otherwise, existing HTTPS controls
> would already protect them.

Perhaps a bit unclear from my description is the fact that the User 
Agent handles all credentials.

When the user browses to a site, the agent looks up the client 
certificates that are signed by the *same CA* as the one that signed the 
server certificate. Only the matching certificates will be offered to 
user to log in.

A phisher may scare a person into browsing to the phisher's 
bank-look-alike, but the phisher cannot impersonate the certificates. 
The user agent sees it as a different site -- which it is -- and won't 
offer the certificates that the user has from his bank.

This protocol is not meant be be used stand-alone to secure access to 
bank sites.

When the user falls for the phishers, enters his username and password 
(at US-banks) or his token from his token generator (at EU-banks), the 
bank sees a correct log in coming from a different client certficate and 
*knows* something's fishy. The bank blocks the account.

The user agent must not allow the user to pick a certificate that does 
not match. Doing so would lead to the current yes-clicking, because the 
user is really scared that the there is CUR 1500.- being deducted from 
his account.

There is a small window of vulnerability here, when the user signs up 
for an Eccentric certificate at the first time. This must be solved at 
bank-account signup time.

> B. What zone would contain user keys for DNSSEC?
>

I'm not sure what the question is. There are no user keys in DNSSEC, 
only the First Party Root certificates. That is stored according to the 
DANE/TLSA specification. ( 
http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ )
The way to retrieve client certificates by user name is unspecified. DNS 
could be a way. Or a well known url at the site.


> C. Your message transport protocol seems a little unclear - could you
> walk through it?

In short, the site where a user has an account allows incoming 'blobs' 
from other people. These blobs would be messages, signed with the 
senders' private key and encrypted with the recipients' public key. The 
blobs include the certificate to prove ownership of the private key.

The recipient (she) can decrypt the message and it gives her the public 
key of the sender (him). She validates senders' certificate against the 
Root certificate.

She checks the global memory to check if there are not two or more 
certificates with the same common name. (that indicates a MitM from the 
senders' CA, or just an incompetent senders' CA).

Notice, the recipient doesn't know the identity of the sender. To reply, 
she signs with her private key, encrypt with his public key and delivers 
it at the site specified by the Root certifcate of his certificate.

Each site name is unique because it is specified in DNSSEC. Each client 
certificate has a unique name (protocol requirement) to make names 
unique for a site.

Here two people can send encrypted messages without ever having to 
exchange keys beforehand.

> There are more issues here, but at a minimum I feel like it doesn't
> adequately address a broad enough threat model.

I've designed it with these things in mind:
- eliminate passwords;
- eliminate email address requirements at account setup;
- create anonymous accounts that are easier to set up than passwords, 
yet more secure against abuse.
- use TLS everywhere
- certificates are not forever. If a site requires an account to view 
it, create an account, view the site and delete the private key. Repeat 
for each visit.

There are weak spots:
- browsers handle certificates badly, very badly or not at all;
- browsers make it difficult to use crypto-card, share keys over devices;
- there is no protection against traffic analysis. Tor to the rescue.


It's a bit longer than I expected but I hope it answers your questions. 
Please let me know if it raises more questions.

with regards, Guido Witmond.