Secure once, secure always.
This guide explains how you can get started using the Mesh in as little as ten minutes. Once set up, the Mesh automatically performs all the housekeeping chores needed to use PKI. The only time you should need to think about using the Mesh is if you need to add or remove a device or change an application setting.
At the time of writing, the public Mesh Portal has not yet been established. But developers can still explore the Mesh by running their own portal. This isn't very difficult, the only catch is that a Mesh portal needs to be run on a machine that is always on and connected to the network.
First decide which of the devices you are likely to want to use as an administration device. This is a device you can use to manage your Mesh devices, to add or remove devices. You can change your mind later and you can have as many administration devices as you like.
If your administration device is lost or stolen, all that stands in the way of someone else taking over your personal security environment will be whatever passwords protect that device and the administration key stored on it. Which device you choose is a balance of security and convenience. If you are a security specialist, a c-suite executive or a senior government adviser than you should probably buy a cheap tablet computer to use as your administration device and keep it in a fireproof safe. But that is probably going to be unacceptably inconvenient if you are a network administrator who might need to add or remove devices several times a week.
Creating your Personal Profile and configuring your first device requires the following steps.
1. Download and install the Mesh tools
Currently, the Mesh is available for Windows, OSX and Linux. There is an installer for the Windows platform but not yet for OSX or Linux.
The Mesh tools are currently limited to command line tools. A GUI client is in development but does not currently support the latest version of the Mesh protocols.
To create a personal profile, you first need to choose a Mesh Portal and an account name.
Mesh account names look just like an email address. The default Mesh portal is prismproof.org. So to create a profile for herself Alice types:
meshman /personal email@example.com "Alice Example"
Users can have multiple personal profiles but this is not usual and it is not clear that this has any advantages. Since this is the first profile Alice created, the mesh manager automatically makes it the default for future operations.
Computers break, they get lost or stolen. Strong encryption provides the best available protection for the confidentiality of your important data. But your data will be lost forever if you lose access to your decryption keys. For this reason, users are strongly advised to create a set of recovery shares. This allows the master private keys in the personal profile to be recovered should disaster strike. And these keys in turn allow the recovery of your important data:
Alice decides to create three recovery shares and require two shares to recover her master keys:
meshman /escrow 2 3
Alice writes down the three recovery shares on paper and stores each of them in a (different) safe place.
If necessary, any two of the recovery shares created may be recombined to recover an AES encryption key that was used to encrypt a recovery record stored in the Mesh. The user does not need to know the portal account to perform recovery as the recovery record is indexed under the fingerprint of the encryption key.
At this point, Alice is ready to configure her applications. She begins with her email:
meshman /mail firstname.lastname@example.org
The Mesh manager automatically read the configuration files for the mail clients it recognizes and configured them for use with S/MIME signature and encryption.
If an OpenPGP implementation is installed, the Mesh manager could perform configuration for OpenPGP as well.
Next, Alice configures SSH:
Finally, Alice configures her Web browser to use the Mesh to store her usernames and passwords:
Thats it, Alice is done.
The Mesh makes security easy on a single device but it becomes even more useful when multiple devices are used because the Mesh doesn't just copy the necessary security settings across to a machine, it can copy over all the users settings for connected applications.
When connecting a device to a personal profile it is of course essential that the correct device is connected to the correct profile. An attacker could get up to all sorts of mischief if they persuaded Alice to connect her device to a profile they controlled or a device they control to Alice's profile. For this reason, the process of connecting a device requires strong mutual authentication.
As a result this process does require the user to exercise a measure of care and attention when connecting devices. But this is one of the very few cases where the Mesh does make demands of this type from the user.
The Mesh specifications (but not currently the reference code) describe three methods of connecting a device. The most convenient method is usually the 'fingerprint' method which has the following steps:
1. Download and install the Mesh tools
The first step is to download and install the Mesh tools to the new device.
To connect a new device to her profile, Alice uses the mesh manager and specifies her account profile:
meshman /connect email@example.com
The Mesh manager responds with the fingerprint of the profile returned by the portal. Once a profile is created, this fingerprint will never change so Alice will always see the same fingerprint every time she connects a device.
To remind herself of her profile fingerprint, Alice uses the fingerprint command on the administration device she connected earlier:
The two fingerprints are the same, meaning that the device is attempting to connect to the right profile.
The next step is for Alice to get a list of pending connection requests from her administration device:
This time there is the request from Alice and a second request that Alice didn't make. This is a bogus request that is automatically generated by the portal to provide a means of measuring the accuracy of user challenge verification.
Alice accepts the legitimate request.
meshman /accept xxxxx
At this point all the necessary profile data is generated to add the device to the profile. If the user's applications were Mesh enabled, Alice wouldn't need to do anything more to start using the machine.
Since there are no mesh enabled applications to date, Alice needs to complete the connection process by synchronizing the new device to the Mesh profile. This could of course be set to run periodically in a script. Alice can force the synchronization to taken place using the sync command:
At this point the new device is fully configured. All Alice's email, Web and SSH settings have been configured automatically and secured to best practical security practices.
The default security settings are designed to provide the maximum security possible without interfering with the user's work. Since often neglected tasks such as key rotation when devices are added or removed are performed automatically, these settings typically provide a much higher degree of security than even a security conscious user would achieve by themselves.
The main reason that the default level of security configured might be lower than the best available (or in some situations best practice) is to support interaction with legacy systems that don't support modern algorithms, protocols or have some other major limitation.
A less common reason that the default level of security might not be sufficient is that the user works in a regulated industry and is required to comply with a particular set of security requirements. These may or may not be more secure but are almost certain to be different.