The Latest Fad

Two factor authentication has made marked in-roads in web-based services lately, with the promise of additional security in the face of enormous data breaches being so commonplace as to bring about infographics on the phenomenon. What two-factor authentication does is protects access to your account, so that when a third-party site is breached and your (presumably re-used) password stolen, this isn’t an issue for other services you might, where two-factor is enabled. That this is an implicit burden shift — from service providers being expected to securely hash and salt passwords (so they’re hard to reverse into the original password) for a secure authentication implementation, to users having to opt-in, and then ensure their phones are charged and proximate whenever they want to use their email — isn’t the worst part. Even engraining and encouraging the very behaviour — password re-use — that was the genesis of this Band-Aid solution requiring people to use both “something you have, and something you know” isn’t it. It’s just a Huge Pain in The Ass. And it doesn’t have to be half as bad.

Certificate Authentication

Currently, when a user connects to (say) this website, the web server presents a cryptographically signed certificate, to verify that the server that’s been contacted is, in fact, ‘blog.joelbuckley.com.au’ (as promised by someone like The Hong Kong Postal Service or Verisign, who likely all have files installed on your computer, stating that they’re trustworthy af). This identity verification is very hard to spoof. As it’s obviously valuable to companies to be able to verify their identity to consumers, identity verification companies sell certificates to promise that people are who they say they are, as the local florist is unlikely to have the information security wherewithal to apply to each of the various companies who run Root Certificate Authority (CA) stores (such as The Hong Kong Postal Service, Verisign, etc). The local florist can buy a certificate, but unlike the intermediate and root certificates (shown below), this can’t spawn further trusted certificates; it’s the end of the line. This, but for some flaws, is a workable model, and has served the web relatively well for around 20 years.

Reversing the Model

There’s nothing to say, however, that a user can’t present a bunch of information in a cryptographically signed format back to the web sever; for example, information that says my name is Joel Bloggs, and my email address is joel@bloggs.com, and even something that might change, like my home address (all certificates must expire; it’s up to whoever vouches for this information to set appropriate expiry dates). And in fact, you can even set up a web server to request information like that today! You can store this verified identity (a certificate) in a file on your computer, meaning your browser can easily grab it and send it off when it’s required. But, who would vouch for you?

1) Be a Root CA 2) ??? (Auditing) 3) Profit!

Given that most requirements for both identity verification and security come from the corporate sector – where capital it concentrated – it’s unsurprising that certificate solutions can be priced in the hundreds, or sometimes thousands, of dollars. Given this, it’s a further barrier to entry to nascent companies, or experimenting individuals, to create an application which can talk the standard language of the secure web. You could set up your own Root CA, if you’d like. Jamie Nguyen has some cool guides. The problem though, is then getting your Root Certificate onto the approximately 500 million computers in use today.

A New Paradigm

However, it doesn’t have to be this way. What I propose should exist – and, I imagine, but for the obvious cash-flow implications of the global certificate industry, would exist – is the ability to receive a certificate for the administration of a domain or set of domains. Joel Bloggs owns the domain bloggs.com, and he’d love to sign users up to comment on his blog, and for these users to have some sort of two-factor authentication, because he’s a conscientious kind of guy. Luckily, Mr. Bloggs has managed to purchase a ‘domain controller certificate’ for bloggs.com, which means he can administer users at his domain. Each user is addressed as user@bloggs.com, and is issued a certificate (a small file, as before) signed by Mr. Bloggs, to verify that the user is who they say they are. The model from above expands to this:

However, the scope of the certificate is limited only to ‘bloggs.com’ – when a user heads on over to rival John Citizen’s blog, citizenblog.com, Mr. Citizen doesn’t recognise anything coming out of Mr. Blogg’s trust chain. So each site can make its own assessment of identity, based on however it might want to.

Features!

The ability to issue certificate to users for a domain – to vouch, with self-limiting scope, for who people are – would extend the features of the current email regime, too.

Why Nobody Encrypts Email

To date, there is widespread evidence of the ability of governments to store and read your personal electronic communications, much of which, for a lot of people, is email. Sure, we all have “nothing to hide”, but that’s beside the point. (Hit me up on twitter/IRL for a more detailed discussion on this, or have a google, but I’m aiming to gloss over this because it’s not the point of this post). The difficulty involved in setting up email encryption (I mean, just look at this instruction guide or this Lifehacker article) mean nobody cares, because an abstract, internalised, imperceptible threat is much less concern than the software equivalent of this:So, what’s a security-conscious organisation to do? Well, it turns out that my suggested model could alleviate the inherent lack of security in email, by email providers issuing these certificates with their ‘domain controller certificate’, so that joelbloggs@gmail.com gets a file to both prove who he is, and decrypt messages anyone sends to him. This is dead easy, and support for this is ready to go in iOS and Android. (Below is a screenshot of an encrypted email, shown with a small ‘lock’ icon in the sender line).

Conclusion

Large obstacles stand in the way of this, not least CAs’ willingness to issue certificates for which they cannot give assurances to the degree of confidence with which they might be accustomed. But, the web has moved on since the inception of the certificate issuer/buyer paradigm, and if there’s any social trust model construct that can be changed for the sake of efficacy, it’s one enshrined only in software.