Cryptography 2013

Trust Link Grid

I'd like to fuel the interest in a more closely knit Web of Trust for PGP keys with a bit of history.

In 1998 a book was published (in very small numbers) that contained a few hundred people's public keys with their fingerprints, mainly from academic circles. It was called "The Global Trust Register 1998". The book certainly helped me to establish a trust chain to the PGP key used to sign the PGP source code at the time.

As the book put certain prominent PGP keys in print it helped to make circulation of faked keys more difficult. But it certainly was not able to provide an infrastructure that anyone could use to gain first-hand-knowledge of PGP keys.

In 2001 I discussed a proposal with Ross Anderson that might have closed that gap but it was not being advanced at the time, so I'll describe it briefly here for evaluation:

The Trust Link Grid (TLG)

"The initiative is based on the assistance of a number of volunteers to make sure that a reliable public PGP key is in reach of 100 Km globally, by establishing a grid of nodes that publish first-hand-knowledge about PGP keys, that cannot be forged easily.

The TLG should provide a solution to this problem:

"How can anyone gather enough evidence based on non-electronic first-hand personal knowledge to be sure that a key of whatever kind is really used by a certain individual to the best of the knowledge of those who published the first-hand information."

I hope it will be possible to encourage individuals to act as a "Trust Link Node", as a contact person for others to confirm some first-hand information to them. I don't know how many volunteers would be needed but to cover Britain twenty individuals would make sure that a reliable key is no more than 6o Km away.

Each node creates a Trust-Link-Key and verifies his key to the node in the north, east, south and west. That takes no more than 400 Km of driving each, leaving a "Trust-Link-Statement" with every person contacted.

Every node publishes the TL-key together with at least four TL-statements on a website, which confirm that there had been a personal contact and a key verification procedure that meets certain standards (like A-level keys in GTR).

This should not absorb too much energy. And with every additional personal contact (at conferences or whatever) between two volunteers a node can collect new TL-statements to be published on their local website as well." (Jan. 2001)

This decentralized approach does not need a globally agreed-on standard in contrast it only uses signed ascii messages stating first-hand knowledge in plain english, that has been gathered without electronic means but is verifiable by checking the TL-statements for any path you like.

The trust that lies in the grid is founded on the risk that a publicly stated first-hand knowledge by a node turns out to be false. That would harm the online reputation of the individual that is running the node, as there are always at least four more independent TL-statements from other people for each such information.

"The main purpose of the initiative is risk reduction. Unlike normal signatures on keys trust link statements have semantics they state facts that make it risky to cheat both for the nodes and for the local individual. The reliability depends on the consistency of the system, that some fact is independently confirmed by others whose keys can be verified in a similar way, relying on other keys which in turn have a number of independent verifications." (Jan 2001)

The next generation secure email solution

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.

The next generation secure email solution

I am looking into the future again: (Email Encryption Preferences)

Phillip Hallam-Baker had proposed three pieces of change to make email secure, I will have a closer look at the one piece that IMHO has the most impact on future email security, the proposal that a (receiving) user can declare his email encryption preference that will be honoured by the email transport infrastructure and not the sender's email program.

Alice, the geek, has all crypto gear in place to decrypt X509 and PGP encrypted email, while Bob, the sender, does not use anything to encrypt on his endpoint (a smartphone) he might not even know what encryption is. The fact that Alice declares her preference to receive PGP encrypted email will be enough to trigger an encryption process done on the email transport infrastructure, very soon after Bob hits the send button on his smartphone and the email goes out unencrypted.

How can this be done?

Bob uses the email address alice@example.com in the usual way, his clear text email hits the first MTA. How does this MTA know reliably, that Alice wishes to have her incoming email PGP encrypted? I can imagine the following scenario:

The MTA queries the website "example.com" with the URL wget https://example.com/emailpreference/alice@example.com If unsuccessful, it will try http. If unsuccessful, it will send the unencrypted email off as usual. That's what we have today.

If the query is successful, the MTA expects a (formal) message signed by the key that is appended to the message. It verifies the signature and gets to know Alice's email encryption preference. So anyone who is capable of storing a certain message, with a self-signed key, in the file system of the domain's web server can define (and change) Alice's EEP. If Alice runs her own web site this is the most comfortable and secure way for Alice to express her encryption preference to the world. From now on, encrypted emails are piling up in Alice's inbox, none of which have been encrypted by the sender himself.

This scenario allows for certain (easy) MitM attacks, but it spreads the declarations over a number of web sites, avoiding one single key store. And if Alice wants X509 encrypted email from next week, she signs and stores one single message on her own web site, that's all.

Possible issues:

  1. Alice wants her email in plain text, but someone stores a pre-fabricated preference message on Alice's web server, locking her out from reading her email.

  2. The MTA has to decide which public key is to be used without the help of any PKI, except the EEP messages. But this decision can be supported by some register, similar to the one we have already envisioned for the eccentric authentication model.

  3. MTAs cannot be extended to support the new feature. What does it take to change MTAs like postfix, exim, sendmail etc? Is this a possible way to go that has any chance of success?