Building the Web of Trust – the First Baby Step

A few weeks ago I wrote about the way secure connections on the Web are set up and why the system as it stands is vulnerable to abuse — or total collapse. I’d like to spend a little time now devoted to specific things we can all do to make the Web safer for everyone. This attempt to turn the ocean liner before it hits the iceberg may well be futile, which will inevitably lead to governments being the guardians of (and privileged to) almost all our private conversations and transactions.

So, I have to try.

Security and privacy are related and a key tool for both is encryption. A piece of data is scrambled up and you need a special key (which is a huge number) to unscramble it. Modern systems use two keys, and when the data is scrambled with one, it can be unscrambled with the other.

When I get a message from Joe, I can use the public half of his pair of keys to unscramble it. If that works, then only someone who has Joe’s secret key could have sent the message. Joe has effectively “signed” the message and I can tell he wrote it and that it hasn’t been tampered with since.

The catch is, if someone gave me a bogus key and said it came from Joe, then all those messages that supposedly came from Joe actually came from someone else. These days most of the certificates (the files that contain the keys) out there are created and confirmed by a handful of companies and governments, and the software we use trusts these certificates implicitly. You are not even asked if you think Comodo is trustworthy, diligent, and none of its subsidiaries has been hacked (which happened), the decision has been made for you.

It is conceivable that we can replace this centralized authority system, but so far it’s not simple. Practically speaking, nothing big is going to change until things are much more obvious. Still, one of the first stepping-stones is in place, so we may as well get that part into common use, which would accelerate the rest of the process.

Here’s my thesis: With technology today, all emails should be signed, and any email to someone you know should also be encrypted. I look forward to the day I can reject all unsigned email, because it will be spam. As a side effect, jerssoftwarehut.com won’t get blacklisted in spam filters because some other company used that address in the “from” field of an email they sent. Email is fundamentally flawed, the big companies are too busy arguing about how to fix it, and it’s time to do it ourselves.

How do we get to this happy place? It’s actually pretty simple. It takes two steps: create a pair of keys for yourself and turn on S/MIME in your email program. If everyone did those things, the Internet world would be a much happier place. Plus, once we all have our keys, the next phase in revamping Web security, building the Web of Trust, will be much simpler (once the software manufacturers realize people actually want this — another reason we should all get our keys made).

If it’s so easy, why isn’t everyone doing it already?

All the major email programs support S/MIME, but they don’t seem to think that ordinary folks like you and me want it. All the documentation and tools are aimed at corporate IT guys and other techno-wizards.

I’m going to go through the process in general terms, then show specific steps for the operating system I know best. I borrowed from several articles which are listed at the bottom, but my process is a little different.

Step 1: Get your keys. Some of the big Certificate Authorities offer free keys, and while that route is probably easier and absolutely addresses our short-term goals, it does nothing to address the “what if the CA system breaks?” problem. So, for long-term benefits, and getting used to our new “I decide whom I trust” mentality, I recommend that we all generate our own certificates and leave the central authority out of it.

The catches in Step 1:

  1. It’s not obvious how one generates a key in the first place, gets it installed correctly, and copies the key to all their various devices.
    1. For Windows, it may depend on what software you use to read your email. Here’s an article for Mozilla (Firefox and Thunderbird): Installing an SMIME Certificate.
    2. For Mac, read onI’ll be publishing instructions soon.
  2. I’ve read (but not confirmed) that Thunderbird (the Mozilla email app) requires that certificates be signed by a CA.
    1. You can create your own CA – basically you just make your certificate so it says “Yeah, I’m a Certificate Authority”.
    2. If I know you personally, you can use my CA, which I created just yesterday for my own batch of certificates. If you’re interested let me know and I’ll tell you how. It’s pretty simple.
  3. When you generate your own keys, they won’t be automatically trusted by the world at large. That’s the point. The people you interact with will have to decide whether to trust your certificate. In the near term, this could be a hassle. It’s something people just haven’t had to deal with before. You can:
    1. Educate them, get them on board, and not worry too much if people get an “untrusted signature” message and don’t know what to do about it. That way they’ll at least notice there’s a signature at all.

For all those catches, there’s an alternative: go back to using a trusted Certificate Authority like Comodo to generate your certificate, and at least get used to signing and encrypting everything. Maybe later you can switch to a self-signed certificate.

Ironically, in the case of these free certificates from the big companies, they’re probably less trustworthy than one you generate yourself. All the CA confirms is that they sent the cert to the associated email address after they made it. But, our software trusts them for better or worse, and if that makes adoption of secure communication happen faster, then I’m good with that.

The catches in Step 2:
Really, there aren’t any. Somewhere in the preferences of your email reader you can turn on S/MIME (on Mac, installing your certificate seems to do that). You can probably set it to sign everything — and you should. The next step is to learn how to interact with the signed messages you receive. Do you trust the signature? (Don’t take this lightly – if possible confirm the email you got through another means. You only have to do this once.) If so, you can tell your computer and it will save your friend’s public key. Now you can send an encrypted message back to that person, and they’ll be able to trust your key, too. Between you two, you’ll never have to think about it again. Your communications will simply be secure, with no added effort at all.

Note:
I intended to put the step-by-step instructions for Mac here, but it’s a beautiful Sunday afternoon and even though I’m sitting outside, I have the urge to go do something besides type technical stuff into a computer, prepare a list of references, and all that stuff. So, that will have to wait a day or two. It’s time to let this episode run free!

1