[Cryptography] The next generation secure email solution

[Ralf Senderek]

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.

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. The user's local machine (the endpoint) is secure.

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

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.

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 user knows the recipient's SEI, it's like an email address
stored in the contacts list. The machine searches for the
recipient's public key in the local key store, which contains
all keys for SEIs that have been used before. (like ssh's known_hosts file)
In order to accept a key to be stored in the local key store there
is a preliminary check with the global register of certificates,
where the uniqueness of this SEI is being established.

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


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.
    An attacker like the NSA can use quantum servers to take over the CA
    issuing process for a number of users as they have the ability to react
    to the https requests much faster than the legitimate web site can.
    This is certainly possible, but it would not weaken the encryption
    as they cannot replace the public key with some of their own.
    The user agent would notice and would complain at the registry.

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.

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.

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


            --ralf