Why should you be interested in the Monkeysphere?

For the Web

HTTPS

Security on the worldwide web revolves around HTTP over TLS, or HTTPS. The prevailing scheme for resolving whether a particular certificate should be considered valid by a web browser is to distribute a list of default trusted root CAs. This brings with it a wide variety of problems, most of which are outside the scope of this documentation. For a detailed discussion, see this article written by one of the Monkeysphere developers.

In short, the current scheme using X.509 certs requires that users and administrators defer to outside authorities in order to participate in secure online communication. The Monkeysphere aims to put power over secure communication back in the hands of those users and admins.

Articles on problems with X.509:

How it works

Using the monkeysphere for the Web requires two components. The first is the Validation Agent (msva). This is a software daemon (a process waiting in the background for requests on a network port) that uses the OpenPGP web of trust to validate certificates.

The second is a browser plugin, currently only available for Firefox and Iceweasel (or other Mozilla-based browsers), which passes the appropriate requests to the validation agent as the user browses the web.

When you direct the browser to an https site using the Monkeysphere plugin and validation agent, if the certificate presented by the site does not pass the default browser validation (using standard, hierarchical X.509), the certificate and site URL are passed to the validation agent. The agent then checks the public keyservers for keys with UIDs matching the site url (e.g. https://zimmermann.mayfirst.org). If there is a trust path to that key, according to your own OpenPGP trust designations, the certificate is considered valid, and a browser 'security exception' is put in place to allow connections to the site.

Get the browser plugin and validation agent

For OpenSSH

Do you use ssh to connect to remote machines? Are you tired of seeing messages like this?

The authenticity of host 'foo.example.org (192.0.2.3)' can't be established.
RSA key fingerprint is 17:f4:2b:22:90:d4:98:9a:a2:c5:95:4e:4a:89:be:90.
Are you sure you want to continue connecting (yes/no)?

Do you actually tediously check the fingerprint against a cryptographically-signed message from the admin, or do you just cross your fingers and type "yes"? Do you wish there was a better way to verify that the host you are connecting to actually is the host you mean to connect to? Shouldn't our tools be able to figure this out automatically?

Do you use ssh's public key authentication for convenience and/or added security? Have you ever worried about what might happen if you lost control of your key? (Or did you have a key that was compromised by the OpenSSL debacle?) How many accounts/machines would you need to clean up to ensure that your old, bad key is no longer in use?

Have you ever wished you could phase out an old key and start using a new one without having to comb through every single account you have ever connected to?

Get started with the monkeysphere for ssh

As an ssh administrator

As a system administrator, have you ever tried to re-key an ssh server? How did you communicate the key change to your users? How did you keep them from getting the big scary warning message that the host key had changed?

Have you ever wanted to allow a remote colleague key-based access to a machine, without needing to have a copy of their public key on hand?

Have you ever wanted to be able to add or revoke the ability of a user's key to authenticate across an entire infrastructure you manage, without touching each host by hand?

Get started with the monkeysphere as an administrator!

Examples

Bob is an ssh user, and has just been given an account on foo.example.org by Alice, the example.org system administrator, who he knows.

Bob already trusts Alice to properly identify all example.org servers. Alice already knows who Bob is, and the new machine foo knows that it can rely on Alice's certifications because Alice is its administrator.

Alice can set up the new bob account on foo.example.org without needing to give Bob a new passphrase to remember, and without needing to even know Bob's current ssh key. She simply tells foo that Bob <bob@example.net> should have access to the bob account. The Monkeysphere on foo then verifies Bob's identity through the OpenPGP Web of Trust and automatically add's Bob's ssh key to the authorized_keys file for the bob account.

Bob's first connection to his new bob account on foo.example.org is seamless, because the Monkeysphere on Bob's computer automatically verifies the host key for foo.example.org for Bob. Using the Monkeysphere, Bob never has to "accept" an unintelligible host key or type a password.

When Bob decides to change the key he uses for ssh authentication, he can do so at once: he generates a new key, revokes his old key, and publishes these changes to the public keyservers. The next time he's ready to log into foo.example.org, it accepts his new key -- and it won't accept his old key any longer.

The same thing works for Alice when she decides to re-key foo.example.org (let's say Alice learned that Eve has compromised the old key). Alice generates a new key, revokes the old one, publishes the changes, and the next time Bob connects, he connects as smoothly as ever. And if Eve tries to use the old host key to masquerade as foo, Bob's ssh client will refuse to let him connect!

Alice can even quit as example.org system administrator, and revoke her certifications of all example.org hosts. As long as Bob knows and trusts the new example.org system administrator to identify hosts in that domain, there's no problem.

What's the connection?

All of these issues are related to a lack of a Public Key Infrastructure (or PKI) for ssh. A PKI at its core is a mechanism to provide answers to a few basic questions:

  • Do we know who (or what host) a key actually belongs to? How do we know?
  • Is the key still valid for use?

Given a clearly stated set of initial assumptions, functional cryptographic tools, and a PKI, these questions can be clearly answered in an automated fashion. We should not need to ask humans to do complicated, error-prone things (e.g. checking host key fingerprints) except in relatively rare situations (e.g. when two people meet in person for the first time).

The good news is that this is all possible, and available with free tools, and the Monkeysphere does it!

There are other approaches to alternate PKIs for SSH, if you are interested in exploring other options to the Monkeysphere.

Why OpenPGP?

We believe that OpenPGP is the right PKI to use for this project. It allows a very flexible trust model, ranging all over the map, at the choice of the user:

  • individual per-host certifications by each client (much like the stock OpenSSH behavior), or

  • strict centralized Certificate Authorities (much like proposed X.509 models), or

  • a more human-centric model that recognizes individual differences in ranges of trust and acceptance.

Even if Bob doesn't trust Alice to identify all example.org hosts, his first connection to foo.example.org should give him more than an unintelligible string to accept or reject. It should also give him the information that Alice (and perhaps her colleague Charles) have certified the key. This is far more useful information than the current infrastructure allows, and is more meaningful to actual humans using these tools than some message like "Certified by GloboTrust".

Philosophy

Humans (and monkeys) have the innate capacity to keep track of the identities of only a finite number of people. After our social sphere exceeds several dozen or several hundred (depending on the individual), our ability to remember and distinguish people begins to break down. In other words, at a certain point, we can't know for sure that the person we ran into in the produce aisle really is the same person who we met at the party last week.

For most of us, this limitation has not posed much of a problem in our daily, off-line lives. With the Internet, however, we have an ability to interact with vastly larger numbers of people than we had before. In addition, on the Internet we lose many of our tricks for remembering and identifying people (physical characteristics, sound of the voice, etc.).

Fortunately, with online communications we have easy access to tools that can help us navigate these problems. OpenPGP (a cryptographic protocol commonly used for sending signed and encrypted email messages) is one such tool. In its simplest form, it allows us to sign our communication in such a way that the recipient can verify the sender.

OpenPGP goes beyond this simple use to implement a feature known as the web of trust. The web of trust allows people who have never met in person to communicate with a reasonable degree of certainty that they are who they say they are. It works like this: Person A trusts Person B. Person B verifies Person C's identity. Then, Person A can verify Person C's identity because of their trust of Person B.

The Monkeysphere's broader goals are to extend the use of OpenPGP from email communications to other activities, such as:

  • conclusively identifying the remote server in a remote login session
  • granting access to servers to people we've never directly met

Screenshots

One of the main benefits of using the Monkeysphere is you often do not see anything, especially when the out-of-band verification succeeds. Because of this, there aren't many pictures to show you. However, there are some situations where the marginal user interface is presented because the Monkeysphere isn't certain how to proceed. If you're interested in seeing these, here are some images of Monkeysphere in action