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.
--
Too many emails? Unsubscribe, change to digest, or change password by emailing
moderator at [email protected] or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
