The biggest gains we can make in improving online security and privacy won't be the result of making encryption better. Most of our problems are the result of how encryption is used.
At the moment, using encryption is complicated. Its not complicated to the point where you need special training to use it, but its complicated enough that its a pain in the ass for non-technical people to adopt. So non-technical people don't adopt encryption.
That's a real problem - because most people are non-technical. Actually, its worse than that, because it means only communications between technical people can be secured with any regularity. Even technical people can't communicate securely with non-technical people.
Encryption can only be truly successful with massive levels of adoption. Even with all of its problem, HTTP-based SSL has been enormously helpful because it doesn't require end-users to understand it or even know it exists in order for it to work.
Unfortunately, there are essentially no options that allow transparent encryption of communications between social network users; and the options for the transparent encryption of email are all piss-poor, and do not protect user messages from service providers outside of very specific edge cases.
There is another problem. Encryption is used not merely to make it impossible to read communications; it is also used to verify the identity of individuals involved in that communication. There are two approaches identity verification. With SSL, identify verification is performed by a centralized, corporate authority. This is why people pay money for SSL certificates that anyone can generate on their home computer - because the certificate from Verisign comes along with a guarantee that anyone using your certificate is really talking to you.
Quite a few companies make huge sums of money providing this sort of "service", which is in large part why it has existed for so long. But it can't continue for much longer. Along with centralized trust comes centralized vulnerability. The Snowden revelations confirmed that SSL certificate providers have been targeted by state actors - stealing the keys held by those providers lets the thief defeat the encryption provided by their certificates. But state actors aren't the only problem. It is in the immediate self-interest of SSL providers to issue a certificate to everyone who asks for one, and as a result fraudulent SSL certificates are issued regularly to spammers, phishers and other bad actors. In theory, issuing fraudulent certificates was supposed to devalue the level of Trust that each provider commoditizes. In reality, information about the volume of SSL-related fraud is opaque. Few people know which SSL companies issue the most fraudulent certificates, preventing fraud from playing a direct role in pricing.
Peer-to-peer based trust resolves these problems. The idea is that instead of purchasing an encryption certificate from a centralized authority like Verisign, you generate your own and then people who know you confirm the validity of your certificate. Users can then decide whether to trust a certificate's validity based on the same sets of criteria they use to accept a social media "friend" request (e.g. Do I know you? Do I know someone who knows you? If we don't have direct social connections are you popular enough that you can be trusted anyway?).
A platform called Keybase.io is being designed in the hopes of addressing all of these problems; and it has a lot going for it. Keybase is in pre-release development - so accounts are invite-only. I recently received an invite code and was able to create an account fairly quickly. You can take a look at my online profile here: https://keybase.io/joshwieder
 |
| My user profile on Keybase |
So far, there are a few elements to Keybase. There is a website, a client application and most recently - what the developers are referring to as the Keybase File System (KBFS). Within each of those elements are a few very interesting initiatives - for example, the website uses kbpgp.js - a PGP build for JavaScript. Transactions made through Keybase now write to the Bitcoin blockchain. And the signature architecture is based on a hash tree.
I've just gotten started using Keybase today, and the latest build available for the two operating systems that I am using to test Keybase do not yet include some of these features, like KBFS.
But here's the 1,000-foot-high view of what Keybase is trying to accomplish. Signing up for Keybase will eventually provide users with their own set of encryption keys, access to the website, the client application and a deployment of the Keybase File System. You can then 'sign' your Keybase public key by proving your ownership of social media accounts - right now Twitter, Github and a few others are available. This is a sort of hack-ey-ish way of accomplishing that peer-to-peer style of identity verification.
Using the Keybase client (or the website if you choose to trust the Keybase java library with your private key ... which I haven't and won't during the pre-release), you can "track" other Keybase users. Tracking a user demonstrates that you have verified that user's identity - it also creates a directory within KBFS allowing you to share encrypted files with that user. This allows you to exchange secure communications one-way with a user knowing nothing other than their social media account - unlike the DM features of Twitter, for example, which is both insecure and requires two-way authorization to exchange messages.
Keybase has a long way to go before it can address the user interface problems that make social-media networks the self-imposed wiretaps they are today. The client applications are solely CLI-based, even on Windows (the fix for this will be based on Electron by the looks of things). Certain key functions, like importing keys, require the installation of GPG. Until these two issues are resolved non-technical users will not be capable of using Keybase.
But maybe they won't have to. I'm most excited about the possibility that social media services will integrate the sort of application infrastructure that Keybase is developing into their existing applications. There's no reason why maintaining a separate Keybase account is necessary. Twitter could integrate a Keybase-like service, whereby following a Twitter account "verifies" their identity and setting up a Twitter account, or logging in from an independent device, also generates a PGP keypair that is saved on the user. It is not necessary that an individual only has one PGP key. They can have many - one for each device that authenticates to a given service.
I've been bummed about online privacy since 2005. Since I first found out about the AT&T fiber tap, there has essentially been no good news; what gains in privacy have been made largely surround edge cases and specific applications. Keybase.io is the first project that I've come across in recent memory that has me hoping that privacy can stop being something we remember fondly and become something that we once again take for granted.
PS - I have a bunch of invites for Keybase.io to give out. If you want one, leave a comment or message me and let me know what you need it for. Cheers!
No comments:
Post a Comment