[Cryptography] The next generation secure email solution

Guido Witmond guido at witmond.nl
Sun Dec 22 17:34:10 EST 2013


On 12/20/13 14:37, Ralf Senderek wrote:
> I am looking into the future: Secure Email Identities (SEI)
> 
> The next generation secure email solution based on
> eccentric authentication may look like this:
> 
> A user finds some website interesting and trustworthy and
> signs on. He gets a client-side X509 cert from the site that is stored
> on his local computer (including unprotected
> private key) under a globally unique name, that can be but
> needn't be his own name.

In fact, the user is better of to create a different (account) name at
each site. As the site name is part of the account name (SEI) these are
already disjunct. Eg. me at gmail.com is disjunct from me at hotmail.com.

The user is free to set passwords/fingerprints/iris-scan/swipe patterns
to protect the private keys on their computer. The agent creates a new
key pair for each account at each site. Important keys can have more
protection than throwaway accounts that a site demanded just to post a
comment.

> Users need their certificate to log into the website that
> has issued the cert, there are no passwords any more and whoever
> *has* the unprotected private key *is* the person and can
> use the SEI.

Exactly.

> Any website can create these certificates for users as long
> as SEIs are globally unique but only for local users.

As DNS(SEC) domain names are unique and each account name is unique,
hence SEI are globally unique.

> The global-uniqueness of a SEI can be verified by checking a
> distributed list of hashes, that enables anyone to see, if
> a certain site issues unique SEIs or not.

> Any duplicate SEI is proof of a problem and disqualifies the
> site as a trustworthy CA issuer, and therefore invalidates
> all user's certificates from the time a duplicate is detected.

> It basically kills the site, as users need certs to log in.
> So every web site has an incentive to do proper signing and
> SEI verification before signing.

It dents the reputation of the site. However, not all is lost. Any
previously validated SEI's in the users address book stay valid. If
people have created separate channels between them, these stay valid
too. The site can die, the users' validations stay. It is encouraged
that people set up extra indenendent channels as a precaution against an
untrustworthy/hacked/coerced site. It also protects against metadata
analysis.

Any message delivery via the site will get logged for life. Independent
channels can be anonymous if set up like a alt.messages.anonymous newsgroup.


> How does a user get a key?
> Read: How does the software on the user's computer fetch the
> correct recipient's public key without the user noticing what
> happens behind the scenes?

The protocol automates all these parts. It can be 1 click. "Create an
account at this site".

> All SEI addresses that are not locally stored can be used in
> the initial trust-establishing dance, involving the global
> register.

There are several ways to get to know the SEI of someone.
1. You communicate with people on the blog site. The site acts as
introducer to strangers;
2. You receive the SEI from someone on a business card; or read it from
a printed letterhead; or read it at a newpaper-colophon.
3. You receive it from someone you trust, family, friend. You wouldn't
accept it from a stranger on the street.


> How can a Man-in-the-Middle attack be mounted under these conditions?
> 
> 1) The classic attack is the case where the cert is not signed by
>    the website's CA but the MitM during the sign up step.

No need for quantum computers. If the attacker coerces the
DNSSEC-registrar to sign a duplicate for the fake site, it will be
detected by the Registry that notices a new CA for a known site as soon
as you submit your certificate for inclusion.


> 2) If someone who is not the recipient, replies to my encrypted message,
>    I need to verify the sender's identity (via a mandatory signature).
>    The user agent has to perform sign and encrypt on every message.
>    No problem.

> 3) An attacker induces false certificates with the attempt to ruin the
>    website. He creates a fake CA and creates duplicate certs for existing
>    users and sends them off to the global registry. As the registry is
>    designed to accept all submissions, a number of SEIs will soon
>    be unusable. The registry has no means to distinguish benign from
>    fraudulent certificates, because the web site CAs are not signed by a
>    root key or bound to any old-fashioned PKI.
>    As I see it, there is no protection from this kind of malice.

This has been foreseen. The Registry validates the submissions to see if
the certificate chain ends in the DANE-specified site-CA. It drops any
certificate that does not match. Eliminating this attack.

The site operator has an incentive to choose a good registrar. And throw
out bad ones.

> And if the endpoint (local machine) is the place where the private key is
> stored we will soon have another pile of SEIs becoming unusable, when
> laptops
> get stolen, hard drives die and local OSes become unreliable without proper
> backup procedures. This will happen.

The endpoint opsec is the weak link. These problems are real. But they
are equally problematic for password. Any malware that goes after
private keys can go after password managers and keylogging the master
password. Any improvement in opsec for passwords is also an improvement
for private key storage. Proper sandboxing, microkernels, process
isolation are important techniques to make client certificates more
safe. We need these techniques urgently anyway, whether we deploy
passwords or certificates. If only to keep my bitcoin wallet safe.


> So in the end we will have a mix of working addresses and dead addresses
> and nobody can tell the difference.

That can be a good thing or a bad thing. Depending on your view.


Guido.

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


More information about the cryptography mailing list